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 7DE5442EDA for <ffmpegdev@gitmailbox.com>; Fri, 9 Dec 2022 12:00:19 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1B13068BC88; Fri, 9 Dec 2022 14:00:16 +0200 (EET) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 841C868B29E for <ffmpeg-devel@ffmpeg.org>; Fri, 9 Dec 2022 14:00:09 +0200 (EET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F321B3200934 for <ffmpeg-devel@ffmpeg.org>; Fri, 9 Dec 2022 07:00:05 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Fri, 09 Dec 2022 07:00:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1670587205; x=1670673605; bh=iw+YBzAYZA9rqjbdamcX/bKFUtxq RDvp2ZcPAEWmU/I=; b=Kn/SA+8GuXYbc99tvAGSUv6pNcUWB/JhnvCRtSkvl80W IcxbPF27OdsHBO/yBxA8bfQHdo67dJMGI1KyxoAIkfmq3LbIULaMGaaOMkhoBoD/ YIoiMPvMuorEg8vU84G61lqtzIqiihWQvuG9T2ZzkNegFYgAJN27l2eTGCsPZibC P/n/KQVxvbIPr6SzPKgwgXq1TKn+rBk8JLu7ZpyDm9YUcdHT1pcsGQ6M1mXNaghk kRn9qVsZiUc+nAw3i5vf9JkMWGMBcR+o0v6W5/iTK1MDiMjqbmiJVPDndDOZ8mKF 3ah29XO1Z0bEN0/AfSo3RNGjsH+e9iCq68x4snXZ5g== X-ME-Sender: <xms:RCOTY4L_80OV51W4w4MwQDokYR557fQjwEKoUVVgonc70xyVzzu7xw> <xme:RCOTY4KyQLbDYzOn6AEMxWB_57OXSZZjl92lqP5cxA1Co6IecI4Dx8U7eyp89cTbP erjfmFkcuIjbkevaQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddvgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdflvggrnhdquegrphhtihhsthgvucfmvghmphhffdcuoehj sgesvhhiuggvohhlrghnrdhorhhgqeenucggtffrrghtthgvrhhnpeegkeehtddthfegke dtheevvddtleefffejgfetjeeviedtvefghfelleevieehgeenucffohhmrghinhepfhhf mhhpvghgrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepjhgssehvihguvgholhgrnhdrohhrgh X-ME-Proxy: <xmx:RCOTY4slJf1cei6DbfDddxC_SGbD-4d11FwYZ0YhoAdDNPkkLHkNqw> <xmx:RCOTY1ZKk5MP3xXrWm5L9N42_fhLv8lXLjrZnP0xX_CyFgBULpo8ZA> <xmx:RCOTY_auC4K0btQ6Jgj9ziR2j-MEzgH4i6R72nFD665o4M5tXQCU9g> <xmx:RSOTY2wK7cRwpoMsPJDya5LnncAKfw13qmpziVNruF1W8joE6yaIpg> Feedback-ID: i06904239:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id C67B615A0087; Fri, 9 Dec 2022 07:00:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <b37bdb8e-6e7a-4b6d-b020-593ab383846c@betaapp.fastmail.com> In-Reply-To: <20221209124941.GB66771@haasn.xyz> References: <20221209124941.GB66771@haasn.xyz> Date: Fri, 09 Dec 2022 12:59:42 +0100 From: "Jean-Baptiste Kempf" <jb@videolan.org> To: ffmpeg-devel <ffmpeg-devel@ffmpeg.org> 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 <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/b37bdb8e-6e7a-4b6d-b020-593ab383846c@betaapp.fastmail.com/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> 3. :) On Fri, 9 Dec 2022, at 12:49, 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. > > 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: > > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > > 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. > > Now, there are some solutions I can see for how to handle this case in > a non-YUVJ world: > > 1. Simply output an error, and rely on the user to insert a conversion > filter, e.g.: > > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > error: inputs to jpeg encoder must be full range > > $ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg output.jpg > ... works > > 2. Have the JPEG encoder take care of range conversion internally, by > using sws to convert limited to full range. > > 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. > > 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). > > 1 would be the most explicit but would break any existing pipeline that > includes conversion to jpeg, which is probably a very large number. > > 2 would be the least work, but violates abstraction boundaries. > > 3 would be the most work and is, IMO, of questionable gain. > > 4 would be both explicit and not break existing workflows. > > Thoughts? > _______________________________________________ > 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". -- Jean-Baptiste Kempf - President +33 672 704 734 _______________________________________________ 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".