After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 392534 - ffdemux enhancement: push based scheduling
ffdemux enhancement: push based scheduling
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.2
Other Linux
: Normal enhancement
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 385882 423298 440300 458124 496222 544455 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-03 23:13 UTC by Mark Nauwelaerts
Modified: 2009-01-27 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for push-based scheduling support for ffdemux (17.59 KB, patch)
2007-01-03 23:21 UTC, Mark Nauwelaerts
none Details | Review
Addendum to patch (2.66 KB, patch)
2007-01-04 08:24 UTC, Mark Nauwelaerts
none Details | Review
patch for (only) push-based support (17.76 KB, patch)
2007-01-07 23:41 UTC, Mark Nauwelaerts
none Details | Review
Updated patch for current master (18.54 KB, patch)
2009-01-27 10:34 UTC, Edward Hervey
committed Details | Review

Description Mark Nauwelaerts 2007-01-03 23:13:38 UTC
Subject says it all, see patch for push-based scheduling support for ffdemux (as well as a few other fixes/additions).
Comment 1 Mark Nauwelaerts 2007-01-03 23:21:48 UTC
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)
Comment 2 Mark Nauwelaerts 2007-01-04 08:24:08 UTC
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".
Comment 3 Edward Hervey 2007-01-04 10:41:38 UTC
Will have a look at this later, put next time please check an existing bug hasn't already been created : #385882
Comment 4 Edward Hervey 2007-01-04 10:42:03 UTC
*** Bug 385882 has been marked as a duplicate of this bug. ***
Comment 5 Edward Hervey 2007-01-07 12:45:38 UTC
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.
Comment 6 Mark Nauwelaerts 2007-01-07 14:00:29 UTC
* 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).
Comment 7 Edward Hervey 2007-01-07 15:44:33 UTC
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.
Comment 8 Mark Nauwelaerts 2007-01-07 23:41:45 UTC
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
Comment 9 Edward Hervey 2007-03-27 11:19:31 UTC
*** Bug 423298 has been marked as a duplicate of this bug. ***
Comment 10 Tim Angus 2007-04-26 14:24:10 UTC
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.
Comment 11 Mark Nauwelaerts 2007-04-29 19:12:29 UTC
(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 ...
Comment 12 Edward Hervey 2007-05-23 07:32:31 UTC
*** Bug 440300 has been marked as a duplicate of this bug. ***
Comment 13 David Johnson 2007-05-24 19:34:32 UTC
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.
Comment 14 Edward Hervey 2007-05-25 09:24:21 UTC
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...
Comment 15 Edward Hervey 2007-07-19 13:14:31 UTC
*** Bug 458124 has been marked as a duplicate of this bug. ***
Comment 16 vanista 2007-07-26 19:59:21 UTC
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?

Comment 17 Edward Hervey 2007-11-12 19:45:59 UTC
*** Bug 496222 has been marked as a duplicate of this bug. ***
Comment 18 Tim-Philipp Müller 2007-11-13 23:09:45 UTC
For the special case of FLV, also see bug #496221.
Comment 19 Ramana 2008-04-09 07:06:48 UTC
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
Comment 20 Allan Day 2008-07-24 00:32:22 UTC
*** Bug 544455 has been marked as a duplicate of this bug. ***
Comment 21 Edward Hervey 2009-01-27 10:34:09 UTC
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.
Comment 22 Edward Hervey 2009-01-27 10:41:36 UTC
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