GNOME Bugzilla – Bug 651968
avidemux/mpegaudioparse: pre-rolling problem with (broken?) avi where mp3 audio track contains 600kB of zeroes at the beginning
Last modified: 2018-11-03 14:44:03 UTC
Open bug in Launchpad.net: https://bugs.launchpad.net/bugs/793361 "Totem and Banshee not work. VLC play movie. Attach movie" Movie: https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/793361/+attachment/2156503/+files/Firehouse%20Dog.avi
+ Trace 227391
Created attachment 189289 [details] Packages PPA for Natty Update gstreamer to PPA-Ubuntu: https://launchpad.net/~gstreamer-developers/+archive/ppa?field.series_filter=natty Idem problem
Created attachment 189290 [details] gdb-totem
Confirmed... mplayer doesn't handle the movie that good either, the first ~40 seconds are played at a much higher speed (like 20 times faster). Probably a broken file that we could handle a bit better
See bug 617563
Believe it or not, that file's audio track has 600 KB of 0 bytes at start. playbin2 can play it once extracted, and removing the first 600 KB sounds the same. Logs show mad skipping madly (ahem) over the first 600 KB trying to find sync, and eventually finding it. That's too late when muxed with a video though, as this will fill a queue before mad has prerolled. VLC plays the video "correctly" - audio starts at 38 seconds into the video, which seems to match what it should. I guess something has stomped over the start of the audio track and zeroed it, it's not "just" padding. The audio is allegedly 128 kbps, and 600 KB is about 38 seconds at that rate, so it works out.
Fun. Also, I wonder what's in the codec_data field for the mp3 data. Maybe the mp3 parser should at least move time along (newsegment update in 0.10 or GAP event in 0.11?) if it gets an input chunk with a timestamp but can't find a sync ?
If the mp3 parser gets 0 filled buffers with correct timestamps, then I guess it could do that. It (or mad) might not know enough about the stream to set caps though, one would have to try and see (if any mp3 element is actually added, since you only get mp3 data after 600 KB of audio data).
Still fails with master
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/45.