<br><br><div class="gmail_quote">On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo <span dir="ltr"><<a href="mailto:francis.rammeloo@gmail.com">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>This is an interesting use case and it would be good if it worked IMHO.</div><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>qtmux/mp4mux is recommended over ffmux_mp4.</div><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>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><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">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><br clear="all"><br>-- <br>Thiago Sousa Santos<br>