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

[Benoit Fouet]

M?ns Rullg?rd wrote:
> 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.
>
>   

ok, thanks for the clarification.

-- 
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com