GNOME Bugzilla – Bug 670699
h264parse: some MP4 files don't show video (regression)
Last modified: 2012-02-23 20:41:59 UTC
Overview: After updating to the new 0.10.36 release, I found out that .mp4 files that have the video stream in the first stream inside the container, they all play 100%. But if the video stream is in the second stream (after the audio) the .mp4 files don't display image. In the previous version the problem doesn't occur. Steps to Reproduce: [File 01] MP4 file with video in the first stream (before the audio)-> http://dl.dropbox.com/u/2534198/adidas.mp4 [File 02] MP4 file with video int the second stream (after the audio) -> http://dl.dropbox.com/u/2534198/ikea.mp4 Testing: - with gst-launch playbin2 uri="File 01". Result: Video ok Audio ok - with gst-launch playbin2 uri="File 02". Result: Audio ok Video isn't displayed Build Date & Platform: Date and platform of the build in which you first encountered the bug. Build 0.10.36 built with Mingw/Msys on Windows 7 64bit Additional Information: With more tests I found out that if using playbin instead of playbin2, both files play ok
Indeed. With my system 0.10.35 version the video plays fine for ikea, with git 0.10 branch (effectively equal to 0.10.36 at this point of time) it does not. Does with playbin1 as you say. But gst-launch filesrc location=/tmp/ikea.mp4 ! qtdemux name=d ! queue ! h264parse ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! xvimagesink d. ! queue ! aacparse ! faad ! volume ! audioconvert ! audioresample ! pulsesink doesn't play either for file2, while does for file1. Removing the h264parse from in there makes it work. So this is a regression due to some bug in h264parse, combined with the fact that since 0.10.36 playbin2 auto-plugs parsers now, while in 0.10.35 it did not do that yet.
Indeed an h264parse issue: gsth264parse.c:387:gst_h264_parse_wrap_nal:<h264parse0> nal length 402 gsth264parser.c:1296:gst_h264_parser_identify_nalu_avc: Can't parse, buffer has too small size 404, offset 404
Actually, recent git and 0.10 do not have identical h264parse. In particular, the latter may have above error, but the former does not, and should work fine with following fix: commit 4c9ac0886a4c289fddbf2b8a76db1426b2eb3b55 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Thu Feb 23 21:17:53 2012 +0100 h264parse: consider nal_length_size when constructing codec_data Fixes #670699.