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?).
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 |
On Tue, Jan 12, 2010 at 12:38 PM, Francis Rammeloo <[hidden email]> wrote:
This is an interesting use case and it would be good if it worked IMHO.
qtmux/mp4mux is recommended over ffmux_mp4.
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.
-- 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 |
[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 |
In reply to this post by Thiago Sousa Santos-2
2010/1/13 [hidden email] <[hidden email]>
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.
------------------------------------------------------------------------------ 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 |
In reply to this post by Thiago Sousa Santos-2
2010/1/13 [hidden email] <[hidden email]>
Done, id is 606859. See https://bugzilla.gnome.org/show_bug.cgi?id=606859.
------------------------------------------------------------------------------ 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 |
Free forum by Nabble | Edit this page |