Closed HuHeng closed 3 years ago
时戳处理有问题,播放一卡一卡的,totalDuration变量不应该是音视频共用的。 时戳是相对于chunkstreamid相同的chunk包的,这里音视频混用了同一个totalduration变量,计算出来的有问题。
这段代码已经默认时戳是相对时戳了,不够严谨,这个时戳可能是绝对时戳啊,这段计算totalduration,其实就是绝对时戳, 这部分逻辑应该放到解析协议中吧,这里并没有任何地方表明这个时戳一定是相对时戳。虽然大部分推流工具除了首包,后面都是相对时戳。
由于时戳问题,rtmp拉流会明显卡顿。
case RTMP_MSG_AUDIO: // pkt := avformat.NewAVPacket(RTMP_MSG_AUDIO) if msg.Timestamp == 0xffffff { totalDuration += msg.ExtendTimestamp } else { totalDuration += msg.Timestamp // 绝对时间戳 } stream.PushAudio(totalDuration, msg.Body) case RTMP_MSG_VIDEO: // pkt := avformat.NewAVPacket(RTMP_MSG_VIDEO) log.Println("huheng debug push video timestamp: ", msg.Timestamp) if msg.Timestamp == 0xffffff { totalDuration += msg.ExtendTimestamp } else { totalDuration += msg.Timestamp // 绝对时间戳 } stream.PushVideo(totalDuration, msg.Body)
如果你进入engine代码中看PushAudio和PushVideo就知道了,其实传入的时间戳并没有被使用,有一个判断UseTimestamp那里,你看一下呢
自己打时戳吗?难怪我改了后试了试,拉流时戳还是和原始的对不上
时间戳问题已经彻底解决了,看v3分支
时戳处理有问题,播放一卡一卡的,totalDuration变量不应该是音视频共用的。 时戳是相对于chunkstreamid相同的chunk包的,这里音视频混用了同一个totalduration变量,计算出来的有问题。
这段代码已经默认时戳是相对时戳了,不够严谨,这个时戳可能是绝对时戳啊,这段计算totalduration,其实就是绝对时戳, 这部分逻辑应该放到解析协议中吧,这里并没有任何地方表明这个时戳一定是相对时戳。虽然大部分推流工具除了首包,后面都是相对时戳。
由于时戳问题,rtmp拉流会明显卡顿。