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

[Alex Izvorski]

Hello Gabriel, Thank you for the feedback, I was hoping you'd pitch in
since you did the last patch like this.

On Tue, 2008-04-08 at 01:50 -0700, Gabriel Bouvigne wrote:
> 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.

Yes.  Actually they have to be written with reduced precision anyway,
the best precision available is in units of 64bit for bitrate and 16bit
for buffer size (don't ask why ;)  I think saving space by removing a
few more bits of precision from these values is pretty pointless, so I
always use *_scale=0 in my patch.  But if someone feels it is worth it,
and wants to contribute such a modification, that is cool.

Regarding adjusting the user supplied values, isn't it better to round
them up instead and write that in HRD?  I would be very surprised if i
asked for a bitrate of X kbit but got something other than X just
because X could not be written exactly in the HRD fields.  However if I
asked for X and got X exactly, but the HRD fields contained X rounded
up, that would be a lot less surprising behavior - at least for me ;)

> *In case of variable frame rate (vfr), you would then have to put
> timestamps info within each pic struct. 

Couldn't the timestamps be indicated only in the container, such as a
mpeg2 transport stream?  Not providing timing info, or providing timing
info but not setting the fixed framerate flag, and providing timestamps
in the container should be spec compliant.

> 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).

What I meant is that timestamps in picture timing sei seem to be written
using units of vui time_scale per second, which may be written by x264
as time_scale/num_units_in_tick = 30/1 (depending on the settings).  In
that case the 90kHz clock values would have to be rounded to a very low
precision.  Sure, we could force x264 to write these as 30000/1000, or
even 90000/3000, by giving a fractional fps on the command line, in
which case rounding would minimal or none.  Is there any reason not to
always do that?

> 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.

Absolutely, full vfr support would require quite a lot of changes to the
bitrate allocation.  But, if you don't mind your bitrate being
unintentionally variable as well ;) vfr does sort of work now.

Which standards require cfr?  Is that cfr with occasional switching
(when/how), or completely fixed?  This is very interesting, because I am
seeing a whole lot of vfr in mpeg2 satellite feeds now, not with
completely arbitrary times but more along the lines of quickly switching
between 30/29.97/25/24/23.97, sometimes a few times per minute, so at
least common practicee seems to be to do sort-of-vfr.

> *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
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>