[x265] A few questions about the new VUI settings

[Steve Borho]

On Fri, Feb 28, 2014 at 10:25 AM, dave <dtyx265 at gmail.com> wrote:
> On 02/27/2014 11:38 PM, Selur wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Got a bunch of questions and uncertainties about the new VUI settings,
>> would be nice if someone could explain a bit what they are ment for.
>>
>>> --vui                         Add Video Useability Information with
>>>   all fields to the SPS. Default disabled
>>
>> Does this have to be set for all the other options to work, if not what
>> does it do?
>
> No, it doesn't.  All it does is set all flags that cause the vui and
> optional parts of it to be added to the sps.  Without specifying any other
> vui cli options, the vui will only have default values.  I added this
> initially only for testing purposes but thought it might be useful beyond
> that.  If not, then it can be removed.  Just specifying any vui cli option
> by itself will cause a vui to be added to the sps.

Dave and I are both kind of winging it with regards to the VUI
contents.  We could use a lot of feedback on how you would prefer
these items to be configured in the API and CLI.


>>> --sar <int:int|int>           Sample Aspect Ratio, the ratio of
>>> width to height of an individual pixel. Choose from 0=undef,
>>> 1=1:1("square"), 2=12:11, 3=10:11, 4=16:11, 5=40:33, 6=24:11,
>>> 7=20:11, 8=32:11, 9=80:33, 10=18:11, 11=15:11, 12=64:33, 13=160:99,
>>>   14=4:3, 15=3:2, 16=2:1 or custom ratio of <int:int>. Default 0
>>
>> Is there a difference in I use --sar 1:1 or --sar 1 ?
>
> No they will both cause the same result of apsectRatioIdc being set to 1.

Yes, as of now I believe SAR is handled "like you would expect".  You
give us a ratio or an index and we figure out how to fill in the VUI
fields.  Or we read it from the Y4M header if it was unspecified.

>>> --overscan <string>           Specify crop overscan setting from
>>> undef, show or crop. Default undef
>>
>> I suspect this requires '--crop-rect <string>' to be set and decides
>> what to do with the crop values.
>> assuming the decoder supports it:
>> show = should just 'overlay/show' the crop rectangle
>> crop = should actually crop the output picture
>> but what does 'undef' in this context mean? Does it mean that the
>> decoder decides what to do with the crop rectangle values, does is mean
>> 'ignore' the crop rectangle values or what is it ment to do?
>
> Initially, I left out the undef option but since it's part of the x264
> --overscan cli option I added it.  The undef option means that overscan info
> is not included in the vui which is the default anyway so it really does
> nothing.  The decoder decides nothing.

I guess --overscan undef would be logically the same as --no-overscan
(but no such option exists)

>
>>> --[no-]fieldseq ... --nal-hrd .. --subpichrd ..
>>
>> I suspect that these might be needed for some future blu-ray/avc-hd
>> compatibility?
>
> I am not sure.  I am new to x265 and haven't worked on x264 but I am sure
> there are others that can answer this for you.

Near as I can tell, all of the VUI fields are informational only,
communicating some information directly to the decoder.  None of those
affect the encoder behavior at all yet, but I imagine --nal-hrd
should.

>
>>> --timinginfo                  Add timing information to the VUI.
>>> Defaut disabled
>>
>> No sure what this is for since I doubt that it is the same as the time
>> codes one normally finds in containers.
>
> It's timing information in relation to the display of frames and general
> system clock information in units of ticks.
>
>>> --bitstreamrestriction        Add bit stream restriction fields to
>>>   the VUI. Default disabled
>>
>> I suspect that this is needed for later tier, profile, level signaling?
>>
> Probably.  Like I said, I am new to this and others may have a better
> answer.

The SPS already has level, tier, and profile.  This enables a number
of flags in the VUI that we do not allow to change from their
defaults, so it is not very useful at present.

>> => got a lot of ideas what stuff might be, but some additional infos
>> would be nice (and it might be a good idea to add these to the next
>> 'x265 Evaluators Guide').

For the VUI, all I can really say in this release is that it has been
exposed in the API and CLI.  The one thing I really wanted signaled
(frame rate) was actually enabled in the VPS, so the VUI's only
effective use at the moment is to signal SAR and to communicate color
space info to the decoder.

We are updating the eval guide for the very near 0.8 release, and
we're also converting the document to restructured text (for lack of
anything better) so that it may be maintained within the source
repository as the encoder is developed.  So anyone will be able to
present patches to improve the documentation.

reST can be compiled to HTML and PDF, and we intend to host both
formats at readthedocs.org, similar to how the TortoiseHg docs (my
other project) are maintained, see:
http://tortoisehg.readthedocs.org/en/latest/

-- 
Steve Borho