Webrtc Gstreamer：如何在不重新编码的情况下将rtpvp8depay导入webmmux？

从提供Webrtc的浏览器中，我收到一个RTP流，该流使用janus网关进行解密。在仅接收到视频rtp数据包时，将其中继到本地多播组以进行测试

所以，假设我在udp端口上接收到vp8编码的rtp数据包。我还可以随时请求新的关键帧

问题在于：

gst-launch-1.0 -v -v -v -v udpsrc multicast-group=224.1.1.1 auto-multicast=true port=1235 ! "application/x-rtp, payload=100, clock-rate=90000" ! rtpvp8depay ! webmmux streamable=true ! filesink location=/tmp/test.webm

产生错误

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = "application/x-rtp\,\     payload\=\(int\)100\,\ clock-rate\=\(int\)90000\,\ media\=\(string\)video\,\ encoding-name\=\(string\)VP8-DRAFT-IETF-01"
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps = "video/x-vp8\,\ framerate\=\(fraction\)0/1"
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps = "application/x-rtp\,\ payload\=\(int\)100\,\ clock-rate\=\(int\)90000\,\ media\=\(string\)video\,\ encoding-name\=\(string\)VP8-DRAFT-IETF-01"
ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 0:00:00.039571113
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstWebMMux:webmmux0.GstPad:src: caps = video/webm
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Kurento项目提供了一个名为“vp8parse”的gstreamer插件，它解决了以下问题：

gst-launch-1.0 -v -v -v -v udpsrc multicast-group=224.1.1.1 auto-multicast=true port=1235 ! "application/x-rtp, payload=100, clock-rate=90000" ! rtpvp8depay ! vp8parse ! webmmux streamable=true ! filesink location=/tmp/test.webm
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = "application/x-rtp\,\ payload\=\(int\)100\,\ clock-rate\=\(int\)90000\,\ media\=\(string\)video\,\ encoding-name\=\(string\)VP8-DRAFT-IETF-01"
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps = "video/x-vp8\,\ framerate\=\(fraction\)0/1"
/GstPipeline:pipeline0/KmsVp8Parse:kmsvp8parse0.GstPad:src: caps = "video/x-vp8\,\ framerate\=\(fraction\)0/1"
/GstPipeline:pipeline0/KmsVp8Parse:kmsvp8parse0.GstPad:sink: caps = "video/x-vp8\,\ framerate\=\(fraction\)0/1"
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps = "application/x-rtp\,\ payload\=\(int\)100\,\ clock-rate\=\(int\)90000\,\ media\=\(string\)video\,\ encoding-name\=\(string\)VP8-DRAFT-IETF-01"
HERE THE PIPELINE BLOCKS UNTIL A KEYFRAME IS RECEIVED
/GstPipeline:pipeline0/KmsVp8Parse:kmsvp8parse0.GstPad:src: caps = "video/x-vp8\,\ width\=\(int\)640\,\ height\=\(int\)480\,\ framerate\=\(fraction\)10/1"
/GstPipeline:pipeline0/GstWebMMux:webmmux0.GstMatroskamuxPad:video_0: caps = "video/x-vp8\,\ width\=\(int\)640\,\ height\=\(int\)480\,\ framerate\=\(fraction\)10/1"
/GstPipeline:pipeline0/GstWebMMux:webmmux0.GstPad:src: caps = video/webm
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/webm
/GstPipeline:pipeline0/GstWebMMux:webmmux0.GstPad:src: caps = "video/webm\,\ streamheader\=\(buffer\)\<\ 1a45dfa301000000000000104282857765626d0042878102428581021853806701ffffffffffffff1549a96601000000000000502ad7b1830f42404d809f4753747265616d657220706c7567696e2076657273696f6e20312e342e31005741994753747265616d6572204d6174726f736b61206d7578657200446188062408b80e88c4001654ae6b010000000000003cae0100000000000033d7810183810173c588786b225315e5f279536e86566964656f00e00100000000000008b0820280ba8201e08686565f56503800\ \>"
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = "video/webm\,\ streamheader\=\(buffer\)\<\ 1a45dfa301000000000000104282857765626d0042878102428581021853806701ffffffffffffff1549a96601000000000000502ad7b1830f42404d809f4753747265616d657220706c7567696e2076657273696f6e20312e342e31005741994753747265616d6572204d6174726f736b61206d7578657200446188062408b80e88c4001654ae6b010000000000003cae0100000000000033d7810183810173c588786b225315e5f279536e86566964656f00e00100000000000008b0820280ba8201e08686565f56503800\ \>"

但是使用vp8dec！vp8enc显然没有多大意义，因为我已经收到了一个vp8编码流

现在我的问题是，如何在不重新编码流和不依赖vp8parse的情况下解决这个问题？如果没有其他选择，我似乎不得不使用它，但由于这是目前无法通过标准gstreamer插件包获得的插件，我希望避免这种情况。是否可以强制将封口设置为特定的宽度、高度和帧速率，以便webmmux不会抱怨？因为我认为这就是为什么第一条管道没有谈判的原因

我试着使用像rtpvp8depay这样的capsfilter！capsfilter caps=“视频/x-vp8，宽度=640，高度=480，帧速率=10/1”！webmmux，但它也不协商。

这是一个bug，已经在上游修复了， 但是您系统中的Gstreamer版本可能很旧 （Ubuntu 14.04中的1.2.4）仍然受到影响

在这些旧版本中，作为一种变通方法， 如果你知道视频的帧大小 可以在depayloader之后使用元素 要手动设置拒付加载器未命中的上限，请执行以下操作：

gst-launch-1.0 -v \
  udpsrc multicast-group=224.1.1.1 auto-multicast=true port=1235 \
  ! "application/x-rtp, payload=100, clock-rate=90000" \
  ! rtpvp8depay ! capsetter caps="video/x-vp8,width=640,height=480" \
  ! webmmux streamable=true ! filesink location=/tmp/test.webm

---

你为什么反对使用Kurento的插件？之所以会出现这种情况，是因为Chrome出于带宽原因动态更改vp8比特流，而我发现纠正这种情况的方法是您已经提出的两种解决方案（使用该元素或重新编码流）。插件可以工作但强制使用CAP却不能工作的部分原因是，它从关键帧读取值并动态设置CAP，以便协商可以工作。安装capsfilter并不能做到这一点。我不确定我是否正确理解这一点。这是否意味着，我可以使用capsfilter将帧速率设置为一个固定值，该值可能会工作几秒钟，然后由于chrome可能会更改流而中断？如果是，为什么在接收udp数据包时管道会立即中断？它不会等待一个关键帧。你的问题：主要是出于兴趣，我试图了解编解码器、浏览器、gstreamer和kurento插件是如何协同工作的。我希望能找到一个简单的解决方案，帮助更好地理解非kurento插件工作流。问题不仅仅在于帧率，还在于图片分辨率会在运行中发生变化。

gst-launch-1.0 -v \
  udpsrc multicast-group=224.1.1.1 auto-multicast=true port=1235 \
  ! "application/x-rtp, payload=100, clock-rate=90000" \
  ! rtpvp8depay ! capsetter caps="video/x-vp8,width=640,height=480" \
  ! webmmux streamable=true ! filesink location=/tmp/test.webm