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

Benoit Fouet benoit.fouet
Wed Aug 13 09:47:50 CEST 2008


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 ?

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




More information about the ffmpeg-cvslog mailing list