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 574661 - [gstffmpegdec] Wrong usage of parsers
[gstffmpegdec] Wrong usage of parsers
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal blocker
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-09 17:14 UTC by Edward Hervey
Modified: 2012-08-27 21:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2009-03-09 17:14:56 UTC
Our usage of parsers is completely wrong. We currently assume that if there's a parser for a given codec we should use it, whereas there's no guarantee that it's the appropriate parser to use for the given stream.

To figure out whether a parser is needed or not, we should actually probe the incoming stream mimicing the parsing being done in libavformat.

As such, I'd like to *NOT* use the parsers for the following codecs (tested against many files, removes errors and introduces no regressions so far):
* mpeg2video
* aac
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-10 21:09:37 UTC
I would actually suggest to use the parser for aac. The aacparse has a seeking issue which rene is currently fixing/has fixed. One advantage of the aacparse is that one gets much quicker sane durations for vbr streams (over just using faad).

Also it would be nice to explain what "probe the incoming stream mimicing the parsing being done in libavformat" actually means.
Comment 2 Edward Hervey 2009-03-13 10:23:00 UTC
I was of course talking about AVParser (and not the -bad aacparse).

As for the probing part, there is some code in libavformat (the demuxer/muxer part of ffmpeg) which is used by ffmpeg demuxers to figure out whether they need a parser for a given AVStream.

This is how they figure out:
* If a parser is needed for the given stream
* Which parser is needed 
Comment 3 Edward Hervey 2009-03-13 16:35:23 UTC
Bumping target milestone to next release, we're too close to the release to grasp all the implications.
Comment 4 Jan Schmidt 2009-06-29 21:35:35 UTC
Bumping the target milestone even further... this clearly isn't making it into 0.10.8
Comment 5 Jan Schmidt 2009-09-11 21:30:56 UTC
Should we bump this again?
Comment 6 Sebastian Dröge (slomo) 2010-02-25 17:06:56 UTC
...and maybe again? :)
Comment 7 Edward Hervey 2010-03-03 18:09:20 UTC
and maybe again indeed... *sigh*
Comment 8 Edward Hervey 2010-06-27 08:43:46 UTC
And again
Comment 9 Wim Taymans 2010-11-04 09:58:23 UTC
I did some grepping on the ffmpeg code. The code to initialize the parser (av_parser_init) is only called from 2 places, one for removing extra codecdata and the gst-libs/ext/ffmpeg/libavformat/utils.c.

The utils.c functions are:

av_find_stream_info() 
av_read_frame_internal()

The first function is to setup all the streams. The way it works is that it iterates over all codec_ids and tries to create a parser. If this succeeds, it uses the parser. This is what we currently do.

The second function basically does the same but also takes new dynamic streams into account.

I did some more grepping to see who does the actual calls to av_parser_parse* and again the only callers are in gst-libs/ext/ffmpeg/libavformat/utils.c.

Maybe I'm wrong in assuming that ffplay is doing the right thing?
Comment 10 Edward Hervey 2011-07-18 10:12:17 UTC
Bumping to next release
Comment 11 Edward Hervey 2012-07-27 08:48:54 UTC
We no longer use video parsers in latest code (0.10 and master).

Shall we just close this ?
Comment 12 Tim-Philipp Müller 2012-08-27 21:06:44 UTC
Let's.