[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