Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API

Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2071 bytes --]

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.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API

[Niklas Haas]

On Mon, 29 Jan 2024 04:19:43 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> 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

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)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3245 bytes --]

On Mon, Jan 29, 2024 at 07:49:49PM +0100, Niklas Haas wrote:
> On Mon, 29 Jan 2024 04:19:43 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> > 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
> 
> 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

thx

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

No snowflake in an avalanche ever feels responsible. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API

[Niklas Haas]

On Tue, 30 Jan 2024 23:36:37 +0100 Michael Niedermayer <michael@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 <michael@niedermayer.cc> wrote:
> > > 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
> > 
> > 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-request@ffmpeg.org with subject "unsubscribe".