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

回答

相關問題