From: Bernardo Pilarz via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: ffmpeg-devel@ffmpeg.org
Cc: Bernardo Pilarz <bernardo.pilarz@aitek.it>
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/avformat: Added codec_name to AVCodecContext and AVCodecParameters
Date: Wed, 3 Jul 2024 14:30:04 +0200
Message-ID: <6b43ca74-f3d0-44f9-907d-e8f2751bbf1f@aitek.it> (raw)
In-Reply-To: <20f24967-a341-4eba-adaf-5a0592d3c98f@aitek.it>
On 03/07/2024 11:56, Bernardo Pilarz via ffmpeg-devel wrote:
> 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.
>
>
How about putting this information in the stream's
'codecpar.coded_side_data'?
--
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".
next prev parent reply other threads:[~2024-07-03 12:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 7:47 Bernardo Pilarz via ffmpeg-devel
2024-07-03 8:02 ` Hendrik Leppkes
2024-07-03 8:10 ` Bernardo Pilarz via ffmpeg-devel
2024-07-03 9:10 ` Anton Khirnov
2024-07-03 9:56 ` Bernardo Pilarz via ffmpeg-devel
2024-07-03 12:30 ` Bernardo Pilarz via ffmpeg-devel [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-07-02 13:03 Bernardo Pilarz via ffmpeg-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6b43ca74-f3d0-44f9-907d-e8f2751bbf1f@aitek.it \
--to=ffmpeg-devel@ffmpeg.org \
--cc=bernardo.pilarz@aitek.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git