[FFmpeg-devel] [PATCH 00/17 v3] AVCodecContext and AVCodecParameters side data

James Almer jamrial at gmail.com
Mon Sep 4 19:10:52 EEST 2023


On 9/4/2023 12:37 PM, Derek Buitenhuis wrote:
> On 9/4/2023 4:03 PM, James Almer wrote:
>>   71 files changed, 737 insertions(+), 415 deletions(-)
> 
> I see no document updates, commit messages, or deprecation warnings
> that would:
> 
> * Explain what and why this is happening - this should at the very
>    least be in the commit message(s), if not a doc somewhere. IRC or
>    pevious ML threads are not sufficient.

I'll mention it in a commit message. The idea is to properly propagate 
and make available the global side data in AVCodecContext, and no longer 
have to inject it in the first packet. This way global and frame 
specific side data is separate, and there's no need to copy and inject 
entries in several different places.

The new struct allows the simple use of a single set of helpers that 
don't depend on the context containing the side data.

> * 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'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 make no comment on the usefulness or utility of the change, but it is these
> sorts of things that make downstream API users experiences a little worse.
> 
> - Derek
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list