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 671544A61C for ; Wed, 3 Jul 2024 09:10:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E434368D964; Wed, 3 Jul 2024 12:10:55 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E62D168D8BE for ; Wed, 3 Jul 2024 12:10:48 +0300 (EEST) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=lXpBXauV; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 7AB21240DAC; Wed, 3 Jul 2024 11:10:48 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id jD8OoZ7Qpv6j; Wed, 3 Jul 2024 11:10:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1719997847; bh=bXeyc64ABkLSXhrtIg+T2n6NbS+eU26LHSeRw+/lVGw=; h=Subject:From:To:Cc:In-Reply-To:References:Date:From; b=lXpBXauVLKIh70H0CetvfotAkO0XZ+YZozV3dh6OeYaX4mYL3jZXB1QAyohmh3UHh BP1bxynCkxgLEl0D4oOY39GVs8cuklnCDufabGuUOxm6AQ5/kiJYdcl4NPRUe2AbJG v3lZdfN2BapwjZawf9Z3gKXr+3X26vo8peAiZsbMx1JodIujZ3UCbOTOhaGmFpmTwH rJ7EQw9UJs4AmebCZE3SEthLmr6JoFVw14+YG0DsdXJ/H05/26FwWfuruvrr5inCJV lNmWKaASoShiW06hAVkqcULDTf0nskopcrV9vWluL5s7nVfoEuM7Lu3TxZPENJCeLa jBJNRkfnsr5BA== 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 7DCB52404E5; Wed, 3 Jul 2024 11:10:47 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 58F7C1601B9; Wed, 3 Jul 2024 11:10:41 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: Mail-Followup-To: FFmpeg development discussions and patches , Bernardo Pilarz Date: Wed, 03 Jul 2024 11:10:41 +0200 Message-ID: <171999784133.21847.14283142110470102625@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/avformat: Added codec_name to AVCodecContext and AVCodecParameters 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: Bernardo Pilarz 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 Bernardo Pilarz via ffmpeg-devel (2024-07-03 10:10:15) > >> + char *codec_name; > >> const struct AVCodec *codec; > >> enum AVCodecID codec_id; /* see AV_CODEC_ID_xxx */ > >> > > Adding a new field here is an ABI break, it would need to go at the > > end of the struct. > > > > In general, I feel like this might be better served to go into > > metadata though, especially as very few containers have a string codec > > identifier to begin with. > > I would be very glad to do it the right way, but I need some guidance > since this is the first time I try to contribute to FFmpeg. > > The problem that I am trying to solve is receiving metadata from an RTSP > stream (in example, ONVIF metadata identified by the codec name > 'vcd.onvif.metadata'). > This is data that the application will want to handle on its own (and > not through FFmpeg). > > Can you guide me on how to do this properly? First of all, this should definitely NOT go into AVCodecContext, since the entire premise is that we have no codec ID and hence no decoders or encoders, so a codec context makes no sense. Next, the idea that you can define a generic container-independent "codec name" sounds dubious to me, as they are not universally standardized. You'd either have to define precisely what can the API caller expect in there, or make this a private AV_OPT_FLAG_EXPORT option of your demuxer. I'd suggest the second, as it's much simpler, though IIRC we do not yet support per-stream private options. -- 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".