live video streaming server in golang

v:0.0.5

newtest docker run -p 1935:1935 -p 7001:7001 -p 7002:7002 --name livego gwuhaolin/livego 2019/11/04 08:56:28 main.go:118: start livego, version master 2019/11/04 08:56:28 liveconfig.go:35: starting load configure file(.livego.json)...... 2019/11/04 08:56:28 liveconfig.go:38: ReadFile .livego.json error:open .livego.json: no such file or directory

你好，首先多谢贡献这么好的rtmp server开源。 近期我用SRS_bench对livego做性能测试，测试的设备是阿里16核的服务器。 并发publish 300路rtmp流到livego， CPU占用率比较高。 其中一个原因是内部的报文传递，都直接用的内存copy，而不是应用，导致cpu比较高。 我对大部分的接口进行了修改： type WriteCloser interface { Closer Alive CalcTime Write(Packet) error------>Write(*Packet) error }

type VirWriter struct { Uid string closed bool av.RWBaser conn StreamReadWriteCloser packetQueue chan av.Packet------>packetQueue chan *av.Packet } 等等，就不贴所有代码了，主要就是用引用传递，而不是每次都做copy。 修改后cpu占用率降下来不少。

但是目前在300路rtmp publish并发的情况下，CPU占用率还是比较高，50%左右。 定位了一下，主要cpu消耗较多的是下面这个部分： func (s *Stream) TransStart() { ....... for { ...... err := s.r.Read(&p) ...... //Start: 从这里开始的gop cache的处理，cpu消耗非常大！，如果注释掉这部分，性能和SRS rtmp服务器性能差不多 s.cache.Write(p)

	for item := range s.ws.IterBuffered() {
		v := item.Val.(*PackWriterCloser)
		if !v.init {
			if err = s.cache.Send(v.w); err != nil {
				log.Printf("[%s] send cache packet error: %v, remove", v.w.Info(), err)
				s.ws.Remove(item.Key)
				continue
			}
			v.init = true
		} else {
			new_packet := p
			if err = v.w.Write(&new_packet); err != nil {
				log.Printf("[%s] write packet error: %v, remove", v.w.Info(), err)
				s.ws.Remove(item.Key)
			}
		}
                    //End: 到这里结束
	}

希望能帮助看看gop cache这部分怎么优化，如果方便，是否能qq交流。这是我的邮箱: [email protected]。

1，配置文件功能 配置application_name, streamname 2，动态push，pull功能 根据http命令来做push和pull 3，静态push功能 通过配置文件，静态push流到上游rtmp服务器； 我整理一下吧，然后再上传。 4，解决大量并发play结束后的崩溃问题 5，解决去使能hls的异常问题

在文件livego\container\flv\muxer.go的函数GetWriter中

	if err != nil {
		log.Error("open file error: ", err)
		return nil
	}

它打开了文件写操作，并且没有关闭。因此会一直写文件。在open后添加defer关闭，生成的文件就只有1k，并且可随时删除，也不影响直播效果，完全不占用磁盘空间

	w, err := os.OpenFile(fileName, os.O_CREATE|os.O_RDWR, 0755)
	defer w.Close()
	if err != nil {
		log.Error("open file error: ", err)
		return nil
	}

Guys, why does your module have a relative name? Why isn't it github.com/gwuhaolin/livego?

And why are imports on livego made relative?

This prevents me from using livego as a library. I can make a pool request if it's OK for you

在HLS中，写AAC音频，会修改SpecialCache中的数据，造成后续的播放全部错误，

func (d *Demuxer) Demux(p *av.Packet) error {
	var tag Tag
	n, err := tag.ParseMediaTagHeader(p.Data, p.IsVideo)
	if err != nil {
		return err
	}
	if tag.CodecID() == av.VIDEO_H264 &&
		p.Data[0] == 0x17 && p.Data[1] == 0x02 {
		return ErrAvcEndSEQ
	}
	//此处有可能影响缓冲
	p.Header = &tag
	p.Data = p.Data[n:]

	return nil
}

修改位置

func (specialCache *SpecialCache) Send(w av.WriteCloser) error {
	if !specialCache.full {
		return nil
	}
	//TODO zhangzj 进行一次赋值，防止被缓冲数据修改
	packet := *specialCache.p
	return w.Write(&packet)
}

Hi! Run docker run -p 1935:1935 -p 7001:7001 -p 7002:7002 -p 8090:8090 -d gwuhaolin/livego and have error: ERRO[2020-09-04T16:31:23+03:00] handleConn HandshakeServer err: rtmp: handshake version=80 invalid

在livego中，对channel生成key的时候使用的是golang的rand包。在golang中rand包生成的是伪随机数，每次运行的seed是不变的。所以虽然在每次运行中各个channel的key不会重复，但是对于多次运行中生成的key是不变的。比如说，第一次运行的时候，第一次生成的key是key1，第二次生成的key是key2，那在第二次运行程序的时候，第一次生成的key肯定也是key1，第二次生成的key肯定也是key2。我们可以在uid的包里面添加一个设置rand的seed的init函数来解决这个问题：

func init() {
	// rand.Intn is pseudo-random, set seed to make it vary
	rand.Seed(time.Now().UnixNano())
}

运行一段时间，就崩了。。。

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x5375b6]

goroutine 449 [running]:
bufio.(*Writer).Flush(0xc0001fbb40)
	/usr/local/go/src/bufio/bufio.go:628 +0x56
bufio.(*Writer).Write(0xc0001fbb40, {0xc0006221a3?, 0x436dd2?, 0xc000214110?})
	/usr/local/go/src/bufio/bufio.go:672 +0xd8
net/http.(*response).write(0xc0000ba0e0, 0xbd, {0xc0006221a3, 0xbd, 0x56e5d}, {0x0, 0x0})
	/usr/local/go/src/net/http/server.go:1615 +0x21e
net/http.(*response).Write(0xc00023e010?, {0xc0006221a3?, 0x7ce8f?, 0xc00003ef03?})
	/usr/local/go/src/net/http/server.go:1573 +0x30
github.com/gwuhaolin/livego/protocol/httpflv.(*FLVWriter).SendPacket(0xc00023e000)
	/mnt/c/Users/cosx/dev/livego/protocol/httpflv/writer.go:151 +0x1d3
github.com/gwuhaolin/livego/protocol/httpflv.NewFLVWriter.func1()
	/mnt/c/Users/cosx/dev/livego/protocol/httpflv/writer.go:55 +0x26
created by github.com/gwuhaolin/livego/protocol/httpflv.NewFLVWriter
	/mnt/c/Users/cosx/dev/livego/protocol/httpflv/writer.go:54 +0x42a

with this new feature we can handle who can have access to the stream, so we can share unique credentials for each user that can access the content of the rtmp stream. also we can control (by ip) to force only one client by shared credential.

例如: 房间号aa 串流密钥 rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk

正常使用 推流 rtmp://localhost:1935/live/rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk 拉流 http://localhost:7001/live/aa.flv

但发现下面做法也能推拉流成功. 这明显是不符合逻辑. 推流 rtmp://localhost:1935/live/aa 拉流 http://localhost:7001/live/rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk.flv

解决方法: 建议房间号和串流的 缓存键增加前缀 用以区分, 例如: room:aa key:rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk