On Sun, Dec 31, 2023 at 09:49:47PM +0000, Niklas Haas wrote:
> ffmpeg | branch: master | Niklas Haas <git@haasn.dev> | Tue Oct 31 13:52:53 2023 +0100| [45e09a30419cc2a7251e72689142e021ecdfe6d9] | committer: Niklas Haas
> 
> vf_scale: use colorspace negotiation API
> 
> This filter will always accept any input format, even if the user sets
> a specific in_range/in_color_matrix. This is to preserve status quo with
> current behavior, where passing a specific in_color_matrix merely
> overrides the incoming frames' attributes. (Use `vf_format` to force
> a specific input range)
> 
> Because changing colorspace and color_range now requires reconfiguring
> the link, we can lift sws_setColorspaceDetails out of scale_frame and
> into config_props. (This will also get re-called if the input frame
> properties change)
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=45e09a30419cc2a7251e72689142e021ecdfe6d9
> ---
> 
>  libavfilter/vf_scale.c | 188 +++++++++++++++++++++++++++----------------------
>  1 file changed, 103 insertions(+), 85 deletions(-)

This seems to remove metadata

./ffmpeg -f lavfi -i color=black -pix_fmt yuv422p10le -bitexact -vframes 1 -f framecrc -

 Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), yuv422p10le(tv, progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 38400 kb/s, 25 fps, 25 tbn
vs
 Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), yuv422p10le(progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 38400 kb/s, 25 fps, 25 tbn


 when its stored in a file, it results in a different output, example:
./ffmpeg -f lavfi -i color=black -pix_fmt yuv422p10le -bitexact -vframes 1 -c:v ffv1 -level 3 -y ffv1-lavf-black-4636-new.mkv


I have not investigated what is correct, but i would think "no range information"
would seem worse than whatever the correct is

thx


 [...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.