On 2/8/2021 12:16 PM, Andreas Rheinhardt wrote:
typedef struct AVPacketList { +#if FF_API_INIT_PACKET AVPacket pkt; +#else + AVPacket *pkt; +#endif struct AVPacketList *next; } AVPacketList;As long as the packet-list functions use this structure, there will be an unnecessary allocation for every packet list entry. This is unnecessary even if one wants to make sizeof(AVPacket) not part of the ABI any more: Just move the next pointer to the front. Of course this will make this structure useless to someone who doesn't have functions that deal with AVPacketList entries. But given that there are no public functions dedicated to this task at all and given that anyone can write a packet list like the above without problems, this structure should be removed from the public API altogether.
I agree. I was considering to either make this an opaque struct, so new public API that makes use of it can be added down the line without worrying about what fields are defined in it, or just remove it. FFplay was defining its own struct based on it because it needed one extra field per element (Which will become unnecessary once an opaque user field is added to AVPacket).
(If the packet list helper functions were to be made public, the above would need to be revised. But I don't think that adding a packet list API that forces us to use a linked list should be made public.)
A public packet list API could have its internals hidden, and then use a FIFO (sizeof(AVPacket) will be allowed within lavc, so no allocs). As far as the user can see, the API would simply consume are return packet references. But that's for later, if ever.
_______________________________________________ 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".
