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 6C8F742EDA for ; Fri, 9 Dec 2022 12:56:50 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6A7C568BCBD; Fri, 9 Dec 2022 14:56:49 +0200 (EET) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AA5DF68BC6C for ; Fri, 9 Dec 2022 14:56:43 +0200 (EET) Received: by mail-lj1-f182.google.com with SMTP id f16so4826131ljc.8 for ; Fri, 09 Dec 2022 04:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=r0NIfGb2FbgGFqdcj0N2YBJ0i4GRRPkqflUkCUjhKXQ=; b=jb1Dq7kTTkT+o+3XFzqQKCyXXCfqnKy2+6s1d2vJpaqXml0BKNsAdPgGnaqsRSpXpf 8TOMxrr8b0ngVBCdWL/GO9UDr5K1MKmiGmgIg+elaQnS5hj9SOTi+H483jDSH+IfmnzN g1WZe4yXgsnXG8zHmmA68gye3FXf7dLimbob4ujeSQ4hDsAfhbsnW9MBqZwWqI5g9jgA o3q36moa3PEtHjgZ6Z5jJ+4GGFdFQsZZa72FkyZCvjaUJk+22v51IAT1tDCPXrXK1Ekg b581Hlq5UWSthD8UAu7INdHtHuqztN9LySnWHraWhRVtGXQE2s06d8KChx/tRe0YkPHg fK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=r0NIfGb2FbgGFqdcj0N2YBJ0i4GRRPkqflUkCUjhKXQ=; b=PNBqQMoH9Mmskqg0YQ0PrZlfgS1UMZezCeuG9iBtj6N/k6VzzlzB8+Jglzstl4OS1w bhicWF+hi5rJy94VKVAGmDmDKf8TtB9LhcBoAd50M+7Us/Zzxqm37gwbfe1EpQ2dQX5y sQKReHZQRqnjBFH/1B8tQUtySyIP2j53IUKY1XjCo7V3/xkWgbbFtnTOKRsbXUcVBr2y ta86w3frPH06xWAwfq664cJDK34ITh/Isse8QO9ICmbCoIO3/qxQuYIUcrCRUXOBeHQa oZa51DhfhBifNM3yAPxx77DVzXvFZTAN6DHiAZT3mLFctK8YR7CXbxXR5lFQhxyM6RXY 8pUQ== X-Gm-Message-State: ANoB5ply78aq2UZoruVlU0lzD1AjMaxcjTL1jQ0zKufU+Z+0PMIInMWE CVdsQksK+xR8NO/wxLhPrIVVvyB7OmEIajthdArXkaV0uGg= X-Google-Smtp-Source: AA0mqf5VoDYQrypEpkRx08N4n07JLv2i05zd3QPx/ZtXcfHxeZj98QXoBXsaXKPHCfsOHUP/l7pVdxARzcJPjZ6fJQ8= X-Received: by 2002:a2e:a312:0:b0:27a:5b5:c573 with SMTP id l18-20020a2ea312000000b0027a05b5c573mr5098606lje.515.1670590601975; Fri, 09 Dec 2022 04:56:41 -0800 (PST) MIME-Version: 1.0 References: <20221209124941.GB66771@haasn.xyz> In-Reply-To: <20221209124941.GB66771@haasn.xyz> From: Hendrik Leppkes Date: Fri, 9 Dec 2022 13:56:27 +0100 Message-ID: To: FFmpeg development discussions and patches 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, Dec 9, 2022 at 12:49 PM 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. > Some sort of metadata has to be present to indicate this. It is not reasonable to assume users magically know what range a codec accepts, and then go out of their way to hardcode a list that might need full range. So 1 alone is entirely not reasonable, especially if you think eg. about an API user, who might create an app that may not show the immediate error message, or even have a button to insert a scaler. Instead the API should contain all the information for an application to make the right choices if necessary. Of course I already see people argue that JPEG accepts both depending on standards compliance etc, but the metadata should allow me to make the encoder work without needing to set standard compliance to some value. Or in other words, it should just work the most straight-forward way, without needing special knowledge about the encoder or even format. For mjpegenc this probably means it should only advertise full range. Or this information needs to somehow be context-sensitive and allow me to indicate the standards compliance value I care for. If the encoder indicates both limited and full, but errors out on limited, thats not useful. - Hendrik _______________________________________________ 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".