<br><br><div class="gmail_quote">2010/1/13 <a href="mailto:thiagossantos@gmail.com">thiagossantos@gmail.com</a> <span dir="ltr"><<a href="mailto:thiagossantos@gmail.com">thiagossantos@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br><br><div class="gmail_quote"><div class="im">On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo <span dir="ltr"><<a href="mailto:francis.rammeloo@gmail.com" target="_blank">francis.rammeloo@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>I would like to create a pipeline that takes an WMV file and converts it into a MP4 (H264 + AAC) file. The WMV file contains an unknown number of video and audio streams (usually around 4 video streams, and 20-30 audio streams). Because the number of streams is not known I can't use gst-launch (I think?).</div> </blockquote><div><br></div></div><div>This is an interesting use case and it would be good if it worked IMHO.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><br></div>My initial approach was to use a decodebin2 and link each decoded pad (in the new-decoded-pad callback) to an audio/video encoder element and then link the encoder element to a newly request sink pad of the muxer. However, this led to internal dataflow errors. Apparently (<a href="http://n4.nabble.com/ffmux-mp4-audio-signal-not-emitted-td970892.html#a970892" target="_blank">http://n4.nabble.com/ffmux-mp4-audio-signal-not-emitted-td970892.html#a970892</a>) you can't request a sink pad once the muxer has been initialized.</blockquote> <div><br></div></div><div>qtmux/mp4mux is recommended over ffmux_mp4.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <br></div><div>The solution seems to be to request all sink pads before setting the pipeline to play state. But the problem is that I don't know how many streams there will be in the video file.</div><div><br></div><div> So before I start messing with workarounds, I'd thought I ask the mailing list first. Can someone help me solve this problem?</div></blockquote><div><br></div><div><br></div></div><div>Most muxers doesn't accept new pad requests after they start receiving data (which not necessarily happens when they switch to PLAYING state). AFAIK the asfdemux (that is being used internally on decodebin2) would add all its pads before pushing any data, but decodebin2 waits till a buffer is pushed on each pad of that to expose it, the problem is likely to be related to this.</div> <div> </div><div>Please file a bug with a sample file and possibly an application that reproduces the problem, this is a valid use case and should work.</div><div><br></div></div></blockquote><div><br></div><div>Ok.</div> <div><br></div><div>FYI my current workaround is to use a 2-step mechanism. First create the pipeline containing only the filesrc and decodebin2 and set it to playing. For each new decoded pad I increase a counter variable. When I receive the no-more-pads event I post a quit message to the main loop. Back in the main function (after the main loop exit) I know how many streams are needed so I can setup my muxer properly and start the main loop again.</div> <div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><br></div><div>Grts,</div><div>Francis</div> <br>------------------------------------------------------------------------------<br> This SF.Net email is sponsored by the Verizon Developer Community<br> Take advantage of Verizon's best-in-class app development support<br> A streamlined, 14 day to market process makes app distribution fast and easy<br> Join now and get one step closer to millions of Verizon customers<br> <a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a> <br>_______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.sourceforge.net" target="_blank">gstreamer-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br> <br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>Thiago Sousa Santos<br> </font><br>------------------------------------------------------------------------------<br> This SF.Net email is sponsored by the Verizon Developer Community<br> Take advantage of Verizon's best-in-class app development support<br> A streamlined, 14 day to market process makes app distribution fast and easy<br> Join now and get one step closer to millions of Verizon customers<br> <a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a> <br>_______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br> <br></blockquote></div><br>