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. 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".
