[x265] [PATCH 3 of 4] cli: allow -P/--profile to influence requested API bit-depth

[Steve Borho]

On 04/28, Xinyue Lu wrote:
> How about using --output-depth instead of --profile?
> 
> Profile is the "up-limit" of the stream. For example in x264 world,
> it's possible that a stream of yuv420p8 avc is marked as High 444
> Profile. This may not make much sense in real world encoding though.
> 
> So I'd propose the following code logic.
> 
> param->output_depth = 0
> param->profile = 0
> 
> OPT(output-depth)
> ..param->output_depth = value
> OPT(profile)
> ..param->profile = value
> 
> if param->output_depth && !param->profile
> ..param->profile = param->output_depth.to_profile
> else if !param->output_depth && param->profile
> ..param->output_depth = param->profile.to_depth
> else
> ..param->output_depth = x265_depth
> ..param->profile = x265_depth.to_profile
> end
> 
> if param->profile < param->output_depth.to_profile
> ..alert(Invalid profile)
> end
> 
> That is, unless user specify both depth and profile, either option
> will take effects.
> 
> And IMHO --output-depth 10 makes more sense than using --profile
> Main10. You'll probably have --output-csp 422/444 soon as well, as
> Main422-10 or Main444 is required for i422p8.

(apologies for the long mail, but this is a complicated topic)

The --profile argument has historically been treated by x265 much the
same as --level-idc and --tier in that they are meant to describe the
capabilities of your (least capable) hardware decoder and the encoder
will ensure that the resulting bitstream will be decodable by that
device.

But when the bitstream itself is signaled, x265 always signal the minimal
requirements possible for that stream so even lower capability decoders
can decode them.

For example you might specify --profile main422-10 --level-idc 5.1
--high-tier, telling us that your decoder cannot support anything above
those specifications, but if you linked against an 8bit encoder and are
encoding i420 720p video, it will be signaled as Main profile, level 4,
Main tier. Your user params might lower certain options (like --refs)
but they will never increase them.

Our CLI does not have the ability to convert color spaces, so the output
color space is the input color space. I don't see that ever changing for
us. But the CLI has had the ability to convert from any input pixel
bitdepth to the internal bitdepth as needed (even dithering when
reducing bit depth), which I've found very helpful.

We already have 'param->internalBitDepth' which is essentially the same
as your param->output_depth, but previously it was not configrable via
x265_param_parse() or by getopt(). It was only configured by
x265_param_default() and friends, based on which build of libx265 you
linked against. I don't think we want that to change, the internal bit
depth is a compile time decision and so it is solely determined by the
library whose API you are using.

All that said.. we could add --output-depth N to the CLI getopt()
options and use that instead of --profile to select the output bit depth
(and by proxy, select the libx265 used), if people think this is better
than treating --profile like a request for bitdepth. I'm ambivalent
about it.

No-one has tried to convince me yet that --profile main10-444 should
mean that we signal main10-444 even if the bitstream will be 8bit i420.

FWIW: apps like ffmpeg will use the encoder's input pixel format to
select the output bitdepth (via -pix_fmt). So it will be unlikely that
ffmpeg and our CLI will ever configure output bitdepth in the same way.

-- 
Steve Borho