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 ED06143516 for ; Mon, 15 Aug 2022 17:42:33 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2D02368B93A; Mon, 15 Aug 2022 20:42:30 +0300 (EEST) Received: from mail.overt.org (mail.overt.org [157.230.92.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1541968B6E8 for ; Mon, 15 Aug 2022 20:42:19 +0300 (EEST) Received: from authenticated-user (mail.overt.org [157.230.92.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.overt.org (Postfix) with ESMTPSA id A4A0E3FB7B; Mon, 15 Aug 2022 12:42:16 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=overt.org; s=mail; t=1660585337; bh=Q1ZWSyH/ogyowviutrFZ+Z2d2P1TLEo4aw2n1icQQH0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oJs+vaWPnR4xTPdmUvIoG4Nnuvm2BMGS3BHLOR4dzNwbGV50iIRKgfcB/FenL1MiD CQP88Z1MAtsWdz3c39IM3Iu3Px3rjKFu3U1NTDEyBYU2pU7hNch0XhiMD3gVxbjptY L7L7SlWu0nH2qnURB+c1kuZ4xmQt6UKoGQXY75qIZWgosU5vHAWZKKq0ktfBeuaq29 67uQCyfmaoKmcQMaLxhm3kXDKvZ3klFC0T3pv1QIfTKDNZnocTWTg/cqeWlMHPa2k/ 1+nF/j+RA6tF0fL0yJHduxZ8PfgyygOmWXmX3bxSzwjoXZYflAlMEiKJK2oAEGhhnN okaVasT6vBaUA== Date: Mon, 15 Aug 2022 10:42:11 -0700 From: Philip Langdale To: "Xiang, Haihao" Message-ID: <20220815104211.573ed7ef@app.nyansa.com> In-Reply-To: <6df4920e8a38198bf293429b95d0fd30746f16d9.camel@intel.com> References: <20220814213313.37948-1-philipl@overt.org> <20220814213313.37948-2-philipl@overt.org> <6df4920e8a38198bf293429b95d0fd30746f16d9.camel@intel.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/pixfmt: Add Y216, Y410, and Y416 formats 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 Cc: 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 Mon, 15 Aug 2022 06:12:20 +0000 "Xiang, Haihao" wrote: > > Hi Philip, > > May we add new formats P012, Y212 and Y412 for 12bit contents ? I > agree with Mark's comment in > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200619015248.21873-1-fei.w.wang@intel.com/ > > > " > Tracking it separately does not seem fun - it looks to me like it > would require adding a new bit depth field to AVFrame. > > FFmpeg has always used pixfmt as defining both the memory layout and > which bits are used in that (so, for example, ARGB and 0RGB are not > the same thing), unlike most of the graphics APIs which tend to > define those two separately. > " I went through this same conversation a few years ago around the behaviour of nvdec, which uses p016 and yuv444p16 for 12bit content. All the same arguments were made about not introducing new pixel formats to just indicate stream depth and how we could add a new attribute but it would be a bunch of work, and to avoid bogging down and doing nothing, I just had nvdec/nvenc work with P016 (and honestly, nvidia don't even use P010 internally, it's P016 for >= 10bit) and it was fine. On the decoder side, there's no real problem, and on the encoder side, I think the key insight is that the encoder doesn't encoder to the frame's pixel format depth, it encodes to the depth _specified by the profile_. So even if you give it real 16bit frames in P016, if you are encoding Main12, you are going to get 12bit. Same for any future Main14. I'd argue this is the most correct way to handle it anyway. If the default profile we guess based on format isn't right, specify the one you actually want. > The bit depth is known if using p012 for 12bit contents in the > command below: > > $ ffmpeg -init_hw_device vaapi=vaapi:/dev/dri/renderD128 -f lavfi -i > yuvtestsrc -vf "format=p012,hwupload" -c:v hevc_vaapi -f null - > > If using p016 for 12bit contents, how do we know the bit depth is 12 > when converting yuv444 to p016 in the command below ? > > $ ffmpeg -init_hw_device vaapi=vaapi:/dev/dri/renderD128 -f lavfi -i > yuvtestsrc -vf "format=p016,hwupload" -c:v hevc_vaapi -f null - That's also my answer to your command lines: Specify the profile if the default that we guess from the format isn't what you want. It's not the say that I don't think a bit depth field on AVFrames is a terrible idea, but it's a huge project and not one that I'm interested in blocking on. We'd get nothing done otherwise. I'm very comfortable with the heuristics I've added in this patch set vs the heuristics we had before. It'll be a while before we get 14bit and profile selection actually becomes ambiguous. I don't know if QSV has different constraints that make this approach impossible but it works fine for VAAPI, and I would imagine that when implementing Microsoft's directx interfaces you have to do something similar as they fix the set of usable formats for you. --phil _______________________________________________ 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".