[gst-devel] Stopping and restarting complicated pipeline with muxing

Stefan Kost ensonic at hora-obscura.de
Wed Sep 22 20:35:36 CEST 2010


Am 21.09.2010 01:23, schrieb BillBock:
> 
> All:
> 
>  I’m hoping my issue is some kind of basic misunderstanding of GStreamer
> design philosophy.  I have an application with a fairly complicated
> pipeline.  The pipeline has two sources, v4l2src and alsasrc.  It can do
> simultaneous video capture (without muxing audio), video streaming (using
> tcpsink), individual frame capture, audio capture, and audio streaming.  The
> various branches of the pipeline all end at fakesinks.
> 
>  If I want to capture video, I block the src pads of v4l2src and alsasrc,
> unlink stuff, insert an encoder element, a muxer element, and a filesink
> element, link them to the pipeline, set them to playing, and unblock the src
> pads.  When I’m ready to stop capturing, I again block the src pads, unlink
> and relink elements so that the encoder, muxer, and filesink are linked to
> each other, but not to the rest of the elements in the pipeline, send an EOS
> to the encoder, unlink and set the elements to null, remove them from the
> pipeline, link stuff back to a fakesink, and unblock the src pads.  I do
> similar things with the other functions.  Everything works great
> (simultaneously and successively) without general stream errors or internal
> data flow errors.

I see nothing obviosly wrong. Just as a suggestion to avoid the pad-blocking and
relinking bussiness, would using output-selector work for you?

Stefan

> 
>  It’s when I try to do muxing that I have issues.  It will usually work the
> first time, except that when unblocking the src pads after reconfiguring the
> pipeline to end in fakesinks again when done with capture, no more buffers
> pass through the video source.
> 
>  If I strip down the pileline to simplify it and only do muxing of video and
> audio (so, no tee elements at all in the pipeline, for example) then
> successive capturing of muxed video and audio works.  I’ve done up to 30
> captures in a row.  Whenever I stop capturing in this case, I have to send
> the EOS events on the video and and audio encoders before blocking the video
> and audio src pads (so I also don’t unlink/relink stuff so that section of
> the pipeline is off by itself).  I always get a couple general stream errors
> in this case, but everything continues to work afterwards and I can start
> and stop again, over and over.
> 
>  I’m hoping for suggestions as to what I’m doing wrong.  I’d be happy to
> post code if that would help.





More information about the gstreamer-devel mailing list