似乎有那麼每個嘗試通過RTSP/RTP實現H.264的人都會遇到這個問題。那麼這裏是我的兩分錢:
1)有一個訪問單元的概念。訪問單元是代表編碼幀的一組NAL單元(可能只有一個)。這是你應該工作的邏輯級別。如果您想要編碼器爲您提供單獨的NAL單元,那麼當編碼過程從一個原始幀(例如,SPS + PPS +編碼圖像)導致多個NAL單元時,您會期望什麼行爲。也就是說,可以通過配置編碼器來減少訪問單元中的NAL單元數量(例如,不包括AUD NAL,不重複SPS/PPS,不包括SEI NAL) - 通過這些知識,您實際上可以知道應該如何處理期望和種類的強制編碼器給你每幀單一的NAL(當然這不適用於所有幀,但是有關於解碼器的知識你可以處理)。我不是NVENC API方面的專家,我也剛剛開始使用它,但至少對於Intel Quick Sync,關閉AUD,SEI並禁用PPS/SPS的重複使我大概每幀1 NAL左右幀2 ... N。
2)不能回答這個,因爲我提到我不熟悉API,但我非常懷疑這一點。 3)SPS和PPS應該位於第一個訪問單元(從編碼器獲得的第一個位流),並且您可以在位流中找到正確的NAL並提取它們,或者可能存在特殊的API調用來從編碼器獲取它們。
所有的說法,我不認爲這是很難實際運行的比特流,解析開始代碼,並提取NAL單元,並將它們逐一餵給Live555。當然,如果編碼器提供以AVCC格式輸出比特流(與起始碼或附錄B相比,它使用NAL單元之間的交錯長度值,因此您可以跳到下一個長度值而無需查找前綴)那麼你應該使用它。當它只是RTP時,很容易實現自己的傳輸,因爲我對GStreamer運氣不好,沒有對FU-A分組化提供適當的支持,在RTSP的情況下,傳輸基礎設施的開銷更大,它是合理使用Live555等第三方庫。
我試圖做你已經實現的,使用NVEnc發送OpenGL幀。你使用CUDA互操作,還是有更好的方法?感謝任何指針! – JPNotADragon 2015-10-01 17:43:40
最好的方法是CUDA互操作,但我還沒有做到。我只是渲染一個FBO,將數據傳遞給RAM,然後再次傳遞到NVENC表面。在CUDA示例中,應該有關於如何直接從FBO發送它們的資源。 – 2015-10-02 07:22:45
謝謝@chuckleplant,我會看看。到目前爲止,唯一的一件事就是在奧斯陸大學完成的這個非常有趣的論文:http://heim.ifi.uio.no/paalh/students/MartinAlexanderWilhelmsen.pdf – JPNotADragon 2015-10-02 09:49:03