<div dir="ltr"><span style="font-size:12.8px">Hello folks,</span><div style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">I'm facing some problem while playing around with with dynamic pipelines.</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Need your help / suggestions based on below scenario in case observer something wrong in approach.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">I have a gstreamer demuxer plugin (not the standard plugin) with 1 video and 1 audio pad.</span><br style="font-size:12.8px"><span style="font-size:12.8px">This plugin has 2 source pads: video pad, audio pad. (always 2 pads, doesn't have multiple audio pads per stream as per regular demuxers)</span></div><div style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">For each pad there is dedicated gst_buffer_pool allocated which contains pool of buffers to host Video and Audio ES post demuxing. In this configuration A/V playback is working OK (the pipeline is constructed with playbin)</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Now on top of this I have to support <span style="font-size:12.8px">switching to another audio stream present in the container (MP4) at run time when gstreamer pipeline is in playing state (with same reason as explained above that number of src pads is fixed)</span></div><div style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">demux has to switch to another audio stream as mentioned above which has <b>different </b>codec type. So following the dynamic pipeline principles, following steps are done in sequence to attain this objective:</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">While injection to demux video pad is ongoing (I guess it should be ok to let continue video inject because we are considering deletion and creation of new src pad for audio only chain) ,</span><span style="font-size:12.8px">older audio pad is removed by following below steps: </span><br style="font-size:12.8px"></div><div style="font-size:12.8px"><span style="font-size:12.8px">flush the pipeline, send eos event and remove pad followed by no more pad notification:</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">1. gst_pad_push_event (audio_stream->pad, gst_event_new_flush_start ());</span><br></div><div style="font-size:12.8px"><span style="font-size:12.8px">2. gst_pad_push_event (audio_stream->pad, gst_event_new_flush_stop (TRUE));</span><br style="font-size:12.8px"><span style="font-size:12.8px">3. gst_pad_push_event (audio_stream->pad, gst_event_new_eos ());</span><br style="font-size:12.8px"><span style="font-size:12.8px">4. Flush the buffer pool associated associated with audio stream</span><br style="font-size:12.8px"><span style="font-size:12.8px">5. gst_element_remove_pad (xx, audio_stream->pad);</span><br style="font-size:12.8px"><span style="font-size:12.8px">6. gst_element_no_more_pads (xx);</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">And then a new audio pad is created with following operations</span><br style="font-size:12.8px"><span style="font-size:12.8px">1. gst_pad_set_active pad</span><br style="font-size:12.8px"><span style="font-size:12.8px">2. gst_pad_use_fixed_caps</span><br style="font-size:12.8px"><span style="font-size:12.8px">3. gst_pad_push_event gst_event_new_stream_start</span><br style="font-size:12.8px"><span style="font-size:12.8px">4. gst_pad_set_caps pad</span><br style="font-size:12.8px"><span style="font-size:12.8px">5. gst_element_add_pad</span><br style="font-size:12.8px"><span style="font-size:12.8px">6. new segment event</span><br style="font-size:12.8px"><span style="font-size:12.8px">7. caps event</span><br style="font-size:12.8px"><span style="font-size:12.8px">8. push buffers</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">gstreamer version: 1.4.5</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Note that all above steps are done in sequence and in same thread context which we can call as streaming thread as per gstreamer design. Being sequential operations there is no possibility to push buffers or events on audio stream src pad (old and then new) from any other thread.</div><div style="font-size:12.8px">But during this period I have another thread which keeps on pushing the buffers on video src pad (which although little different from standard gstreamer streaming thread concept but since the ongoing operations are on audio stream pad so it should not create problem .. problem with buffer timestamps in case ?<br><br style="font-size:12.8px"><span style="font-size:12.8px">The expectation was, after above steps, we can inject audio buffers on new audio pad and overall there should be just change in audio stream with no problem on video.</span><br style="font-size:12.8px"><span style="font-size:12.8px">But the observations are not as per expectation !!!!</span></div><div style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Video is stalled for some time when older audio pad is deleted and new audio pad is created.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Thereafter video playback is fine but there is no audio and from demux perspective audio packets are pushed without any error on new audio pad.</span><br style="font-size:12.8px"><span style="font-size:12.8px">And the pipeline dump gives an idea that older chain is still not deleted and new chain is not built yet.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Taking dump of GST pipeline it seems that older pipeline is not deleted and new pipeline from new audio pad is partially created upto proxypad16 inside decodebin,</span><br style="font-size:12.8px"><span style="font-size:12.8px">This pad is connected with Gstaacparse src pad but the chain meets dead end at this stage !!!!</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">gst_pad_push() is always successful on new audio pad. The buffers which are pushed on audio pad are allocated from buffer pool.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Any suggestions for debugging will be helpful especially with dynamic pipeline management (gstreamer 1.4.5)</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Thanks</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Nitin</span></div></div>