H264 over RTP video timing using single nal mode

我使用NvEnc编码实时H264流，我试图通过RTP将它作为“实况广播”（实际上是多播）发送。事情目前工作正常，将h264转储到磁盘，甚至将flv写入磁盘进行调试都可以正常工作。使用MPlayer观看流时，发送原始UDP流也可以。至于流本身，它正在使用LOW_LATENCY预设，我只生成I帧和P帧（强制每隔60帧插入I帧以及SPS/PPS）。此外，NAL单元创建为小于MTU大小减去RTP标头长度。H264 over RTP video timing using single nal mode

现在，当我试图通过RTP发送它时，我正在使用单个NAL模式（packetization-mode = 0），并且在计算rtp时间戳的外观时遇到问题。我正在使用jrtplib来设置和使用RTP。

对于我从NvEnc获得的每个编码帧，我提取n个NAL单元，并且每个NAL单元都在它自己的RTP包中发送。我尝试使用相同的rtp时间戳发送帧的所有NAL单元，并将下一帧的时间戳增加1500（90000 Hz/60 fps，因为我有固定的60 fps输入）流。我也尝试测量帧n和帧n + 1之间花费的时间作为时间戳的增量（无论如何大致为1500）。现在MPlayer仍然可以播放流，但VLCPlayer每隔几秒都会重新缓冲，我认为它与时间戳问题有关。我觉得MPlayer似乎更容忍滥用我身边的东西。欲了解更多信息，下面是我使用回放流（的一部分）的SDP设置：

m=video 24712 RTP/AVP 96 
a=rtpmap:96 H264/90000 
a=ftmp:96 packetization-mode=0 
a=recvonly

我误解的东西吗？我试图阅读RFC，但无法自行解决这个问题。

所以问题是，当使用单一nal模式时，生成RTP时间戳的正确方法是什么？

来源

2015-11-17 pettersson

你是否在FLV中包含这些单一的NALU？如果您录制10秒钟然后使用像FFMpeg这样的工具先将FLV转换为MP4，然后再将MP4转换为新的FLV，现在将您的旧FLV与FFMpeg中较新的FLV进行比较，会发生什么情况。查看时间戳和CTTS偏移量。他们匹配吗？ –

FLV仅用于“离线调试”。当通过RTP /网络发送时，我只发送NAL单元。我会试着看看你在上班时提到的时间戳。改变一些代码后，VLC看起来更好，但仍不完美。 – pettersson

在摆弄了一些东西之后，我在我的线程代码中发现了一个错误，导致了错误的帧。一旦解决这个问题，创建时间戳如下：

我测量每个发送的nal单元之间的时间。因此，对于每个新帧，自上次发送单元（固定60fps应用程序）以来，延迟时间大约为16ms，我将其添加到RTP数据包的时间戳中。同一帧的每个nal单元之间的延迟相当小（接近于零）。

这适用于我的用例。

来源

2015-11-30 12:20:37 pettersson

H264 over RTP video timing using single nal mode

回答

相关问题