On 2/8/2021 11:43 AM, Andreas Rheinhardt wrote:
James Almer:
On 2/8/2021 11:37 AM, Andreas Rheinhardt wrote:
James Almer:
On 2/4/2021 4:09 PM, James Almer wrote:
Once removed, sizeof(AVPacket) will stop being a part of the public
ABI.
Signed-off-by: James Almer <jamr...@gmail.com>
---
libavcodec/avpacket.c | 23 +++++++++++++++--------
libavcodec/packet.h | 23 +++++++++++++++++++----
libavcodec/version.h | 3 +++
libavformat/avformat.h | 4 ++++
4 files changed, 41 insertions(+), 12 deletions(-)
Will add APIChanges entry and version bump, and apply soon.
Why the hurry? In fact, I have just sent a patchset that makes 3/50
redundant.
I'm talking about this patch, not the whole set. I'll give the rest some
more time in case others want to review or test (The vaapi stuff i can't
test, for example).
And yes, i saw the patches you sent that supersede 3/50, so assuming
your set is ok i was going to withdraw it.
I still don't see the reason to hurry things;
We're overdue for the bump and a new release before it, so it's best to
move forward at least a bit. And this change, if committed, should go in
before either of them.
actually I don't even this
direction at all, as it just leads to more allocations and frees. The dv
stuff is a good example of this, the mpegvideo_enc another.
The mpegvideo_enc was an extreme case the way i wrote it at first, yes.
And the DV stuff is not an issue for needing allocs, but for being
shared code between lavd and lavf, with one of the modules, the lavd
device, being undertested (Does any developer here use libiec61883? The
massive leak i fixed years ago was there for while, i recall).
New AVPacket fields are being discussed to be added, and if
sizeof(AVPacket) is public then the window to add them is very small
(About one month every 2 to 4 years). There's also the issue of field
initialization. Any new fields could end up uninitialized in the
scenario of users not calling av_init_packet, which is the reason
av_read_frame, av_packet_copy_props and av_get_packet do it on their own
(and it can lead to leaks if you pass them a valid, non empty packet,
for example).
So I suggested putting AVPacket in line with AVFrame, and two other
developers agreed. This change removes the above corner cases, relaxes
the requirements to add new fields, and forces the user to do things
right, and now that the old decode/encode API is being removed, it's the
ideal time to do it.
_______________________________________________
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".
