H264 over RTP 视频时序使用单最终模式答案

【问题标题】：H264 over RTP video timing using single nal modeH264 over RTP 视频时序使用单最终模式
【发布时间】：2016-02-18 13:35:35
【问题描述】：

我正在使用 NvEnc 对实时 H264 流进行编码，并尝试通过 RTP 将其作为“直播”（实际上是多播）发送。到目前为止一切正常，将 h264 转储到磁盘甚至将 flv 写入磁盘进行调试都可以正常工作。使用 MPlayer 观看流时，发送原始 UDP 流也有效。至于流本身，它使用的是 LOW_LATENCY 预设，我只生成 I 和 P 帧（强制每 60 帧插入一个 I 帧，以及 SPS/PPS）。此外，NAL 单元的创建小于 MTU-Size 减去 RTP 标头长度。

现在，当我尝试通过 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，但无法自行解决此问题。

那么问题来了，在使用单一模式时，为 RTP 生成时间戳的正确方法是什么？

【问题讨论】：

您是否在 FLV 中包含这些单个 NALU？如果您录制 10 秒，然后使用 FFMpeg 之类的工具先将 FLV 转换为 MP4，然后再从 MP4 转换回新 FLV，会发生什么情况，现在将您的旧 FLV 与来自 FFMpeg 的新 FLV 进行比较。查看时间戳和 CTTS 偏移量。它们匹配吗？
FLV 仅用于“离线调试”。通过 RTP / 网络发送时，我只发送 NAL 单元。当我重新开始工作时，我会尝试查看您提到的时间戳。更改一些代码后，使用 VLC 看起来更好，但仍然不完美。

标签： video-streaming h.264 vlc rtp

【解决方案1】：

在摸索了一些之后，我在线程代码中发现了一个错误，导致帧损坏。解决此问题后，按以下方式创建时间戳对我来说效果很好：

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

这适用于我的用例。

【讨论】：