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

[Mark Nauwelaerts]

thiagossantos at gmail.com wrote:
> 
> 
> On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo 
> <francis.rammeloo at gmail.com <mailto: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.

A muxer starts collecting data once it is set to PAUSED.
A 'trick' is to keep the muxer in locked state (READY or so), and to request new 
pads while it is in this state.  When all streams are ready (no-more-pads has 
been indicated by decodebin2 or so), then unlock the muxer state (and set it to 
e.g. PAUSED).

[examples of this technique can likely be found in e.g. entrans or transmageddon 
application]

Mark.