Hi all, I currently encountered a problem in my software, where I am trying to seek backwards to a random keyframe in an xvid encoded video. For some reason when I seek to the same timestamp in AV_TIME_BASE units a couple of times, the time after the seek, queried by av_gettime() is never the same.
For seeking I use the following call: av_seek_frame(videoFormat_->getAVFormatContext(), -1, timestamp, AVSEEK_FLAG_BACKWARD); This is a comparison of the seeked values (the timestamp value above) and the values av_gettime returns: searched: 960000 actual: 1295230664051371 searched: 960000 actual: 1295230664054287 searched: 960000 actual: 1295230664056488 searched: 960000 actual: 1295230664058355 searched: 960000 actual: 1295230664060223 searched: 960000 actual: 1295230664061738 searched: 480000 actual: 1295230664063235 searched: 480000 actual: 1295230664066660 searched: 480000 actual: 1295230664070496 Note that a seek to a different keyframe actually seems to seek to almost the same timestamp in the video. As a matter of fact, independent to where I seek in the video, the next frame encoded is the first frame in the video, whereas I am currently trying to seek and return the keyframes only (the decoder gets flushed before the seek and encode part). I use the following ffmpeg build (since it is been used in a production environment (in osx, win and linux version) we didn't want to upgrade to a newer version until needed): FFmpeg version SVN-r22726, Copyright (c) 2000-2010 the FFmpeg developers built on Mar 29 2010 19:16:02 with gcc 4.2.1 (Apple Inc. build 5646) (dot 1) configuration: --prefix=/usr/local --enable-libmp3lame --enable-shared --enable-libfaad --disable-mmx --enable-gpl --enable-nonfree --enable-pthreads --enable-libxvid --extra-cflags=-I/opt/local/include --extra-ldflags=-L/opt/local/lib --arch=i386 libavutil 50.13. 0 / 50.13. 0 libavcodec 52.62. 0 / 52.62. 0 libavformat 52.59. 0 / 52.59. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0.10. 0 / 0.10. 0 Hyper fast Audio and Video encoder Did anybody already encounter this problem? Could this be a problem that is fixed in one of the newer libav versions? Thank you for your help Herbert Grasberger _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
