[FFmpeg-devel] [PATCH 1/3] lavf: add AV_DISPOSITION_TIMED_THUMBNAILS

[Marton Balint]

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