Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 00/17 v3] AVCodecContext and AVCodecParameters side data
Date: Tue, 5 Sep 2023 10:31:32 -0300
Message-ID: <1c67edf5-0933-eaed-dd3c-ef77412cf373@gmail.com> (raw)
In-Reply-To: <6eee5a65-516e-f165-43ee-4c513c4a1376@gmail.com>

On 9/5/2023 10:19 AM, Derek Buitenhuis wrote:
> On 9/4/2023 5:10 PM, James Almer wrote:
>>> * Warn users they need to update their code to not use stream side data (?).
>>>     Will my code just silently change behavior if it was using stream
>>>     side data? I legitimately do not know due to the above.
>>
>> How so? This, like any other deprecated field, remains working as it
>> always did until it's removed. The downstream users will see the
>> deprecation warning during compilation, and the doxy for the field
>> mentions the direct replacement. It's standard procedure.
> 
> I mean dowstream users who are relying on the current behavior of checking the
> first packet or stream side data - will it just cease to behave that
> way silently? That is, users relying on the *output/result* of the current
> behavior.

Users relying on global side data being in the first packet need to call 
the inject() lavf function to enable said functionality. As that 
function is now deprecated, they will get the relevant warning and be 
directed to the global side data API.
Nothing is being dropped silently. Their code will behave as usual 
during the deprecation period.

> 
>> I'll add a @deprecated comment to the doxy of
>> av_format_inject_global_side_data() to mention the aforementioned objective.
>>
>>> * Any useful doxy for API users or any example aside from function args and
>>>     very basic struct info.
>>
>> The helper functions are basically the same as the packet ones, and the
>> stream ones I'm deprecating. add(), new(), get(), etc. Example usage as
>> usual is in ffmpeg.c, but i think the doxy does a good job explaining
>> what they do.
> 
> I think neither ffmpeg.c nor doxy are very good ways to explain to API users
> both what they should use and why. The doxy relies on the fact you alreay know
> they exist and you need to use them and for what purpose. ffmpeg.c is the
> worst example for API users in the known universe.

What makes this different to every other API that was introduced with 
relevant documentation and references to it in the deprecacted/replaced API?

It's IMO very clear in the doxy: Instead of calling inject() and looking 
at packet side data, just look at the always available avctx side data.
Similarly, instead of looking or filling AVStream.side_data, you look or 
fill the field in AVStream.codecpar.
_______________________________________________
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".

  reply	other threads:[~2023-09-05 13:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04 15:03 James Almer
2023-09-04 15:03 ` [FFmpeg-devel] [PATCH 01/17] avcodec/avcodec: add side data to AVCodecContext James Almer
2023-09-04 22:08   ` James Almer
2023-09-05 11:07     ` Anton Khirnov
2023-09-05 11:26       ` James Almer
2023-09-05 11:37         ` Anton Khirnov
2023-09-05 11:52           ` James Almer
2023-09-04 15:03 ` [FFmpeg-devel] [PATCH 02/17] avcodec/codec_par: add side data to AVCodecParameters James Almer
2023-09-04 15:03 ` [FFmpeg-devel] [PATCH 03/17] avformat/avformat: use the side data from AVStream.codecpar James Almer
2023-09-04 22:09   ` James Almer
2023-09-04 15:03 ` [FFmpeg-devel] [PATCH 04/17] fftools/ffmpeg: stop using AVStream.side_data James Almer
2023-09-04 15:03 ` [FFmpeg-devel] [PATCH 05/17] fftools/ffplay: " James Almer
2023-09-04 15:03 ` [FFmpeg-devel] [PATCH 06/17] fftools/ffprobe: " James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 07/17] avcodec/hevcdec: check for DOVI configuration record in AVCodecContext side data James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 08/17] avcodec/decode: check for global side data " James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 09/17] fftools/ffmpeg: stop injecting stream side data in packets James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 10/17] fftools/ffplay: " James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 11/17] Revert "avcodec/mpeg12dec: Do not alter avctx->rc_buffer_size" James Almer
2023-09-04 15:37   ` Andreas Rheinhardt
2023-09-04 22:10     ` James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 12/17] avformat/demux: propagate the internal decoder's bitrate properties James Almer
2023-09-04 22:11   ` James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 13/17] avcodec/mpeg12dec: stop propagating AVCPBProperties side data James Almer
2023-09-04 22:11   ` [FFmpeg-devel] [PATCH 14/17] avcodec/avcodec: deprecate coded_side_data James Almer
2023-09-04 15:04 ` James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 15/17] avcodec/utils: move ff_add_cpb_side_data() to encoder code James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 16/17] avformat/demux: stop copying the internal AVCodecContext coded_side_data James Almer
2023-09-04 15:04 ` [FFmpeg-devel] [PATCH 17/17] fftools: stop propagating the encoder's coded_side_data James Almer
2023-09-04 15:37 ` [FFmpeg-devel] [PATCH 00/17 v3] AVCodecContext and AVCodecParameters side data Derek Buitenhuis
2023-09-04 16:10   ` James Almer
2023-09-05 13:19     ` Derek Buitenhuis
2023-09-05 13:31       ` James Almer [this message]
2023-09-05 14:06         ` Derek Buitenhuis

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=1c67edf5-0933-eaed-dd3c-ef77412cf373@gmail.com \
    --to=jamrial@gmail.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /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