VBV + CRF-MIN/MAX, level, profile, tier

[Selur]

• "--crf-min/max" should not cause the encoder to violate VBV restrictions
• '--tier <string>' and '--profile <string> should be added
• "--level" should set vbv restrictions according to level&profile&tier choice

[Selur]

Does --crf-min/--crf-max influence the encoding at all? I combined '--crf 28' with different values for '--crf-min/max', but the output seems to be identical independent of the min/max values.

[Steve Borho]

--level should change the user's rate control options? That's counter to what I've heard from discussing this topic with Fiona, please bring this up for discussion on IRC

--profile is a compile-time choice right now

--crf-min/max only affects ABR/VBV

[Selur]

--level should change the user's rate control options?

crf should not be able to violate the level restriction, unless level is only ment as a flag which doesn't say anything other that the person thought it would be fun to label the content this way. In my option: if a content is label Level X, it should be level x compatible.

--profile is a compile-time choice right now

profile as in H.265 profile: Main/Main10/... same as for level: when a content is flagged as profile X it should be compatible to that profile

--crf-min/max only affects ABR/VBV

Thanks for clearing that up ! That should be stated somewhere (in the documentation, that crf-min/max are ment for ABR encoding)! btw. currently the documentation mentions '--max/min-crf'.

That's counter to what I've heard from discussing this topic with Fiona, please bring this up for discussion on IRC

I know Fiona doesn't care about compatibility at all and doesn't think that content should only be labeled as Level ( @ Tier ) @ Profile if it is really compatible to that selection. -> not really anything to discuss, I think it's a mistake that x264 uses Level@Profile only as a label which doesn't say anything and Fiona thinks otherwise. (has been discussed for x264 a few times over at doom9&irc and it ended always with Fiona basically saying that this is the way she wants it)

[Steve Borho]

If the user builds x265 for 10bit internal bit depth (HIGH_BIT_DEPTH) and then asks for --profile Main, the most we would be able to do is abort with a message "this build is incapable of making bitstreams compatible with Main profile". It's my understanding a Main encode is compatible with Main10 profile, so nothing would need to be done for 8bit builds, all encodes (labeled as Main profile) will be compatible with Main and Main10 profiles.

thanks for the hint, fixing the crf-min/max docs - though I need to get some clarifications before I push those fixes.

Against your wishes :) I brought this up on IRC to get an idea of the range of viewpoints. I learned two things:

1 - the --level argument should not override any other arguments like --refs; so I'll need modify the API a bit to make this possible. 2 - if would be valid for us to set --vbv-bufsize and --vbv-maxrate to the level's limits if the user specified --crf N --level M, but the primary reason this wasn't done for x264 was that VBV is non-deterministic and thus it is a large semantic change of behavior.

I get your point, why would you specify a --level if you didn't want to ensure the bitstream will be compliant. And I don't know how else to do that except by enabling VBV. Though if a user asked for --qp N --level M I don't know what we could do except barf. My intention is two send two patches to the mailing list:

The first patch will make a new API function so that profile and tier can be applied to the params after presets and tunes but before the other CLI arguments.

bool x265_param_apply_profile_tier(x265_param param, const char profile, const char *tier);

The second will change the behavior of the function to bail if CQP is enabled, and to enable VBV if CRF without VBV was specified (and to log a warning stating that outputs will be non-deterministic).

[Selur]

Thanks for looking into this. :)

--qp N --level M I don't know what we could do except barf. I agree, constant quantizer simply doesn't belong in any level, so specifying a would be a mistake and should throw an error. Same is you use 10bit encoding and you are not using Main10. (12bit and Main 12,...)

Ideally x265 should to some checks to check if tiers&levels&profile are violated by the current settings (vbv, resolution&frame rate, cq, bit depth,lossless,...) and report an error/barf if this happens. non-deterministic only is an issue for codec comparisons, for normal usage it is no issue unless specified tier/level/profile restrictions are violated by it, which shouldn't happen.

I get your point, why would you specify a --level if you didn't want to ensure the bitstream will be compliant. exactly. profile/tier/level/vbv are restrictions which when specified should be the most important thing, if the rest of the settings don't allow/violate a given restriction (in example: cq, or specifying vbv restrictions which are not inside the current level) x265 should throw an error. If people really want to misuse profile/level/tier/vbv as some sort of strange 'tagging for fun' and the developer want to support this they could add an '--ignore-restriction' which would just write the flags into the bitstream (even if they are bogus), but ignore them during encoding.

Cu Selur

[Ben Waggoner]

My opinion is that the default behavior is that --profile and --level compatibility should always be maintained, even if parameters need to be constrained. If a user really wants to make an out-of-spec stream, there should be some kind of "--compatibility-override" parameter that would need to be used.

Also, even if you don't override a user's specified refs or VBV settings, you should DEFINITELY override the parameters set by --preset or --tune. The user should never get an out of spec file unless they specifically override the specific parameter that's going out of spec.

And if you're not going to enforce profile/level, you should at least flag the incompatibility in the console output in a visually striking way. Bold and colors would be good.

[Steve Borho]

I'm sending a patch to the ML which will address all the issues except --profile, which I feel will only be interesting when the range extensions are finalized and I add level determination/enforce support for them.

[Steve Borho]

ignore my comment about --profile. I discovered we've had the API function for this for ages, but it was never used by the CLI. I'm cleaning this up now.

[Former user]

I tried encode video 640x480 with ffmpeg, but crf-min and crf-max seem to have no effect

-x265-params bitrate=1100:crf-min=22:crf-max=24 

[Steve Borho]

level: add --high-tier and auto-configure VBV if --crf N --level M (refs #61)

This patch is a major overhaul of the level enforcement logic. The first obvious difference is that the user may specify the tier. The second difference is that x265 will no longer run any configuration that might generate non-compliant bitstreams.

Any of these conditions will cause the encode to abort if a minimum decoder level was specified:

• picture size is too large
• frame rate is too high
• constant QP rate control is configured
• the specified level does not exist

Further, if CRF was specified, we now configure VBV using the maximum CPB size and bitrate for their level/tier (and issue a warning that the output may now be non-deterministic).

Note that the encoder will still encode the minimum decoder level which covers the encode parameters. So even if you specify --level 5.1, we may signal the stream as level 4.0-High if the stream should be decodable at that level.

This further fixes the CLI to allow --level-idc or the shortened --level, just as it now also supports --high-tier or the shortened --high.

→ <<cset 5510d559c2bd>>

[Steve Borho]

can I close this?

[Steve Borho]

no known remaining issues; if any are found please open a new bug