Video streaming 使用单nal模式的H264 over RTP视频定时

我正在使用NvEnc对实时H264流进行编码，并试图通过RTP将其作为“实时广播”（实际上是多播）发送。到目前为止，一切正常，将h264转储到磁盘，甚至将flv写入磁盘以进行调试。使用MPlayer观看流时，发送原始UDP流也可以工作。至于流本身，它使用低延迟预设，我只生成I帧和P帧（强制每60帧插入一个I帧，以及SPS/PPS）。另外，创建的NAL单元小于MTU大小减去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设置：

我是不是误解了什么？我试图阅读RFC，但无法自行解决此问题

---

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

在反复尝试之后，我在线程代码中发现了一个错误，导致了帧中断。修复后，按如下方式创建时间戳对我来说很好：

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

---

这对我的用例很好。

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

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