[gst-devel] Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

[Francis Rammeloo]

2010/1/13 thiagossantos at gmail.com <thiagossantos at gmail.com>

>
>
> On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo <
> francis.rammeloo at gmail.com> wrote:
>
>> 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?).
>>
>
> This is an interesting use case and it would be good if it worked IMHO.
>
>
>>
>> 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 (
>> http://n4.nabble.com/ffmux-mp4-audio-signal-not-emitted-td970892.html#a970892)
>> you can't request a sink pad once the muxer has been initialized.
>
>
> qtmux/mp4mux is recommended over ffmux_mp4.
>
>
>>
>> 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.
>>
>> So before I start messing with workarounds, I'd thought I ask the mailing
>> list first. Can someone help me solve this problem?
>>
>
>
> 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.
>
> 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.
>
>
Ok.

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.



>> Grts,
>> Francis
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
>
>
> --
> Thiago Sousa Santos
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100113/55ffe51c/attachment.htm>