<div dir="ltr"><div>Dear Edward, Jan and other experts,<br></div><div><br></div><div>I have a specific query. My demux plugin outputs video and audio packets (elementary streams) whereas hlsdemux outputs video and audio but in container. The gstreamer pipeline is running fine.</div><div><br></div><div>Now I want to switch audio track but number of pads would remain the same i.e. one video pad and one audio pad. And there is a change in audio codec. So that essentially means to have new audio chain.</div><div><br></div><div>As suggested by Edward Hervy on following links:</div><div><a href="https://lwn.net/Articles/661403/">https://lwn.net/Articles/661403/</a> </div><div><a href="https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2015/Edward%20Hervey%20-%20decodebin3.pdf">https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2015/Edward%20Hervey%20-%20decodebin3.pdf</a></div><div><br></div><div>There are some known issues (explained by Edward in above links) that we can not just remove audio pad and add new audio pad. We would have to create new video and audio pad, push eos on old video pad and old audio pad, remove old video pad and remove old audio pad.And then start pushing packets on the new video pad and new audio pad. Currently my gstreamer version is 1.4.5 which is based on decodebin2.</div><div><br></div><div>In such scenario just before track change:</div><div>- significant video of future timestamps is already buffered in the video chain (old chain)</div><div>- significant audio of future timestamps is already buffered in the audio chain  (old chain)</div><div><br></div><div>Now when switching to push buffers on new pads, for audio case, we have capability to "rewind" the PTS as per the current presentation time. But for video case, the video packets would have timestamps which is much ahead as compared to audio. I'm not sure if hlsdemux also rewinds the video when it performs the track switch ? </div><div><br></div><div>I think it will create problem at synchronisation stage when video is much ahead. </div><div>How such issues are handled at hlsdemux or inside any other demux plugin  </div><div>which perform decode group switch ? Do they also "rewind" video before pushing on video chain ?</div><div><br></div><div>Do we need to also FLUSH <b>old </b>video and audio chains also before start pushing buffers on <b>new </b>video and audio pad ?<br></div><div><br></div><div>Now we also have a situation when there is no codec change we are trying to flush audio without removing audio pad and observing synchronization issues:</div><div>Please have a look at, <a href="http://gstreamer-devel.966125.n4.nabble.com/a-v-freeze-while-flushing-audio-chain-of-pipeline-in-running-state-clock-and-renderer-sync-related-td4683168.html">http://gstreamer-devel.966125.n4.nabble.com/a-v-freeze-while-flushing-audio-chain-of-pipeline-in-running-state-clock-and-renderer-sync-related-td4683168.html</a></div><div>and suggest how we can address this behaviour.<br></div><div><br></div><div>In both cases we would not intend to flush video. Is there any specific requirement to flush video also to handle a/v freeze..</div><div><br></div><div>Kindly share your expert insights to help with decodebin2 based audio track switch with single audio pad that outputs elementary stream.</div><div><br></div><div>Thanks</div><div>--Nitin</div></div>