[FFmpeg-devel] [PATCH] Fix H.264 num_reorder_frames when not specified in VUI

[Michael Niedermayer]

On Fri, Mar 13, 2009 at 03:56:31PM +0000, John Cox wrote:
> Hi
> 
> I was testing ffmpeg against my ITU derived test & conformance bitstreams and I
> found ~20 failures were caused by the reordering code throwing away frames
> until it has established the correct reordering level.  This can be fixed by
> setting num_reorder_frames to MaxDpbSize before parsing the VUI.
> 
> This has the disadvantage that it will increase the latency through the decoder
> but the advantage that frames are no longer lost (and it passes about 20 more
> conformance tests).
> 
> I enclose a patch for this.
> 
> I used a modified tutorial01.c as the decoder for testing as ffmpeg itself
> produced more failures (I'm guessing missing frames at the start or end - but
> I'm not sure - I haven't investigated closely yet).  What options should I be
> using to take an H.264 elementary bitstream in and produce a YUV file out with
> no missing frames and no post processing?

ffmpeg with -vsync 0 -strict 1 should have no problem with the reference
streams
and setting num_reorder_frames based on the level&profile seems very
unreliable considering that profile&level may be random, also this as
your patch shows requires a huge amount of mess ...

Its a grave flaw in the h264 spec that num_reorder_frames is not a
mandatory element. (and thats not the only grave flaw, the whole
POC/timestamping is a insane misdesigned mess that could have been done
with a single timestamp per frame)

The obvious "fix" that can be done is to make the parser figure out what
amount of reordering the first few frames need, this of course is unreliable
as well but i hope that encoders that do fancy reordering would store
num_reorder_frames


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090313/e032251d/attachment.pgp>