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 2931143D8A for ; Fri, 9 Dec 2022 12:45:36 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DE08268BC95; Fri, 9 Dec 2022 14:45:33 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 182AA68B5B0 for ; Fri, 9 Dec 2022 14:45:27 +0200 (EET) Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id B307448D91 for ; Fri, 9 Dec 2022 13:45:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1670589926; bh=tD3raYsBUyS6HKOplQEPUy7FFrOaPuwvyQgQsEV9QFs=; h=Date:From:To:Subject:In-Reply-To:References:From; b=X/Jemiyf9wW7zgc9ZsnKBDIJ1xTCEcj3FIbRj3tSTFpGGeGG5reIfX+T/pKxgPcNT W+58Xu7bayqQ7wHBjuRAB2QLdTEdo6OhQ5AZ6GdNFFP8O2T8XapcXg3qb/LYbO+GSo fcscE4upQsKhO6PzAKbWGTdBRu+wd0n+NOzzfpLg= Date: Fri, 9 Dec 2022 13:45:26 +0100 Message-ID: <20221209134526.GB119445@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: References: <20221209124941.GB66771@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline 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, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt wrote: > This is incorrect: Here are the pixel formats advertised by the mjpeg > encoder: > > .p.pix_fmts = (const enum AVPixelFormat[]) { > AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P, > AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P, > AV_PIX_FMT_NONE > }, > > ffmpeg only inserts the swscale filters, because said list is overridden > in get_compliance_normal_pix_fmts() in fftools/ffmpeg_filter.c. See > 059fc2d9da5364627613fb3e6424079e14dbdfd3. > Also notice that the encoder errors out if fed with limited range data > depending upon strict_std_compliance (see > ff_mjpeg_encode_check_pix_fmt()), which is very similar to the first > approach below; the override being in fftools implies that the breakage > of the first approach would be confined to users of fftools. Oh, you are right. So that presents an alternative to 4 - rather than an encoder flag, we can tie the auto-conversion in fftools to be tied to the strict_std_compliance check. I will try implementing this approach, it may be the best compromise in that it presents a clear upgrade path that doesn't break the common case. That said, there still is an encoder that has this problem: "amv". Currently, this only advertises YUVJ, but after YUVJ removal, it would be treated equivalently to mjpeg when `strict_std_compliance` is enabled. But given that this is a less common format, I think, such a regression would not be as big a concern. (And we can still special-case it in fftools, if we want to) _______________________________________________ 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".