From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 31AC849D8E for ; Wed, 10 Apr 2024 12:59:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9194568CEC8; Wed, 10 Apr 2024 15:59:17 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 12AD968C30E for ; Wed, 10 Apr 2024 15:59:16 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id E32C82000A for ; Wed, 10 Apr 2024 12:59:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1712753956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r/RO1dTatVKELx7ytMXyPVqgxi+RuwlcCp8fCioBvwQ=; b=K6GJg65M/Gu/yQWf9mhdk/bMpCYJa9xnjN46Ltd0IFpDkgmvgVlvCkn3MEE+y40KBejFuX elPiUiWFopiBgbBPL2fobnJzugQvLW7+rXdGyyBDahgpAegv4wVIADVLGHf4o3wJoTDH35 8LK/kMSvPjKIkoemT0vY7aClQHIWxGol3whUX2PEpMYXGj8DLBo4HdvtRTMVA4Qydabclq accXJp5ydL3yRS0BvOuhefsjiiUF9hChJPSxe5FpObxOG7pnQbhwAkm7rGnUTAHYJOcyUf QcZItK4LuSRNyZRSh3m4SomNE0Lh7z1N+iq4lRX5oXLJmxudh4+wfyc8nKhhKA== Date: Wed, 10 Apr 2024 14:59:15 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240410125915.GN6420@pb2> References: <20240408125950.53472-1-ffmpeg@haasn.xyz> <20240408125950.53472-17-ffmpeg@haasn.xyz> <20240410012545.GM6420@pb2> <20240410122906.GB9919@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20240410122906.GB9919@haasn.xyz> X-GND-Sasl: michael@niedermayer.cc 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============5854530089129906979==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5854530089129906979== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KfMgYVQK5Cr6Ux3q" Content-Disposition: inline --KfMgYVQK5Cr6Ux3q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2024 at 12:29:06PM +0200, Niklas Haas wrote: > On Wed, 10 Apr 2024 03:25:45 +0200 Michael Niedermayer wrote: > > On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote: > > > From: Niklas Haas > > >=20 > > > To convert between color spaces/ranges, if needed by the codec > > > properties. > > > --- > > > fftools/ffmpeg_filter.c | 34 ++++++++++++++++++++++++++++++++++ > > > 1 file changed, 34 insertions(+) > >=20 > > 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 > >=20 > > https://trac.ffmpeg.org/attachment/ticket/5071/aletrek.mkv > >=20 > > also given fate does not change, it would make sense to add a testcase > > to fate that does cover this >=20 > Two notes: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. I have the feeling the colorspace negotiation has become a bit messy IIRC The way it was intended to work originally was to have a arbitrary filtergraph and then randomly simplify/merge bits of the filtergraph before picking "colorspaces" for each part. Then repeat this whole process a few times starting from the unsimplified graph. Then pick the best and that would be within a constant factor of the optimal solution for any arbitrary complex graph. Somehow this was never implemented as things worked okesich with just doing a single pass instead of multiple and then picking the best. I dont know how much this applies here now but i thought bringing up the original intended design was a good idea. Because it seems every problem in the negotiation is solved by adjusting the single pass steps or its orders while really it should have been multiple randomized passes. Maybe we never have to deal with complex enough filtergraphs where a single pass cant be made to work well and surely this here is not a complex one at all. But wanted to bring this up anyway because i think many people forgot or didnt even know the original idea was to do multiple passes so as to handle any arbitrary complex graph well. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. --KfMgYVQK5Cr6Ux3q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZhaNHwAKCRBhHseHBAsP q0obAJ0VkIsX251fmFg1+UHJWHLk+C5GZgCePYz9L6c9mm+RHBKoipi1OsAcx3I= =oNL/ -----END PGP SIGNATURE----- --KfMgYVQK5Cr6Ux3q-- --===============5854530089129906979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============5854530089129906979==--