Re: [FFmpeg-devel] [PATCH v2 16/17] fftools/ffmpeg_filter: propagate codec yuv metadata to filters

[Niklas Haas <ffmpeg@haasn.xyz>]

On Wed, 10 Apr 2024 12:29:06 +0200 Niklas Haas <ffmpeg@haasn.xyz> wrote:
> On Wed, 10 Apr 2024 03:25:45 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> > On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote:
> > > From: Niklas Haas <git@haasn.dev>
> > > 
> > > To convert between color spaces/ranges, if needed by the codec
> > > properties.
> > > ---
> > >  fftools/ffmpeg_filter.c | 34 ++++++++++++++++++++++++++++++++++
> > >  1 file changed, 34 insertions(+)
> > 
> > I presume this is intended to change some cases
> > iam asking because it does
> > for example, this one
> > -i aletrek.mkv -t 1 -bitexact  /tmp/file-aletrek-palette.mkv
> > has the output file change slightly
> > 
> > https://trac.ffmpeg.org/attachment/ticket/5071/aletrek.mkv
> > 
> > also given fate does not change, it would make sense to add a testcase
> > to fate that does cover this
> 
> Two notes:
> 
> 1. The only difference between the `master` behavior and the new
>    behavior is that the file is marked as limited range instead of as
>    unspecified. However, this is the correct tagging, as the actual
>    output *is* limited range.
> 
> 2. While not *broken* per se, this is actually still a bug - in this
>    case, since the input is basically full range, we should actually try
>    and output full range by default.
> 
> The reason it doesn't output full range here is because a consequence of
> the fact that format reduction happens *before* the logic in
> pick_format() fixes all non-YUV links to be tagged as PC/RGB-only. So
> the format reduction logic just sees that vf_scale can output any range
> in this scenario (true) and picks TV range output as the default,
> resulting in a conversion from the PC range input to a TV range output.
> 
> The easiest solution would be to not blindly pick the first here, but to
> instead try and pick a colorspace and range matching the input (if one
> exists). But this may still break in more complicated scenarios where
> the dependence on the forced format spans several filters.
> 
> The more correct solution would probably be to explicitly reduce only
> the format first (going through all the steps) and then negotiate
> everything that depends on the format in an entirely separate step.
> 
> I'll see if I can do something about this situation, though it's
> ultimately not a high priority as it's not a regression compared to the
> status quo - just something that we could definitely improve.

Alternatively, a third simple fix would be to make buffersrc explicitly
request PC range in this scenario (e.g. RGB/PAL8 input), but that feels
like a sort of a hack.

> 
> > 
> > thx
> > 
> > [...]
> > -- 
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > 
> > What does censorship reveal? It reveals fear. -- Julian Assange
> > _______________________________________________
> > 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".
_______________________________________________
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".