Video streaming 使用GStreamer的单个MPEG-TS流中的双H264视频：音频/视频同步？

对于一个研究原型，我需要在一个可流化的容器中有两个同步的高清视频流和一个音频流，以便进行实时通信（基本上是Skype和一个附加的二级视频流）。我发现的唯一一种按预期工作的容器格式是MPEG-TS。我有两个工作管道，我根据各种示例将它们组合在一起，但有许多事情我还没有完全理解。首先，管道：

发送方管道（以videotestsrc作为代理）：

接收管道：

gst-launch-1.0 -ve udpsrc port=5000 ! application/x-rtp, media=video, clock-rate=90000, encoding-name=MP2T ! rtpjitterbuffer ! rtpmp2tdepay ! tsparse ! tsdemux name=mux \
    mux. ! h264parse ! queue leaky=downstream ! avdec_h264 ! videoconvert ! fpsdisplaysink sync=false \
    mux. ! h264parse ! queue leaky=downstream ! avdec_h264 ! videoconvert ! fpsdisplaysink sync=false \
    mux. ! queue leaky=downstream ! opusdec ! autoaudiosink sync=false

此设置生成大约500kb/s的网络流量，这非常接近预期值，在本地主机上运行良好。我正在使用Pulseaudio的echo插件进行回声消除，所以这也包括在内

我以前的大多数问题（见下文）现在已经通过a）在发送方使用RTP内部的MPEG2-TS，在接收方使用

rtpjitterbuffer

，以及b）在任何地方使用

队列泄漏=下游

解决。根据Florian Zwoch的建议，我还从x264enc中删除了内部刷新

现在唯一剩下的问题是，我在音频和视频之间有一个恒定但不可预测的偏移量。偶尔，它几乎同步，也保持同步，但在其他情况下，它会关闭1-2秒，这足以让人恼火。我想我可以通过调整队列参数来解决这个问题

---

保留供存档的原始问题集：

当实际在两台独立机器之间使用真实网络时（信号强度接近100%的高带宽WiFi），质量会大幅下降。似乎没有任何明显的数据包丢失，500 kB/s的无线网络连接速度也不算太高。有什么好处

接收方的队列元素的具体功能是什么？如果我设置了最大尺寸。。。属性设置为0，那么它们将无限期地缓冲

即使在功能相当强大的机器上，发送方也会不断发出警告-8 kBit/s音频编码器怎么会“落后”

---

质量下降到底意味着什么？您是否了解正在设置的

x264enc

选项？这真的是你想要的吗。是的，但是如果您的意图是使时间无限，那么您就缺少了时间变量。它们的另一个用途是添加从解复用器获取数据的线程，这样您就不会遇到死锁。质量：一旦有移动，就几乎变得无法识别的阻塞。通过添加

rtpmp2t[de]mux

元素，我看到了显著的改进；我认为问题在于MPEG-TS无法自行解决的数据包重新排序问题。x264enc选项：我知道除帧内刷新外，大多数选项都没有得到解决（但这显然是针对流媒体场景的建议）。LBNL，队列：我已切换到接收方的

队列泄漏=下游

，现在可以可靠地停止和重新启动发送器和接收器。还在想我是否也应该在发送方添加这些内容？

gst-launch-1.0 -ve udpsrc port=5000 ! application/x-rtp, media=video, clock-rate=90000, encoding-name=MP2T ! rtpjitterbuffer ! rtpmp2tdepay ! tsparse ! tsdemux name=mux \
    mux. ! h264parse ! queue leaky=downstream ! avdec_h264 ! videoconvert ! fpsdisplaysink sync=false \
    mux. ! h264parse ! queue leaky=downstream ! avdec_h264 ! videoconvert ! fpsdisplaysink sync=false \
    mux. ! queue leaky=downstream ! opusdec ! autoaudiosink sync=false

WARNING: from element /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(849): gst_audio_base_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 1600 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.