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

thiagossantos at gmail.com thiagossantos at gmail.com
Wed Jan 13 11:24:06 CET 2010


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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100113/9edb0e83/attachment.htm>


More information about the gstreamer-devel mailing list