[FFmpeg-devel] [PATCH 2/2] ffmpeg: Use the colour properties from the input stream when doing transcode

[Tobias Rapp]

On 28.05.2018 09:30, Xiang, Haihao wrote:
> On Sat, 2018-05-26 at 17:29 +0100, Mark Thompson wrote:
>> On 25/05/18 07:57, Tobias Rapp wrote:
>>> On 25.05.2018 07:58, Xiang, Haihao wrote:
>>>> On Thu, 2018-05-24 at 11:15 +0100, Mark Thompson wrote:
>>>>>
>>>>> For example:
>>>>>
>>>>> ffmpeg -i bt709_input.mkv -vf colorspace=bt2020 bt2020_output.mkv
>>>>>
>>>>> will have the output file marked as BT.709 after this patch, where
>>>>> previously
>>>>> it was "unspecified".  (Explicitly setting -color_primaries/-color_trc/-
>>>>> colorspace on the output works in both cases.)
>>>>
>>>> I agree with you it's not worse than before as we don't get the expected
>>>> result
>>>> in both cases.
>>>
>>> Not quite: When a file says "I don't know this property value" you have a
>>> chance to lookup the value somewhere else or use a default. When it says "I
>>> know the value" and gives a wrong value, you completely loose trust.
>>
>> Right, that is a compelling argument.  I agree with you, so I definitely won't
>> apply the patch in this form.
>>
> 
> According the comment in avcodec.h, the color properties in AVCodecContext
> should be set by user for encoding. I think ffmpeg is the user in the case
> below. Where are the color properties set if we don't set the default values in
> init_output_stream_encode()?
> 
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format
> vaapi -i input-with-hdr.mkv -c:v hevc_vaapi -profile:v main10 output.h265

Setting color properties in init_output_stream_encode() basically looks 
OK, but the question "when" seems more important than "where". It should 
be called after some output frame is available, and use that to 
initialize the encoder. Currently the current AVFrame is not available 
in init_output_stream_encode(), only the buffersink properties.

Hopefully somebody with more knowledge about FFmpeg infrastructure will 
make a recommendation on how this should be solved: By adding color 
properties and other frame data to the buffersink interface? Or by 
making the current/last frame available in init_output_stream_encode()? 
Or ...?

It doesn't need to be auto-negotiated like in the mentioned patch series 
for color_range, it just needs to be forwarded properly from filter 
graph output to the encoder.

Regards,
Tobias