> On Jan 8, 2016, at 18:30, Marton Balint <c...@passwd.hu> wrote:
>
> 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?
This does explain that (though it's awkwardly-worded so I can see why it'd be
confusing). It contains the first packet.
>
>> */
>> #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?
My goal there is to get existing consumers not to treat them as "normal" video
streams, but I'd be OK with making this distinct instead.
>
> Thanks,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
