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 4242B442D4 for ; Mon, 5 Sep 2022 05:05:10 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9ABCE68B3FD; Mon, 5 Sep 2022 08:05:07 +0300 (EEST) Received: from mail.overt.org (mail.overt.org [157.230.92.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0D5F968B1CE for ; Mon, 5 Sep 2022 08:04:56 +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 216563F3E3; Mon, 5 Sep 2022 00:04:54 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=overt.org; s=mail; t=1662354294; bh=o+baWIEQN/4i7QMfaQM4DiHhoZznsxrpERo6DuClBEY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ap7SiySS6Di65vbSjb95aOX97uz5leWwdf6ByI7Rbf7abUDv9rB4jnDjSkm66iADy Y5e0lH7jSno2SkIws1th3AMznNce7WaI7sPdPtqsaTAgyKQ1QyYtdNB5qsEdxhynBy MdrWrEYEGxup8JY6jEis8bnpnRCmwgDBRlrlX15EfXSMcR66FWuz1I0hSR2RpT5xoH ohRG7BbmStjM2AvfE9G4khiZmSxqQBT5OH8hvBx3CRkH+YXHsHQUwjos2zpS/V+NSi 3Krqdt/DmSMn9ng5egqvRaH4ga5y2xiREsNk6WxHJvz81RILIPUc/zXIw5FqMeacFn RzfGPwwrbiCmQ== Date: Sun, 4 Sep 2022 22:04:50 -0700 From: Philip Langdale To: "Xiang, Haihao" Message-ID: <20220904220450.706688ba@fido7> In-Reply-To: References: <20220829072751.22395-1-haihao.xiang@intel.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_qsv: add support for AV_PIX_FMT_VUYX 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, 5 Sep 2022 02:47:44 +0000 "Xiang, Haihao" wrote: > On Mon, 2022-08-29 at 14:01 +0000, Xiang, Haihao wrote: > > On Mon, 2022-08-29 at 08:17 -0300, James Almer wrote: > > > On 8/29/2022 4:27 AM, Xiang, Haihao wrote: > > > > From: Haihao Xiang > > > > > > > > AV_PIX_FMT_VUYX is used in FFmpeg for 8bit 4:4:4 content on > > > > Intel HW, and MFX_FOURCC_AYUV is used in the SDK > > > > > > Sounds like you want the VUYA pixfmt instead. > > > > AV_PIX_FMT_VUYX is used for 4:4:4 content in the VAAPI path, > > AV_PIX_FMT_VUYX is > > expected when creating vaapi urface. QSV is based on > > VAAPI under Linux, so AV_PIX_FMT_VUYX is expected too in the QSV > > path when creating vaapi surface. > > > > > > > > > --- > > > > libavutil/hwcontext_qsv.c | 8 ++++++++ > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/libavutil/hwcontext_qsv.c > > > > b/libavutil/hwcontext_qsv.c index 510f422562..a3350eae0f 100644 > > > > --- a/libavutil/hwcontext_qsv.c > > > > +++ b/libavutil/hwcontext_qsv.c > > > > @@ -119,6 +119,8 @@ static const struct { > > > > MFX_FOURCC_YUY2 }, > > > > { AV_PIX_FMT_Y210, > > > > MFX_FOURCC_Y210 }, > > > > + { AV_PIX_FMT_VUYX, > > > > + MFX_FOURCC_AYUV }, > > > > #endif > > > > }; > > > > > > > > @@ -1502,6 +1504,12 @@ static int map_frame_to_surface(const > > > > AVFrame *frame, > > > > mfxFrameSurface1 *surface) > > > > surface->Data.U16 = (mfxU16 *)frame->data[0] + 1; > > > > surface->Data.V16 = (mfxU16 *)frame->data[0] + 3; > > > > break; > > > > + case AV_PIX_FMT_VUYX: > > > > + surface->Data.V = frame->data[0]; > > > > + surface->Data.U = frame->data[0] + 1; > > > > + surface->Data.Y = frame->data[0] + 2; > > > > + surface->Data.A = frame->data[0] + 3; > > > > > > This will go wrong with VUYX. You need to use AV_PIX_FMT_VUYA. > > > > frame->data[0] + 3 is valid even if alpha channel is ignored in > > VUYX. Intel HW doesn't use the data in alpha channel actually, but > > the SDK uses Microsoft pixel > > format AYUV which is the alpha version, here set a valid address to > > alpha channel when mapping a VUYX AVFrame to a AYUV mfx surface. > > > > Is there more comment about this patch ? Wouldn't it be more correct to fill the Data.A with 0xFF rather than using the undefined value from the frame? I assume that the encoder actually drops the value completely so it ultimately doesn't matter, but it makes it clear that there is no alpha and if the encoder was to start preserving it, it would preserve the desired value. --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".