GNOME Bugzilla – Bug 392534
ffdemux enhancement: push based scheduling
Last modified: 2009-01-27 10:41:36 UTC
Subject says it all, see patch for push-based scheduling support for ffdemux (as well as a few other fixes/additions).
Created attachment 79340 [details] [review] Patch for push-based scheduling support for ffdemux - Push-based scheduling support for ffdemux - ffmpeg now uses YUV4MPEG version 2 rather than version 1 - Make the ffdemux loop check the result of gst_pad_push and act accordingly (e.g. ignore some unlinked pad, but give up when all unlinked)
Created attachment 79370 [details] [review] Addendum to patch Oops, I forgot to include a new header file in the previous patch. It is added in this one, which should be combined with the previous one to get the "whole picture".
Will have a look at this later, put next time please check an existing bug hasn't already been created : #385882
*** Bug 385882 has been marked as a duplicate of this bug. ***
Mark, several remarks. * Split up the various fixes in different patches (one for push-support, one for aggregated return function, and one for YUV4MPEG). * Why do you create a dummy pad ?? Just use the existing sinkpad. If there's really a valid reason to not using the existing one, then just use a GstTask, creating a dummy pad that isn't set on the element will bring problems.
* OK, no problem for YUV4MPEG, the other 2 will be a bit closer together. Do you mean I should attach the separate patches here, or to create separate bug reports for these ? * If I understand things correctly, tasks hold a lock while running in their loop function, which in case of a pad_task is the STREAM_LOCK of the pad. So, if the existing sinkpad would be used, then both the _chain function and the task would be trying to get the STREAM_LOCK, so things would block. Both _chain and the task must be able to run (fairly) independently (e.g. queue runs the task on the src pad as well). In this case, there is no specific src pad, so a dummy pad was created. I too had some concerns about possible problems, but no problems have arisen so far during quite some testing, so I became less suspicious ;-) Admittedly, this is (as indicated) a slight hack, but a convenient one. Considering the code and functionality of the gst_pad_xxx_task functions, they offer a thin layer of additional functionality that a raw task does not have. E.g. gst_pad_stop uses some lock tricks to make sure that the task will really effectively stop and be joined. So, basically, the hack intends to use the dummy pad as a collection of "resources" (e.g. its STREAM_LOCK is a static recursive lock) and some code/functionality, and everything else should be oblivious to this, as the pad is not being added or registered anywhere, but serves only as a very local private resource. Of course, the (fairly small) relevant parts could also be extracted out of this collection, thereby just making use of a GstTask. In summary, unless otherwise suggested, I'll be adding 3 separate patches to this bug, and replacing dummy pad with using a GstTask (and corresponding code).
Make different bug reports for the non-push-related patches. The smaller the patch, the easier it is to read/test, and the faster the bug gets closed :) As for the task, it would indeed be cleaner than using a dummy pad. It's not because we constantly pester against ffmpeg, that the plugin wrapper should be equally full of hacks :) Looking forward to the new patch so we can finally add this feature ! P.S. For those wanting to test this feature, simply insert a queue between the filesrc and the demuxer you want to test, that will force it in push-mode.
Created attachment 79694 [details] [review] patch for (only) push-based support - now uses GstTask rather than dummy pad - other changes in former patches can now be found in bug #394075 and bug #394071
*** Bug 423298 has been marked as a duplicate of this bug. ***
Is this patch known to work? I have applied and compiled it successfully but I'm not having much luck in using pipelines which require push support. For example... gst-launch-0.10 gnomevfssrc location=/home/tim/public_html/whatever.flv ! decodebin ! ffmpegcolorspace ! ximagesink ...works with no problems, but if I put a queue between the source and the decodebin I get no output window and a lot of ERROR lines in the terminal: tim@backpack:~/sources/gstreamer/head/gst-ffmpeg$ gst-launch-0.10 -v gnomevfssrc location=/home/tim/public_html/whatever.flv ! queue ! decodebin ! ffmpegcolorspace ! ximagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /pipeline0/decodebin0/typefind.src: caps = video/x-flv /pipeline0/decodebin0/ffdemux_flv0.sink: caps = video/x-flv 0:00:00.350915000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 0, size 1160065, flags 0 0:00:00.351058000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 137, size 8783898, flags 0 0:00:00.351193000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 16, size 13869696, flags 0 0:00:00.351351000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 42, size 16774000, flags 0 0:00:00.351476000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 56, size 4208726, flags 0 [snipped lots of output similar to above] [gst-launch appears to hang at this point, and I hit ctrl-c] 0:00:00.366637000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 31, size 2231299, flags 0 0:00:00.366732000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 237, size 4076417, flags 0 0:00:00.366828000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 41, size 5180399, flags 0 0:00:00.366925000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 50, size 10446398, flags 0 0:00:00.367020000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 143, size 13961506, flags 0 0:00:00.367155000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 34, size 4666866, flags 0 0:00:00.367255000 24249 0x80ff278 ERROR ffmpeg :0:: skipping flv packet: type 75, size 4060389, flags 0 Caught interrupt -- handling interrupt. Interrupt: Setting pipeline to PAUSED ... ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /pipeline0/decodebin0/ffdemux_flv0.audio_00: caps = NULL /pipeline0/decodebin0/ffdemux_flv0.sink: caps = NULL /pipeline0/decodebin0/typefind.src: caps = NULL FREEING pipeline ... tim@backpack:~/sources/gstreamer/head/gst-ffmpeg$ TIA for any insight you are able to offer.
(In reply to comment #10) > Is this patch known to work? I have applied and compiled it successfully but > I'm not having much luck in using pipelines which require push support. I originally tested it with some formats I had at hand; it worked just fine with AVI, and not so fine (IIRC) with Matroska. In either case, though, supplying ffmpeg with some requested next X bytes is quite the same. What then happens with them (which is the bulk of the processing and parsing), is another matter. Basically, using ffdemux_x (in piped/push mode) along with some ffdec_x should have the same extent (or lack) of success than using ffmpeg (binary) (piped), whatever that might be ...
*** Bug 440300 has been marked as a duplicate of this bug. ***
I've tried the above patch but I'm only getting the first frame of video as a still. I'm playing an MPEG2 transport stream from fdsrc using ffdemux_mpegts. This is the command-line I'm using: cat file.mpeg | gst-launch-0.10 fdsrc fd=0 ! ffdemux_mpegts ! mpeg2dec ! xvimagesink The Fluendo flutsdemux works OK in this scenario, so my source file and pipeline are both OK. I've tried with gst-ffmpeg 0.10.2 and CVS HEAD with the same results. If it'd be useful I can upload a small transport stream file for testing.
the main issue with this patch, is that when calling av_find_stream_info(), most ffmpeg demuxers will try to read the whole incoming stream before returning. This results in buffering the WHOLE incoming stream before actually outputting anything...
*** Bug 458124 has been marked as a duplicate of this bug. ***
I'm interested in this enhancement for MPEG-TS demuxing. Although, I've done some investigation and I might go with the flutsdemux alternative instead... In the case of MPEG-TS, the demux does peek at the whole file and completely relies on url_fseek(pb, pos, SEEK_SET) to get back at the begining and perform the actual demuxing. I bet other demuxes behave this way too (a simple grep on url_fseek tells me they almost all use the seek). This feature would be pretty tough to implement properly without hacking every demux there is. Maybe if there was some way to skip av_open_input_file and gst_ffmpeg_av_find_stream_info and make do with whatever the demux outputs... Or, how about buffering the first requested buffer(s), faking an EOS and waiting for the SEEK to resume the flow?
*** Bug 496222 has been marked as a duplicate of this bug. ***
For the special case of FLV, also see bug #496221.
I've tried the patch for ffdemux_mpegts element. but I'm only getting the first frame of video as a still. I'm playing an MPEG2 transport stream using the following command: gst-launch filesrc location=reader.mpg ! queue ! ffdemux_mpegts ! ffdec_mpeg2video ! xvimagesink only first frame comes . But pipeline keeps in running state I’ve also attached the latest file. Can you please tell me if there is any fix for the same? Regards, Ramana
*** Bug 544455 has been marked as a duplicate of this bug. ***
Created attachment 127317 [details] [review] Updated patch for current master All the issues mentionned previously seem to have gone with the current revision of ffmpeg. I'm tempted to commit this one unless anybody complains.
commit 965f23f4f10dc47d1ccb83ef122da817a4097820 Author: Edward Hervey <bilboed@bilboed.com> Date: Tue Jan 27 11:39:18 2009 +0100 Implement push-based support for demuxers Fixes #392534