[FFmpeg-devel] [PATCH] libavfilter: vf_scale: Properly take in->color_range into account

Martin Storsjö martin at martin.st
Sat Mar 5 23:33:15 EET 2022

On Fri, 4 Mar 2022, Michael Niedermayer wrote:

> On Thu, Mar 03, 2022 at 02:06:45PM +0200, Martin Storsjö wrote:
>> While swscale can be reconfigured with sws_setColorspaceDetails,
>> the in/out ranges also need to be set before calling
>> sws_init_context, otherwise the initialization might choose
>> fastpaths that don't take the ranges into account.
>> Therefore, look at in->color_range too, when deciding on whether
>> the scaler needs to be reconfigured.
>> Add a new member variable for keeping track of this, for being
>> able to differentiate between whether the scale filter parameter
>> "in_range" has been set (which should override whatever the input
>> frame has set) or whether it has been configured based on the
>> latest frame (which should trigger reconfiguring the scaler if
>> the input frame ranges change).
>> Signed-off-by: Martin Storsjö <martin at martin.st>
>> ---
>> To test this (without risking running many conflicting swscale
>> filters in one filter pipeline), we'd need to be able to tag
>> the incoming raw yuv data with colorspace and range without setting
>> the in_color_matrix and in_range options on the scale filter.
>> When using the rawvideo demuxer, the pixel format is set via the
>> ffmpeg -pix_fmt option, but there's no corresponding option for
>> setting color matrix or range for it.
>> ---
>>  libavfilter/vf_scale.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
> This changes the output for:
> ffmpeg -i tickets/524/AVCI50.mov   -vframes 3 file-avci50dec.nut
> ffmpeg -i tickets/4493/AVCI100.mov -vframes 3 file-avci100dec.nut
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/
> Is that intended ?
> - 233903 file-avci100dec.nut
> - 383853 file-avci50dec.nut
> + 196558 file-avci100dec.nut
> + 333893 file-avci50dec.nut

Looks like these source files have full range content; for any data with 
full range input, this patch makes sure it uses the right intended 
conversion through swscale. So yes, I guess it's expected that these 
conversions change.

// Martin

More information about the ffmpeg-devel mailing list