observing problems with dynamic pipeline (gstreamer version 1.4.5)

Nitin Mahajan rise.era at gmail.com
Fri Apr 28 13:57:33 UTC 2017


Hello,

I'm facing some problem while playing with gstreamer dynamic pipelines.
Need your help / suggestions based on below scenario:

I have a gstreamer demuxer plugin (not native plugin) with 1 video and 1
audio pad.
This plugin has 2 source pads: video pad, audio pad.
For each pad there is dedicated gst_buffer_pool allocated which
containd pool of buffers to host Video and Audio ES post demuxing.
A/V playback is working OK

Based on requirement, demuxer has to switch to another audio present in the
container (MP4) at run time when gstreamer pipeline is in playing state.

Now demux has to switch to another another as mentioned above which has
different codec type. So following the dynamic pipeline principle,
following steps are done in sequence:
While injection to demux video pad is ongoing (I understand that it should
be ok to let continue video inject because we are considering deletetion
and creation of audio only chain) ,
older audio pad is removed by following below steps:
1. gst_pad_push_event (audio_stream->pad, gst_event_new_flush_start ());
2. gst_pad_push_event (audio_stream->pad, gst_event_new_flush_stop (TRUE));
3. gst_pad_push_event (audio_stream->pad, gst_event_new_eos ());
4. Flush the buffer pool associated associated with audio stream
5. gst_element_remove_pad (xx, audio_stream->pad);
6. gst_element_no_more_pads (xx);

And then a new audio pad is created with following operations
1. gst_pad_set_active pad
2. gst_pad_use_fixed_caps
3. gst_pad_push_event gst_event_new_stream_start
4. gst_pad_set_caps pad
5. gst_element_add_pad
6. new segment event
7. caps event
8. push buffers

gstreamer version: 1.4.5

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.

But the observations are different !!!
Video is stalled for some time when older audio pad is deleted and new
audio pad is created.
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.
And the pipeline dump gives an idea that older chain is still not deleted
and new chain is not built yet.

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,
This pad is connected with Gstaacparse src pad but the chain meets dead end
at this stage !!!!

gst_pad_push() is always successful on new audio pad. The buffers which are
pushed on audio pad are allocated from buffer pool.


Kindly suggest your opinion on handling this dynamic pipeline scenario.
Any suggestions for debugging will be helpful

Thanks
Nitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170428/314885d3/attachment.html>


More information about the gstreamer-devel mailing list