[FFmpeg-devel] FFmpeg 4.4

[James Almer]

On 3/10/2021 7:37 AM, Michael Niedermayer wrote:
> On Tue, Mar 09, 2021 at 05:55:55PM -0300, James Almer wrote:
>> On 3/9/2021 5:47 PM, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> I will branch release/4.4 soon
>>> then like always leave some time for testing, bugfixes, ... and then
>>> make FFmeg 4.4 from release/4.4, its too long since 4.3
>>>
>>> Thanks
>>
>> I have three API changes/additions/deprecations on the ml, some for months
>> now, that i want in 4.4 in order for them to be present in the last release
>> using the current major library versions. This is so users have a good
>> amount of time to notice them and adapt their code.
>> It's not be as nice if they start noticing any new deprecations introduced
>> today in a release made several months from now.
>>
>> These are "deprecate av_init_packet() and sizeof(AVPacket) as part of the
>> ABI", "avutil/buffer: change public function and struct size parameter types
>> to size_t", and "avcodec: add a get_encoder_buffer() callback to
>> AVCodecContext".
>> The first two still need to be LGTM's. The latter was LGTM' by Lynne, but
>> I'm still waiting for Mark to give his.
> 
> sizeof(AVPacket) should not be part of the public API/ABI, well it should
> never have been.
> Do we maybe need a list of release blocking issues on trac or some tag or
> something ? So issues like this are more vissible to everyone, its not
> optimal to get a list of release blockers relatively late, then rush it
> and then have a higher risk for regressions

I guess i was not insistent enough to get reviews for my patches.
You did look at some of them but only to find compilation issues and/or 
regressions, and without a LGTM i can't say it was approved.

The AVBufferRef change should generate no issues whatsoever since it 
just schedules a type change. No actual change will take place until the 
bump.
The get_encoder_buffer() one should also have no effect until encoders 
start being ported to it, and doing that in time for 4.4 is not 
important, only introducing the callback so users know it's there and 
can be ready for when the old encode API is gone after the bump if they 
still wish to provide their own buffers.
The AVPacket one could use some testing not for the actual scheduled 
change or the deprecation, which has no effect on library behavior, but 
because I'm also removing all instances of av_init_packet() to avoid a 
deprecation warning fest when compiling the libraries, and some of them 
i can't test.

> 
> anyway, tell me once the blockers are resolved, and please dont rush, its
> better if we are a few days later than if there are some major bugs introduced
> 
> Thanks
> 
> [...]
> 
> 
> _______________________________________________
> 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".
>