I am currently testing an application that runs on 1.16 against 1.18 to see what breaks. This scenario is as follows:
* a pipeline with four bins - one per conference participant
* one "sender" bin; this bin contains webrtcbin, and the remote peer provides vp8 video, sendonly
* a "recorder" bin. This bin tees the vp8 stream from the video sender bin to a webmmux container and filesink.
* two video receiver bins (these are the viewers). These bins also contain a webrtcbin element. These bins also tee the original vp8 video stream directly (re-payloading) to webrtcbin.
This composition works just fine and N number of receiving endpoints can view the video, and the video is recorded to a file. Great.
However, sometimes the video resolution changes. The webmmux container cannot handle changing caps, so we had to jump through a few hoops. I monitor for a change in resolution, and when I see it, I install a blocking pad probe on the upstream T. In the pad block, I pause the recorder bin, remove the old webmmux and filesink elements, create new elements to a new file, unpause the bin, then remove the block. That works just lovely in 1.16. A new recording file is created every time the video changes, and it happens completely transparently to the viewers.
When tested against 1.18, the stuff with the blocking probe and the redirecting to a new file continues to work. However, now the viewing peers stop receiving video (audio continues to flow). I've cranked up GST_DEBUG but I don't see anything helpful.
Thoughts?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
