[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