GStreamer-devel

Stopping and restarting complicated pipeline with muxing

Classic

List

Threaded

3 messages Options

BillBock

Stopping and restarting complicated pipeline with muxing

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.

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.

Stefan Sauer

Re: Stopping and restarting complicated pipeline with muxing

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.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

BillBock

RE: Stopping and restarting complicated pipeline with muxing

Stefan:

Thanks for the response. I took a look at output-selector and input-selector. I haven’t tried using them yet, but they did point me in some directions I hadn’t considered before. For example, I’m now being much more careful to ensure that only the elements (especially sinks) that I want to see EOS signals get to see them. After making several changes, I’ve gotten video streaming, video capturing (with muxed audio), and image capturing all working simultaneously and successively.

The next few steps are to get audio streaming and audio capturing working alongside the above. However, since I’m using an H.264 encoder for the video stuff, I found that I need to make sure that I store the first SPS/PPS frame so that I can apply it to future IDR frames when doing streaming after video capturing has already begun. This isn’t a GStreamer problem, although I will be solving it with GStreamer by modifying a plugin to do the frame modification work for me.

Thanks,

Bill Bock
Software Engineer
Digital Force Technologies
9455 Waples Street, Suite #100
San Diego, CA 92121
Phone: (858) 546-1244
Fax: (858) 597-1750
[hidden email]
www.digitalforcetech.com

******************************************************
CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute, and delete the original message. Please notify the sender by E-Mail at the address shown. Thank you for your compliance.

From: Stefan Kost [via GStreamer-devel] [mailto:[hidden email]]
Sent: Wednesday, September 22, 2010 11:35 AM
To: Bill Bock
Subject: Re: Stopping and restarting complicated pipeline with muxing

Am 21.09.2010 01:23, schrieb BillBock:

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

View message @ http://gstreamer-devel.966125.n4.nabble.com/Stopping-and-restarting-complicated-pipeline-with-muxing-tp2547757p2550857.html
To unsubscribe from Stopping and restarting complicated pipeline with muxing, click here.