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 624586 - h264parse: H.264 stream in an avi file doesn't play properly (but works with legacyh264parse)
h264parse: H.264 stream in an avi file doesn't play properly (but works with ...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-17 00:21 UTC by Jean-François Fortin Tam
Modified: 2012-10-04 08:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2010-07-17 00:21:28 UTC
I have a file, transcoded from mpeg2-ts to avi with avidemux (video and audio codecs left untouched, no re-encoding). VLC can play it, but not totem. The nautilus thumbnailer doesn't work, and looking at the info it provides, it says the image has a resolution of 0 x 0 pixels.
Comment 1 Jean-François Fortin Tam 2010-07-17 00:22:52 UTC
Sample file: http://jeff.ecchi.ca/public/totem-624586.avi
Comment 2 Vincent Penquerc'h 2011-09-12 10:53:57 UTC
Twiddling priorities to make legacyh264parse to be autoplugged makes it work.
Comment 3 Tim-Philipp Müller 2011-09-12 11:04:13 UTC
Marking as blocker (though maybe it's not a regression, needs to be checked).
Comment 4 Mark Nauwelaerts 2011-09-19 12:44:03 UTC
This is pretty ugly input; afaics there is no single sps/pps in the stream, the chunks appear to have improperly aligned AU and no entry has a keyframe flag set.  Since ffmpeg decoder awaits a keyframe, nothing gets decoded.

Plugging legacyh264parse leads to some parsing and most importantly setting some keyframe flag, which makes ffmpeg decoder take off.

On the other hand, this falls into one of h264parse's optimizations which considers this a case for pass-through and so nothing gets marked as keyframe.
However, even if it would parse, still no keyframe would be marked, since there is not really one (e.g. IDR, SPS, PPS) though it does happen To Work (= Decode).

Slightly hacking up h264parse to be less fussy simply makes it work, but that is not much of a fix since current approach is not necessarily wrong.

If anything, it is just as much (more) an gst-ffmpeg problem in that whether it is useful to have it wait for a keyframe (which is a bit error-prone depending on the input material and/or upstream doing proper flag setting, though it may have its reasons there).
Comment 5 Sebastian Dröge (slomo) 2011-11-24 08:21:26 UTC
Waiting for a keyframe in the decoders definitely makes sense and IMHO this should either be closed as WONTFIX because of a broken stream or fixed in h264parse.
Comment 6 Tim-Philipp Müller 2011-12-09 16:34:53 UTC
Not a blocker. Confirming for now, no opinion on whether to just WONTFIX it or not though.
Comment 7 Tim-Philipp Müller 2012-10-04 08:09:29 UTC
This seems to work fine for me in 1.0 (plays just like in VLC).