[FFmpeg-cvslog] r17956 - trunk/libavformat/utils.c

Baptiste Coudurier baptiste.coudurier
Sat Mar 14 23:24:56 CET 2009


On 3/14/2009 3:07 PM, Michael Niedermayer wrote:
> On Sat, Mar 14, 2009 at 02:06:17PM -0700, Baptiste Coudurier wrote:
>> Hi Michael,
>>
>> On 3/14/2009 8:51 AM, michael wrote:
>>> Author: michael
>>> Date: Sat Mar 14 16:51:46 2009
>>> New Revision: 17956
>>>
>>> Log:
>>> add avformat_seek_file()
>>>
>>> Modified:
>>>    trunk/libavformat/utils.c
>>>
>>> Modified: trunk/libavformat/utils.c
>>> ==============================================================================
>>> --- trunk/libavformat/utils.c	Sat Mar 14 11:18:18 2009	(r17955)
>>> +++ trunk/libavformat/utils.c	Sat Mar 14 16:51:46 2009	(r17956)
>>> @@ -1584,6 +1584,28 @@ int av_seek_frame(AVFormatContext *s, in
>>>          return av_seek_frame_generic(s, stream_index, timestamp, flags);
>>>  }
>>>  
>>> +int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, int64_t ts, int64_t max_ts, int flags)
>>> +{
>>> +    if(min_ts > ts || max_ts < ts)
>>> +        return -1;
>>> +
>>> +    av_read_frame_flush(s);
>>> +
>> Thanks a lot for taking care of this.
>>
>> I have a question, should we flush only if the seek has been sucessful ?
> 
> theoretically, we should not change anything if seeking fails but
> practically i think there are a few problems
> one because seeking changes the state and there is no code to undo that
> if we end up failing ...
> and the other thing i can see is that av_read_frame_flush() resets cur_dts
> which may be bad after seeking succeeded and the old API also did flush
> at the begin so i suspect some code depends on this ...
> 

I understand, would it be better to work on best approach for seek_file,
and fixing code depending on this behavior ?

Si it seems resetting cur_dts when seek fails may be bad too, do you
recall any code having problem with this reset ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org




More information about the ffmpeg-cvslog mailing list