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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
