On Tue, 30 Jan 2024 23:36:37 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Mon, Jan 29, 2024 at 07:49:49PM +0100, Niklas Haas wrote: > > On Mon, 29 Jan 2024 04:19:43 +0100 Michael Niedermayer > > <mich...@niedermayer.cc> wrote: > > > On Sun, Dec 31, 2023 at 09:49:47PM +0000, Niklas Haas wrote: > > > > ffmpeg | branch: master | Niklas Haas <g...@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 > > > > Looking at this quickly, what is happening here is not that vf_scale is > > stripping metadata, it's that vf_scale used to *add* default metadata after > > a pixel format conversion - even though it did not touch the pixel > > range, and the incoming frames were untagged. This was arguably a bug. > > The new behavior is actually less surprising here - the vsrc generates > > untagged frames, so vf_scale preserves them being untagged. > > > > (Observe -vf showinfo,format=yuv422p10le,showinfo before vs after patch) > > > > In any case, the *proper* fix here would be to make vsrc_testsrc aware > > of the colorspace negotiation API. Ideally, it should switch from > > ff_draw_init to ff_draw_init2, and use the negotiated YUV colorspace and > > range. (pal(75|100)bars are also bugged) > > Thanks alot for analyzing, ive added a note locally so if i run into another > case ill remember > > I dont have time ATM to fix vsrc_testsrc
Sent two patches to fix all of the issues I saw with vsrc_testsrc (and some other ff_draw_init() callers) The status quo of outputting *untagged* limited range YUV by default persists, as this was an intentional design choice, and it's consistent with the status quo. That said, it would be trivial to change. _______________________________________________ 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".
