On Fri, 8 Jan 2016, Rodger Combs wrote:
[...]
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 95a645b..eaf6270 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -824,11 +824,17 @@ typedef struct AVIndexEntry {
#define AV_DISPOSITION_CLEAN_EFFECTS 0x0200 /**< stream without voice */
/**
* The stream is stored in the file as an attached picture/"cover art" (e.g.
- * APIC frame in ID3v2). The single packet associated with it will be returned
- * among the first few packets read from the file unless seeking takes place.
- * It can also be accessed at any time in AVStream.attached_pic.
+ * APIC frame in ID3v2). The first (usually only) packet associated with it
+ * will be returned among the first few packets read from the file unless
+ * seeking takes place. It can also be accessed at any time in
+ * AVStream.attached_pic.
Maybe you should clarify that if the stream contains multiple
packets, what will happen to AVStream.attached_pic. Will it contain all
packets? Or only the first? Or some random?
*/
#define AV_DISPOSITION_ATTACHED_PIC 0x0400
+/**
+ * The stream is sparse, and contains thumbnail images, often corresponding
+ * to chapter markers. Only ever used with AV_DISPOSITION_ATTACHED_PIC.
+ */
+#define AV_DISPOSITION_TIMED_THUMBNAILS 0x0800
I don't if it is better to use this flag along with attached pic
instead of keeping it distinct from it.
Changing the semantics of attached pics streams (multiple packets, timed
packets) seems quite a substantial change, so if it were up to me, I'd
rather keep this new flag distinct.
Where do you benefit if you use ATTACHED_PIC for this as well?
Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
