GNOME Bugzilla – Bug 667560
h264parse: H.264 reverse playback does not work anymore
Last modified: 2012-02-01 13:16:08 UTC
+++ This bug was initially created as a clone of Bug #667554 +++ This sample file: http://samples.mplayerhq.hu/V-codecs/h264/cathedral-beta2-400extra-crop-avc.mp4 This works with latest releases and "seek" example, but not with 0.10. Removing h264parse doesn't seem to make a difference, so assuming it's a qtdemux issue for now.
Finally traced down to: commit 1c50dab50c069c4d559921648c92c3ccc7d13dcd Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Dec 5 11:50:17 2011 +0100 h264parse: Use faster parsing variant when input is packetized Reduces latency and cpu usage https://bugzilla.gnome.org/show_bug.cgi?id=665584
What I worked out so far: Calling gst_h264_parser_identify_nalu (rather than the _unchecked version) makes it work again. Tracing shows that the expected "start codes" of mask 0xffffff00 and pattern 0x100 are not found within a (packetized) packet. Not knowing the format, I'm not sure if that's a wrong assumption in the code (that packetized streams will always have a start code in every packet), that the stream is broken, or that there's a bug in the demuxer that fragments packets.
Not quite. The code was looking for a *second* start code in order to determine length of data. When using the unchecked version, which does not do that, the length is assumed to be the full length of passed data, minus the offset at which the start code is found. In reverse mode, it seems we get a huge amount of data from the parser, so the NALU length is set to a very large amount of data, as it does not attempt to locate the start of the next data bit.
A second commit is breaking this: commit d9c1688d49cbd0007223f907829a72a8c6398f65 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Jan 3 22:09:04 2012 +0100 h264parse: prefer negotiating pass-through Reverting both makes -bad master reverse play again on the file above.
For generic reverse mode processing, baseparse has to gather "reverse chunks" and then process these all at once, so the optimized assumptions no longer hold for reverse playback. Following commit should arrange disable the optimized in reverse case. (on 0.10, also pushed on master) commit e6dc08af1d02388f0b2b6638f8bd7d82a598c622 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Feb 1 12:47:56 2012 +0100 h264parse: disable optimized packetized processing for reverse playback ... as baseparse then provides whole chunks of data (as it should) at once to be parsed, and so the assumptions used to optimize are no longer valid. Fixes #667560.