VP8 流来自 Janus Videoroom 插件，在本地重流到 10002/10004。从那里，它通过以下 gstreamer 管道拾取：
gst-launch-1.0 -v udpsrc
caps="application/x-rtp,media=(string)video,encoding-name=(string)VP8,payload=100"
address=127.0.0.1 port=10004 !
rtpvp8depay ! rtpvp8pay !
udpsink host=127.0.0.1 port=5004
并发送到流媒体插件。如您所见，这里没有转码，只是去有效载荷和有效载荷。生成的视频在某些关键帧上分解为伪影，大约每 10 个关键帧中一次，仅在下一个关键帧上固定。
如果我删除 Depay 并付款，只需在 RTP 级别转发即可获得此内容
gst-launch-1.0 -v udpsrc
caps="application/x-rtp,media=(string)video,encoding-name=(string)VP8,payload=100"
address=127.0.0.1 port=10004 !
udpsink host=127.0.0.1 port=5004
它永远不会发生。
我知道这不是 Janus 问题，而是 gstreamer 问题。 但也许有人知道可能是什么问题？ 这已经过非常可靠的测试，在前一种情况下，问题很容易重现，而在后一种情况下永远不会发生。
当然，我正在做的事情的目标是转码，在我将其归结到这个级别之前，设置和管道中还有很多。在安装在具有所有开箱即用设置的全新 Ubuntu 18.04 机器上的 Janus 上复制。
更新：
export GST_DEBUG="rtp*:4";
显示此错误消息，每次出现伪影时都会丢失：
rtpbasedepayload gstrtpbasedepayload.c:473:gst_rtp_base_depayload_handle_buffer:
<rtpvp8depay0> 12 <= 100, dropping old packet
"12"的数字通常在 5 到 12 之间波动。
这是修复：
RTPJitterbuffer 延迟 = 50 ！
在RTPVP8depay之前。
从逻辑上讲，此时数据包的顺序与发送浏览器和Janus之间通过互联网的顺序相同。如果我们不 depay+pay，它与连接到 Streaming 插件的接收浏览器的方式相同，并且它有自己的抖动缓冲区，因此能够固定顺序，但是如果我们在这里做 depay+pay，则没有缓冲区，因此这些数据包被丢弃，在损坏的帧中绝缘。
是的，我找回了转码和我管道的所有其他部分以及周围的所有其他花里胡哨的东西，它仍然工作正常。