[FFmpeg-cvslog] r17956 - trunk/libavformat/utils.c
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
>>> add avformat_seek_file()
>>> 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