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

[Gabriel Bouvigne]

Alex Izvorski a écrit :

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

Advice: put the scale somewhere within a define, and use the define. 
This way if someday you would want to use another scale, you would not 
have to dig everywhere to find where it's used

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

The adjusted value is a way to write a bps value, using less bits. 
You'll find that the difference is usually not that big, so if the user 
asks for 1500kbps, but in fact the encoder is using something like 
1497.8kbps (arbitrary number, for the purpose of explanation), the user 
would not care much. Moreover, if this is a user who specifically asked 
   to use HRD info, he is either totally clueless, or would understand 
this limitation.

Value mentioned within HRD should be the exact value used by the 
encoder, not a rounded one. Otherwise, after a few hours of use (as in 
continuous encoding of a tv channel), you would have a drift between 
values. Second point, if it's not exact, stream analyzers will complain 
sooner or latter, and it's way easier to check your implementation if 
everything comply with the parameters considered by analyzers.

Rounding (due to reduced precision) should be a rounding down, IMO. If a 
user specify xxxkbps, that is, in some cases, because the network can 
handle only up to xxxkbps, and no more. By rounding down, you ensure 
that your stream will be streamable through this network. In the IPTV 
case it's usually not relevant, but in the satellite or dvb cases it is.
Rounding up could also broke compliance with the level specified. If the 
user specified 10000kbps and you round it to 10001kbps, your changed 
level, while if you rounded it to 9999kbps, the level is still identical.


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

That's a possibility. You would have to check the spec you are 
interested in to be sure.
In this case, you would then not be able to check compliance or your 
Annex B stream in analyzers.

note: if the stream is further encapsulated into mpeg2-ts, aren't we 
supposed to use VCL hrd instead of NAL hrd? Could someone provide any 
hint there?


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

I'd say that if your value is 30/1, you probably don't really care about 
the 90kHz clock.
On the other hand, if you are within the NTSC area, and are interested 
by HRD compliance, it's very likely that your input framerate will be 
30000/1001 (the true NTSC framerate).


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

 From memory, I think that at least Blue-ray and DVB-T require cfr.
It might be possible that in order to accommodate input jitter, some 
broadcasters might alternate between different cfr. This way the stream 
would still be cfr, with some occasional changes of the frame rate IDR 
frames. (but that is just pure speculation)

--
Gabriel