[x264-devel] [PATCH] pic timing, vui timing info, hrd, and buffering periods

[Gabriel Bouvigne]

Alex Izvorski a écrit :
> Please comment.

A few comments, from what I remind of my implementation of HRD in 
another encoder more than one year ago (so my memory could be wrong):

*cpb size and bitrate value can be set with a reduced precision in the 
HRD data, in order to reduce needed space. In this case, cpb and bitrate 
value given by the user should be adjusted to values writable using the 
desired precision, and those adjusted values should be used within the 
encoder. If x264 is using kbits in a few places, this then might need to 
be changed to full bits values. The adjusted  values are usually not 
much different than the values given by the user, so that is not a 
problem for the user. If you don't adjust those values, then you either 
have to write them in full bps values, or keep them intact but then you 
won't have a correct HRD compliance.

*In case of variable frame rate (vfr), you would then have to put 
timestamps info within each pic struct. As you are using a selected 
clock with a finite precision (usually a 90kHz one), that means that 
timestamps of pictures have to be adjusted before rate control, in order 
to have integer values using your clock. Yes, that introduces a bit of 
jitter within the timestamps, but it's very small (at most 1/90000s for 
a frame).
As x264 is right now assuming cfr in several places, and considering 
that some ETSI and ATSC standards are requiring the use of cfr, you 
might only consider handling of vfr for a latter stage.

*cpb_removal_delay should be computed from vbv/cpb:
Here, the cpb removal rate is either the target rate (cbr) or the max 
rate (in case of capped vbr). If before the current frame the cpb is 
filled by 100kbits and the cpb removal rate is 200kbps, than your 
current cpb_removal_delay should be 0.5 seconds.
As this is considering the receiver cpb, that means that cpb filling is 
reversed compared to x264 internal terminology (when x264 is complaining 
about a vbv underflow, that is a cpb OVERflow on the receiver side).

*The very first cpb_removal_delay is obviously inferred from the 
--vbv-init value


--
Gabriel