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 B178044F33 for ; Fri, 9 Dec 2022 16:50:24 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7D30A68BD05; Fri, 9 Dec 2022 18:50:21 +0200 (EET) 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 E7FFE68BA5F for ; Fri, 9 Dec 2022 18:50:14 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id E0FE620007 for ; Fri, 9 Dec 2022 16:50:13 +0000 (UTC) Date: Fri, 9 Dec 2022 17:50:11 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20221209165011.GF3806951@pb2> References: <20221209124941.GB66771@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20221209124941.GB66771@haasn.xyz> Subject: Re: [FFmpeg-devel] Towards YUVJ removal 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="===============4295474735680588908==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4295474735680588908== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LP3HGykwGcUp63ex" Content-Disposition: inline --LP3HGykwGcUp63ex Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 09, 2022 at 12:49:41PM +0100, Niklas Haas wrote: > So, as was discussed at the last meeting, we should move towards > removing YUVJ. I want to gather feedback on what appears to be to the > major hurdle, and possible ways to solve it. >=20 > The basic major issue is how to handle the case of combining limited > range input with an encoder for a format that only accepts full range > data. The common case, for example, would be converting a frame from a > typical video file to a JPEG: >=20 > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg >=20 > Currently, this works because the JPEG encoder only advertises YUVJ > pixel formats, and therefore ffmpeg auto-inserts swscaler to convert > from limited range to full range. But this depends on conflating color > range and pixel formats, which is exactly what has been marked > deprecated for an eternity. >=20 > Now, there are some solutions I can see for how to handle this case in > a non-YUVJ world: >=20 > 1. Simply output an error, and rely on the user to insert a conversion > filter, e.g.: >=20 > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > error: inputs to jpeg encoder must be full range >=20 > $ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=3Dout_range=3Djpeg= output.jpg > ... works >=20 > 2. Have the JPEG encoder take care of range conversion internally, by > using sws to convert limited to full range. >=20 > 3. Allow filters to start exposing color space metadata as part of > filter negotiation, and then auto-insert swscaler whenever colorspace > conversion needs to happen as a result of filters not accepting the > corresponding color metadata. This would also allow more than just > conversion between limited/full range. >=20 > 4. Combine approach 1 with an encoder flag for "supports full range > only", and have ffmpeg.c auto-insert a scale filter as the last step > before the encoder if this flag is set (and input is limited range). >=20 > 1 would be the most explicit but would break any existing pipeline that > includes conversion to jpeg, which is probably a very large number. >=20 > 2 would be the least work, but violates abstraction boundaries. >=20 > 3 would be the most work and is, IMO, of questionable gain. >=20 > 4 would be both explicit and not break existing workflows. 3 is nice but is hard as it draws filter negotiation in and that has to do something even for non trivial filter networks. 4 with the complexity in jpeg as disscussed elsewhere in this thread also may or may not be as clean as it sounds here but both 3 and 4 with some amendment sound reasonable to me another option would be to either improve=20 A. general "supported value" information a encoder should be able to tell the caller what it supports depending on some parameter, for example depending on profile and level or std compliance. This would mean implementing AVClass.query_ranges() and using av_opt_query_ranges() IIRC B. error reporting so that=20 failures become machiene readable.=20 aka, "this failed because color range is not X || std complicance is > Y" the lib user could then retry by applying the change if that is within what the usecase wants Both A and B obvioulsy have a much broader use than YUVJ removal thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt compla= in" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" --LP3HGykwGcUp63ex Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY5NnPAAKCRBhHseHBAsP q8oFAJ48adchb6GHgEHsznjgtmZKFXeHGwCeP7aZtcrasppRLu82C8zv/cUFFDI= =Auy+ -----END PGP SIGNATURE----- --LP3HGykwGcUp63ex-- --===============4295474735680588908== 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". --===============4295474735680588908==--