On 3/29/2021 10:20 AM, Nicolas George wrote:
James Almer (12021-03-29):
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.
As I said, at worse it accesses a field just like now. So of course it
can be done.
The point is that having a function to get the packet rather than just a
pointer gives us more freedom to extend the API later.
Not against it in that case, even if it will probably never stop just
being an abstraction layer to fetch an always available packet, but know
that this will kill Andreas' idea of defining how the (until now) public
packet can be used to simplify attached pics in muxing scenarios, or
make it considerably more complex to the point it's no longer worth it.
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".
