From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 9D6B3485F7 for <ffmpegdev@gitmailbox.com>; Wed, 10 Apr 2024 10:31:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7BBC168CDD9; Wed, 10 Apr 2024 13:31:28 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2277B68AFE7 for <ffmpeg-devel@ffmpeg.org>; Wed, 10 Apr 2024 13:31:22 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1712745081; bh=H//cB/SDnSZs7rF2fkAfWsPbrarzgMWm5AGCrpUUcCs=; h=Date:From:To:Subject:In-Reply-To:References:From; b=pxWws6Z+ctf0Dqz9hS1WLkSBB66w+b7pNqJDY1V9Un4mS2kzVY6C6zKsOnjIvI4kJ i1cPlGzKCtHDgbC/uyO2C8MwG9NDxEGSrIOUVI1KzEB0rMdMDcdyFghSUGHnnhFQhu haH0q7ZVSLcWqgBuE9z/nt3VQVCjywYcKzSak8CM= Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id D0BE840941 for <ffmpeg-devel@ffmpeg.org>; Wed, 10 Apr 2024 12:31:21 +0200 (CEST) Date: Wed, 10 Apr 2024 12:31:21 +0200 Message-ID: <20240410123121.GD9919@haasn.xyz> From: Niklas Haas <ffmpeg@haasn.xyz> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> In-Reply-To: <20240410122906.GB9919@haasn.xyz> References: <20240408125950.53472-1-ffmpeg@haasn.xyz> <20240408125950.53472-17-ffmpeg@haasn.xyz> <20240410012545.GM6420@pb2> <20240410122906.GB9919@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [PATCH v2 16/17] fftools/ffmpeg_filter: propagate codec yuv metadata to filters X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20240410123121.GD9919@haasn.xyz/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> 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".