2

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

并发送到流插件。正如你所看到的，这里没有转码，只是depayloading和payloading。生成的视频在某些关键帧上分解为伪影，大约在 10 个关键帧中出现一次，只能在下一个关键帧上修复。

如果我删除 depay and pay，只需在 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 之间波动。

4

1 回答 1

2

这是修复：

rtpjitterbuffer 延迟=50 ！

在 rtpvp8depay 之前。

从逻辑上讲，此时数据包的顺序与通过互联网在发送浏览器和 Janus 之间传递的数据包的顺序相同。如果我们不 depay+pay，它会以相同的方式连接到 Streaming 插件的接收浏览器，并且它有自己的抖动缓冲区，因此能够修复顺序，但是如果我们在这里 depay+pay，则没有缓冲区所以这些数据包被丢弃，导致帧损坏。

是的，我找回了转码和我的所有其他管道以及所有其他花里胡哨的东西，它仍然可以正常工作。

于 2019-09-21T01:46:07.017 回答