On Tue, Aug 31, 2021 at 1:14 AM Jan Ekström <jee...@gmail.com> wrote: > > On Sun, Aug 29, 2021 at 10:05 PM Jan Ekström <jee...@gmail.com> wrote: > > > > On Sun, Aug 29, 2021 at 9:21 PM Paul B Mahol <one...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".