On 3/29/2021 9:57 AM, Nicolas George wrote:
James Almer (12021-03-29):
The idea for attached_pic afaik was that it's always available and easily
accessible to the user from the start, instead of just the one time the
demuxing process would return it in an av_read_frame() call.
The doxy for AV_DISPOSITION_ATTACHED_PIC even mentions that if you seek the
relevant packet may not be returned at all.
Yes, but was it a GOOD idea? For the convenience of the few applications
that actually use the attached pictures, libavformat will use memory in
all applications. It does not seem like a good compromise to me.
I think a better design would be some kind of:
int avformat_get_attached_pic(AVStream *st, AVPacket **packet, unsigned flags);
In the short run, it could just access the field, but in the long run it
could seek back to load the packet only when required.
Can this be done? id3v2 attached pics for many formats are handled by
the generic demux code in avformat_open_input() and not by the actual
demuxer. And in demuxers like asf, it seems to be done in read_header().
Would seeking be able to fetch these pictures again? The comment in the
AV_DISPOSITION_ATTACHED_PIC doxy makes me think it's not possible.
Personally, even if possible i think triggering a seek just to fetch an
attachment is inefficient and disruptive to the user's demuxing/decoding
process, and a step backwards considering it used to always be
available, for both seekable and non-seekable input, the latter which
will no longer be able to access the picture past the original packet.
Since applications need to update their API anyway, it is a good time to
decide if we want to change something.
Patches welcome.
Regards,
_______________________________________________
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".
