On Wed, 10 Apr 2024 12:29:06 +0200 Niklas Haas <ffm...@haasn.xyz> wrote: > On Wed, 10 Apr 2024 03:25:45 +0200 Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote: > > > From: Niklas Haas <g...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
