我使用 gstreamer 透過模仿 UdpSink 的自訂 AppSink 進行串流傳輸。我們這樣做是為了可以在其他連接埠上監聽某些元資料。另外，庫存 UdpSink 已損壞。無論如何，我已經成功地進行了視訊串流傳輸，但 UDP 資料包似乎未正確打包。我想知道我是否錯過了某些步驟。
這是我的發送管道：
filesrc (mpeg TS file) ! displayQueue ! streamTee ! tsdemux ! decoder ! videosink
streamTee ! sendQueue ! udpSink (our custom one)
接收端：
UdpSrc (custom) ! queue ! mpegtsdemux ! queue ! (mpegdecode || h264decode) ! ... ! videosink
串流媒體作品。但它看起來非常脆弱。有時它就停止了。有很多文物。
所以，我嘗試了VLC。我將其設定為透過 UDP 單播進行串流傳輸。效果很好。我注意到 VLC 發送影片的方式與我的管道不同。我用Wireshark分析封包：
使用的協定：VLC：（IP:UDP:MP2T以及PET、PMT資料包和所有其他類型的 TS 相關內容）
礦：IP:UDP:Data
看起來我使用的管道只是通過 UDP 發送原始視頻，沒有任何錯誤糾正。我缺什麼？使用的影片是 h264 或 mpeg 編碼.mpg檔。
我正在使用 gstreamer-java 對自訂 UdpSink 和 UdpSrc 元素進行編程，但無法在控制台中使用 gstreamer 進行測試，因為庫存UdpSink 外掛程式損壞。我在 Linux VM 中嘗試了一個簡單的管道，並獲得了一組與 VLC 類似的資料包：
gst-launch-0.10 -v videotestsrc ! mpeg2enc ! mpegtsmux ! udpsink host=192.168.2.100 port=1234
答案1
這只是一個想法，我對 gstreamer 不太熟悉，所以我不知道它是如何filesrc運作的，但我假設它不理解 MPEG-TS。 MPEG-TS 要求封包進入特定邊界（通常為 188 位元組）。我會嘗試將您的 tee 放在 demux 之後，然後在您的udpSink.
我意識到這將完成比真正需要的更多工作（解復用器再次復用），但它將確保資料包正確對齊。如果它有效且您需要消除開銷，您可能需要考慮實現更智慧的文件來源。
答案2
你很接近。 filesrc 外掛程式對它正在讀取的檔案的內容一無所知。 GStreamer 需要知道資料是傳輸流才能正確傳輸資料。雖然解復用和復用流可以完成這項工作，但還有更好的方法：
Source: gst-launch -v filesrc location=myvideo.ts ! tsparse set-timestamps=true ! udpsink host=192.168.2.100 port=1234
Dest: gst-launch udpsrc caps="video/mpegts, systemstream=(boolean)true, packetsize=(int)188" port=1234 ! tsdemux ! (video decoder) ! autovideosink
插件 tsparse 讀取流並解析出有關流的資訊。它還將其輸出標識為傳輸流。這本身可能足以滿足您的串流媒體需求，因為它允許 udpsink 知道資料位於 188 位元組資料包中。在接收端，需要 tsdemux 來解析出實際的視訊串流。元素「set-timestamps」告訴 tsparse 在傳出資料包上設定時間戳，以便 udpsink 按時發送每個幀，而不是盡可能快地發送。
您也可以使用 rtpmp2tpay 和 rptmp2depay 將資料打包以供 udpsink 發送。它還將編碼名稱設定為 MP2T。你可以嘗試兩種方法。
Source: gst-launch -v filesrc location=myvideo.ts ! tsparse set-timestamps=true ! rtpmp2tpay ! udpsink host=192.168.2.100 port=1234
Dest: gst-launch udpsrc caps="application/x-rtp, systemstream=(boolean)true, packetsize=(int)188" port=1234 ! rtpmp2tdepay ! tsdemux ! (video decoder) ! autovideosink