[FFmpeg-cvslog] r14715 - trunk/libavformat/avformat.h

[Måns Rullgård]

Benoit Fouet <benoit.fouet at purplelabs.com> writes:

> M?ns Rullg?rd wrote:
>> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
>>
>>   
>>> Hi Mans,
>>>
>>> M?ns Rullg?rd wrote:
>>>     
>>>> bcoudurier <subversion at mplayerhq.hu> writes:
>>>>
>>>>       
>>>>> Author: bcoudurier
>>>>> Date: Tue Aug 12 19:28:00 2008
>>>>> New Revision: 14715
>>>>>
>>>>> Log:
>>>>> increase MAX_REORDER_DELAY and pts_buffer size to 16, max for h264 atm
>>>>>
>>>>> Modified:
>>>>>    trunk/libavformat/avformat.h
>>>>>
>>>>> Modified: trunk/libavformat/avformat.h
>>>>> ==============================================================================
>>>>> --- trunk/libavformat/avformat.h	(original)
>>>>> +++ trunk/libavformat/avformat.h	Tue Aug 12 19:28:00 2008
>>>>> @@ -390,14 +390,17 @@ typedef struct AVStream {
>>>>>
>>>>>      int64_t nb_frames;                 ///< number of frames in this stream if known or 0
>>>>>
>>>>> -#define MAX_REORDER_DELAY 4
>>>>> -    int64_t pts_buffer[MAX_REORDER_DELAY+1];
>>>>> +#if LIBAVFORMAT_VERSION_INT < (53<<16)
>>>>> +    int64_t unused[4+1];
>>>>> +#endif
>>>>>         
>>>> What good does this do?  It still breaks ABI.  Or is it only used
>>>> internally?
>>>>       
>>> You might mean API ? It does not break ABI, field still exists and is
>>> the same size as before, and yes it is only used internally.
>>
>> If it were used externally, those external users would be accessing a
>> different array than the internal code, which amounts to ABI breakage
>> in my view.  Other fields remain compatible, of course.
>
> and the AVStream structure size changed, in any case... so writing
> internally to the new pts_buffer could result in overwriting user data.
> Or did I miss something ?

Users shouldn't allocate the structs themselves.

-- 
M?ns Rullg?rd
mans at mansr.com