dynamically audio elements remove issue

[Leslie Li]

Hi all,

I have a pipeline like this:

v4l2src->caps->h264enc->v_tee->
                                                           qtmux->filesink
alsasrc->queue->caps->faac->a_tee->

I have set an event_probe on qtmux src pad, if I press stop button on ui, I will do the following stuff:

1. send eos on qtmux video_00 and audio_00 sink pads
2. then received a event in event_probe callback, in the callback, I unlink v_tee src0 pad from video_00,
    remove v_tee src0; unlink a_tee src0 from audio_00, remove a_tee src0; remove event_probe of qtmux src pad
    then generate an application message, to wake up application thread
3. in application thread, after done step 1, I use a gst_bus_poll on pipeline bus to wait for a application message
     coming, after get the message, I set qtmux and filesink to NULL state, then remove them from pipeline;
     set pipeline state to PAUSED,
     set v_tee, h264enc... video elements to NULL state, then remove them out of pipeline;
     set a_tee, alsasrc...audio elements to NULL state, before this step, I have checked that v_tee and a_tee  
     have none src pad on it, but, sometimes, the application thread will block forever if I do
     gst_element_set_state(alsasrc, GST_STATE_NULL), the same thing happens on a_tee or any element in audio
     path, but video path are always ok and never get any blocking. This happens only sometimes, I guess that the
     time I press stop button, the alsa path maybe in some special state, so it will block.

my requirement is to make up a multitask pipeline, and it can split video/audio encoded stream into rtp and/or qtmux on demand, after talking with nice guys in IRC for days, I got the above solution, but the audio path seems still having problem with it, any suggestion will be very appreciated, and if there is another more effective and reasonable solution, that will be great.

Leslie

[Stefan Sauer]

On 12/11/2011 05:44 AM, Leslie Li wrote:

> Hi all,
>
> I have a pipeline like this:
>
> v4l2src->caps->h264enc->v_tee->
>                                                            qtmux->filesink
> alsasrc->queue->caps->faac->a_tee->
>
> I have set an event_probe on qtmux src pad, if I press stop button on ui, I
> will do the following stuff:
>
> 1. send eos on qtmux video_00 and audio_00 sink pads
> 2. then received a event in event_probe callback, in the callback, I unlink
> v_tee src0 pad from video_00,
>     remove v_tee src0; unlink a_tee src0 from audio_00, remove a_tee src0;
> remove event_probe of qtmux src pad
>     then generate an application message, to wake up application thread
> 3. in application thread, after done step 1, I use a gst_bus_poll on
> pipeline bus to wait for a application message
>      coming, after get the message, I set qtmux and filesink to NULL state,
> then remove them from pipeline;
>      set pipeline state to PAUSED,
>      set v_tee, h264enc... video elements to NULL state, then remove them
> out of pipeline;
>      set a_tee, alsasrc...audio elements to NULL state, before this step, I
> have checked that v_tee and a_tee  
>      have none src pad on it, but, sometimes, the application thread will
> block forever if I do
>      gst_element_set_state(alsasrc, GST_STATE_NULL), the same thing happens
> on a_tee or any element in audio
>      path, but video path are always ok and never get any blocking. This
> happens only sometimes, I guess that the
>      time I press stop button, the alsa path maybe in some special state, so
> it will block.

Try to get backtraces in gdb to see where it stalls when it does. Also
it might be a good idea to make a test-app where you try to simplify it
as much as possible (ideally everything in one file).

Stefan

> my requirement is to make up a multitask pipeline, and it can split
> video/audio encoded stream into rtp and/or qtmux on demand, after talking
> with nice guys in IRC for days, I got the above solution, but the audio path
> seems still having problem with it, any suggestion will be very appreciated,
> and if there is another more effective and reasonable solution, that will be
> great.
>
> Leslie
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/dynamically-audio-elements-remove-issue-tp4182031p4182031.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel