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 9E78D46491 for ; Sun, 18 Jun 2023 11:10:34 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 37CDB68BF1A; Sun, 18 Jun 2023 14:10:31 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3A51E68B0F0 for ; Sun, 18 Jun 2023 14:10:25 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id DEEC52404EC for ; Sun, 18 Jun 2023 13:10:24 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WrFAyW6OC4hO for ; Sun, 18 Jun 2023 13:10:24 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 42AD02404EA for ; Sun, 18 Jun 2023 13:10:24 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 2E4BE1601B2; Sun, 18 Jun 2023 13:10:24 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <168665932811.3843.12542444692785643776@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Sun, 18 Jun 2023 13:10:24 +0200 Message-ID: <168708662415.21886.6377526740221214688@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 2/5] vulkan_decode: use the new AVHWFramesContext.opaque field 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: Quoting Lynne (2023-06-13 14:53:35) > Jun 13, 2023, 14:29 by anton@khirnov.net: > > > Quoting Lynne (2023-06-13 06:19:34) > > > >> This depends on the previous patch, and allows moving the codec > >> profile to the new AVHWFramesContext.opaque field. > >> > >> Patch attached. > >> > >> > >> From f992905250062711fab7522906a573ff8ab5f716 Mon Sep 17 00:00:00 2001 > >> From: Lynne > >> Date: Tue, 13 Jun 2023 06:10:20 +0200 > >> Subject: [PATCH 2/5] vulkan_decode: use the new AVHWFramesContext.opaque field > >> > >> --- > >> libavcodec/vulkan_decode.c | 56 +++++++++++++++++++++++--------------- > >> libavcodec/vulkan_decode.h | 6 ++-- > >> 2 files changed, 37 insertions(+), 25 deletions(-) > >> > > > > This will not work, because the callers are not required to call > > avcodec_get_hw_frames_parameters() and can create the frames context > > themselves. > > > > Indeed they are. This commit doesn't break this. > > > > The decoder is then not allowed to make any assumptions about the opaque > > field. > > > > Exactly. This is just for the case that the user calls avcodec_get_hw_frames_parameters. > Then, we need somewhere to put the profile. > The opaque field is only set, it is never read in this particular case. > Since it's libavcodec creating the frames context in this case, and since the user > explicitly asked for frames parameters to be set, I don't think it's a problem > to set a public field, much the same way the width, height and sw_format > values are set. > > If the user doesn't call avcodec_get_hw_frames_parameters, the rest > of the code wouldn't notice. The rest of the decoder code gets the profile > via the create_pnext chain (where the pointers to the profile structs must be). > So users can attach their own profile, and store it wherever, including > the opaque field. > > This commit also fixes the situation where a users calls > avcodec_get_hw_frames_parameters, gets a frame parameters. > destroys the decode context, and uses the same frames context > which was created for another decoder. Why can't you use the existing user_opaque field? -- Anton Khirnov _______________________________________________ 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".