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 AC660484A8 for ; Wed, 3 Jul 2024 09:56:37 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E99A268D936; Wed, 3 Jul 2024 12:56:33 +0300 (EEST) Received: from relay.aitek.it (dns1.aitek.it [194.244.35.21]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CA15268D88E for ; Wed, 3 Jul 2024 12:56:27 +0300 (EEST) Received: from mail-server.aitek.it (mail-server.aitek.it [172.30.0.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay.aitek.it (Postfix) with ESMTPS id 66F4718007DD for ; Wed, 3 Jul 2024 11:56:28 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.aitek.it 66F4718007DD Message-ID: <20f24967-a341-4eba-adaf-5a0592d3c98f@aitek.it> Date: Wed, 3 Jul 2024 11:56:23 +0200 MIME-Version: 1.0 To: FFmpeg development discussions and patches References: <171999784133.21847.14283142110470102625@lain.khirnov.net> Content-Language: en-US, it In-Reply-To: <171999784133.21847.14283142110470102625@lain.khirnov.net> X-Aitek-Mail-Server-MailScanner-Information: Please contact the ISP for more information X-Aitek-Mail-Server-MailScanner-ID: 7E0A5858854.A45CA X-Aitek-Mail-Server-MailScanner: Found to be clean X-Aitek-Mail-Server-MailScanner-From: bernardo.pilarz@aitek.it X-Spam-Status: No 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: , From: Bernardo Pilarz via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Bernardo Pilarz Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 03/07/2024 11:10, Anton Khirnov wrote: > 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. > I ended up adding it to the AVCodecContext because 'avformat_find_stream_info()' invokes 'avcodec_parameters_to_context()' followed by 'avcodec_parameters_from_context()', thereby overwriting the entire 'codecpar' field of each stream in my format context. This also means that an AVCodecContext is in fact created even for streams with no codec ID. It's not clear to me how I can use AV_OPT_FLAG_EXPORT (it's my fault because I don't know the library so well). It might very well be the solution I am looking for, but I need some help in understanding how to implement it. The basic problem is I need to get the "codec name" information that is available in 'sdp_parse_rtpmap()' and is completely lost when the codec is not supported by FFmpeg. By the way, we are talking of AVMEDIA_TYPE_DATA streams, and codecs that are potentially custom/not widespread and therefore should probably be handled by the application rather than by ffmpeg itself. P.S.: I am currently only using FFmpeg to grab an RTSP stream. The audio and video streams might very well get decoded using FFmpeg later on, but so far I am only concerned with getting the compressed packets and being able to read their declared codec names. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ 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".