[FFmpeg-devel] [PATCH] Fix H.264 num_reorder_frames when not specified in VUI
Mon Mar 16 12:13:01 CET 2009
My patch sets num_reorder_frames to the default specified in the standard - so
it can be reasonably argued that num_reorder_frames is always specified by the
MaxDpbSize is only really dependant on Level - The mess comes from when
constraint_set3 is set which implies (I think) low latency operation - but
constraint_set3 is a recent flag and so cannot be set in the other profiles. I
strongly suspect that only testing for constraint_set3 would do, but I simply
copied the text of the standard.
The POC stuff is OK as far I am concerned - I come from a broadcast environment
where you can use DTS to kick frames out of the reorder buffer if you feel like
I'll try ffmpeg with those switches and see if it works better.
>On Fri, Mar 13, 2009 at 03:56:31PM +0000, John Cox wrote:
>> 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
>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
More information about the ffmpeg-devel