[Ffmpeg-devel] H.264 VUI timing info clarified

[Måns Rullgård]

Hi all,

Below is a thread from the jvt-experts mailing list that should remove
the confusion around the correct interpretation of the H.264 VUI
timing info.  Now we just need to make sure we're doing the right
thing, and work out which versions of which encoders are doing what,
so we can apply workarounds as needed.


> > > Hi Experts,
> > > 
> > > Could you please explain how to use VUI 
> > > num_units_in_tick/time_scale parameters correctly? The 
> > > explanation in the standard is not clear enough.
> > > 
> > > fixed_frame_rate_flag semantics paragraph gives a formula 
> > > for delta T_{fi, dpb} and refers to E-13. Table E-6 adds 
> > > more mess to the subject.
> > > As one can guess from names, delta T_{fi, dpb} is a time 
> > > period between video fields. Table E-6 specifies constaints 
> > > for a fixed frame rate sequence and nothing else.
> > > However, existing implementations use three ways to fill 
> > > num_units_in_tick/time_scale.
> > > 1. Both for field and frame sequences specify this as frame 
> > > rate. I.e., 1/25 or 1001/30000 for 25 or 29.97 fps respectively.
> > > 2. For field sequences specify this as field rate, i.e. 1/50 
> > > or 1001/60000, and for frame sequences specify as frame 
> > > rate, i.e. 1/25 or 1001/30000.
> > > 3. Both for field and frame sequences (progressive frame 
> > > sequences as well) specify as field rate.
> > > Probably there exist other understandings as well, but video 
> > > gurus seem to be happy with mentioned above. IMHO only one 
> > > of the three is correct, and this one should be clarified in 
> > > the standard to avoid ambiguity. Probably, specifying by 
> > > means of example would be sufficient.
> > > 
> > > Regards,
> > > Peter
> > 
> > Peter et al,
> > 
> > You seem to be focusing on the case in which fixed_frame_rate_flag
> > is equal to 1.  In this case, I think your interpretation #3 is
> > correct -- when fixed_frame_rate_flag is equal to 1,
> > num_units_in_tick/time_scale is a hypothetical field rate --
> > Actually, to be more precise, it is the inverse of twice the frame
> > rate (and the "/" operator is defined to mean something else in
> > the standard).  The text of this section is being refined in the
> > in-progress corrigendum, and you may find the new text friendlier.
> > 
> > Best Regards,
> > 
> > Gary Sullivan 
> 
> Gary,
> 
> Thank you for explanation. However, I still do not understand why
> one should specify tick unit as field duration when he encodes
> progressive video and has no any notion of fields. But in any case
> explicit definition is required to avoid misuse.  Looking forward to
> seeing the new text.
> 
> Merry Christmas and Propsperous New Year!
> 
> Peter

Peter et al,

The standard is written in a way that allows the same bitstream to
contain both frames and fields.  The intent was to avoid unnecessarily
restricting what an encoder is allowed do.  Moreover, there was a
conscious intent to decouple timing information from the geometry of the
pictures.

Maybe that syntax capability will not be used by some encoders, but it
does little harm to the encoders that don't use it and provides extra
flexibility for those that do.

Probably a few bits per picture could have been saved if we had done
some of this a little differently.  But I think the design is OK, and
the number of bits that could have been saved by doing it differently is
typically not a big percentage of the total bit rate.

Best Regards,

Gary Sullivan