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

[BillBock]

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
bbock at digitalforcetech.com <mailto:sdu at digitalforcetech.com> 
www.digitalforcetech.com <http://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:ml-node+2550857-789378914-161056 at n4.nabble.com] 
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: 


> 
> 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



________________________________

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 <http://gstreamer-devel.966125.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=2547757&code=YmJvY2tAZGlnaXRhbGZvcmNldGVjaC5jb218MjU0Nzc1N3wxMjc0NDA1MzU=> . 

 


-- 
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Stopping-and-restarting-complicated-pipeline-with-muxing-tp2547757p2715527.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100927/7242532e/attachment.htm>