<div dir="ltr">I am currently testing an application that runs on 1.16 against 1.18 to see what breaks. This scenario is as follows:<div>* a pipeline with four bins - one per conference participant</div><div>* one "sender" bin; this bin contains webrtcbin, and the remote peer provides vp8 video, sendonly</div><div>* a "recorder" bin. This bin tees the vp8 stream from the video sender bin to a webmmux container and filesink. </div><div>* 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. </div><div><br></div><div>This composition works just fine and N number of receiving endpoints can view the video, and the video is recorded to a file. Great.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Thoughts? </div></div>