GStreamer-devel

Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

Classic

List

Threaded

5 messages Options

Francis Rammeloo

Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

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?).

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.

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?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Thiago Sousa Santos-2

Re: Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Mark Nauwelaerts-2

Re: Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

[hidden email] wrote:

>
>
> On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo
> <[hidden email] <mailto:[hidden email]>> 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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Francis Rammeloo

Re: Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

In reply to this post by Thiago Sousa Santos-2

2010/1/13 [hidden email] <[hidden email]>

On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Francis Rammeloo

Re: Requesting a sink pad from a muxer in the "new-decoded-pad" callback?

In reply to this post by Thiago Sousa Santos-2

2010/1/13 [hidden email] <[hidden email]>

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.

Done, id is 606859. See https://bugzilla.gnome.org/show_bug.cgi?id=606859.