[FFmpeg-devel] [PATCH] avfilter/vf_scale: set the RGB matrix coefficients in case of RGB

Jan Ekström jeebjp at gmail.com
Wed Sep 1 23:32:18 EEST 2021


On Tue, Aug 31, 2021 at 1:14 AM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Sun, Aug 29, 2021 at 10:05 PM Jan Ekström <jeebjp at gmail.com> wrote:
> >
> > On Sun, Aug 29, 2021 at 9:21 PM Paul B Mahol <onemda at gmail.com> wrote:
> > >
> > > probably fine if fate passes
> >
> > Yea, FATE passes :) . I think this stuff not being noticed until now
> > is due to nothing checking the metadata values returned by vf_scale
> > (since pix_fmt and actual logic is not changed at all with these
> > output AVFrame metadata changes):
> > - The first fix I did was for RGB->YCbCr still being flagged as RGB
> > (and thus encoders like the libx264 wrapper would gladly comply,
> > leading to bugs like issue #9132 )
> > - This one fixes the opposite conversion where your YCbCr input has
> > matrix coefficients configured, and the RGB output still has that
> > value as-is from the av_frame_copy_props call (and once again, encoder
> > complies).
>
> If there are no further comments, I will soon apply this to fix both
> sides of the YCbCr<->RGB conversion output in case the input format
> happens to have the matrix coefficients configured (and thus copied
> over by av_frame_copy_props). These can then be back-ported to 4.4
> since it was the first release to plug input/filtered AVFrames'
> metadata into output, which brought the issue of input metadata being
> passed through as-is up.
>
> The only question in my mind was whether to set it to
> AVCOL_SPC_UNSPECIFIED or AVCOL_SPC_RGB . I chose the latter one since
> the value literally matches what we are checking there: If output
> pix_fmt is RGB, set output value to RGB.

Applied as 2818b143929d86f6b67695b09bc7483da5cef434 .

Jan


More information about the ffmpeg-devel mailing list