消息傳輸不是0終止

當我使用rtpgstdepay depay負載，我收到警告消息作爲消息傳輸不是0終止

事件串不爲0結束。

如何解決此問題？

pipeline : gst-launch-1.0 udpsrc ! queue ! rtpgstdepay ! autovideosink 


Warning :: "event string not 0 terminated" 
Debug Info :: gstrtpgstdepay.c(331): read_event(): /GstPipeline:Transporter/GstRtpGSTDepay:rtp_depay

來源

2015-11-24 Prasanth Kumar Arisetti

你能請張貼正是你所得到的警告消息（複製粘貼 - 圍繞着一個或許有些行） – nayana

警告信息「事件字符串不是0終止」調試信息:: gstrtpgstdepay.c（331）：read_event（）：/ GstPipeline：Transporter/GstRtpGSTDepay：rtp_depay –

在新版本中，rtpgstdepay caps事件字符串應該以'0字節字符（\ 0）'結尾。對於舊版本，它應該以';（Semicolon）'結尾。

如果事件字符串未正確終止，則會出現'事件字符串不是0終止'的警告消息。

這個條件被添加來克服修復緩衝區重讀問題，並確保我們不會讀取超過緩衝區末尾的字符串。

兼容性矩陣是這樣的：

老付 - >老depay：

沒有變化，升級核心不會對某些畸形輸入崩潰。

老付 - >新depay：

新depay認定;最後解析消息。核心變更不是的事。

新的薪酬 - >老depay：

新depay串後把多餘的0。舊的depay只是解析並跳過多餘的0字節（因爲它包含在長度中）。使用新核心，某些格式錯誤的有效載荷不會崩潰。

新的薪酬 - >新depay：

新的薪酬增加了額外的0串後，新depay檢查0和解碼。新的核心將避免某些緩衝區溢出。

來源

2015-11-25 08:34:02

那麼究竟如何解決這個問題呢？您使用了哪些付款/付款元素？ – nayana

通過使用rtpgstpay & rtpgstdepay組件我通過rtp上的udp成功傳輸修改過的緩衝區。

在接收機端，

在udpsrc帽，i的上限是類型G_TYPE_STRING的加入上限事件串。

當我使用-v選項啓動此管道時，會提取caps事件字符串。

該事件字符串用於我的C代碼的udpsrc帽屬性。

來源

2015-11-28 06:32:34

消息傳輸不是0終止

回答

相關問題