support seeking by decoding from the begin

[ami_stuff]

The file seeks correctly with WMP/MPC, maybe it's possible to fix seeking for this kind of file in FFmpeg.

(not a regression)

​http://www.datafilehost.com/download-2b89c308.html

C:\>ffmpeg -i EVBPIC.AVI
ffmpeg version git-N-30698-g39dbe9b, Copyright (c) 2000-2011 the FFmpeg develope
rs
  built on Jun 10 2011 22:10:00 with gcc 4.5.3
  configuration: --enable-gpl --enable-version3 --enable-memalign-hack --enable-
runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libo
pencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --
enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger
 --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enabl
e-libx264 --enable-libxavs --enable-libxvid --enable-zlib --disable-outdev=sdl -
-pkg-config=pkg-config
  libavutil    51.  8. 0 / 51.  8. 0
  libavcodec   53.  7. 0 / 53.  7. 0
  libavformat  53.  3. 0 / 53.  3. 0
  libavdevice  53.  1. 1 / 53.  1. 1
  libavfilter   2. 15. 0 /  2. 15. 0
  libswscale    0. 14. 1 /  0. 14. 1
  libpostproc  51.  2. 0 / 51.  2. 0
[avi @ 01DCA600] max_analyze_duration 5000000 reached at 5000000
Input #0, avi, from 'EVBPIC.AVI':
  Duration: 00:03:17.00, start: 0.000000, bitrate: 266 kb/s
    Stream #0.0: Video: msvideo1, pal8, 640x480, 1 fps, 1 tbr, 1 tbn, 1 tbc
    Stream #0.1: Audio: pcm_u8, 22050 Hz, 1 channels, u8, 176 kb/s
At least one output file must be specified

[Carl Eugen Hoyos]

Isn't this more related to msvideo1 than avi?

[DonMoir]

EVBPIC.AVI is a file that exact timestamp seeking fixes completely. There are many index_entries but only the first entry is marked as a keyframe. There are no issues with seeking on this file if exact timestamp seeking is used. That is, it's very quick.

So yes, nice if exact timestamp seeking was put into ffmpeg. The current alternative is do this from a higher level.

If exact timestamp seeking is put into ffmpeg, it will be necessary that the interrupt_callback (or similiar) is called so the app has a chance to abort or put it's seek thread to sleep briefly.

[reimar]

Not sure what you exactly you mean to say and what you mean by "exact timestamp seeking".
However

There are many index_entries but only the first entry is marked as a keyframe.

that means that the file is either broken or really stupidly encoded.
Also I suspect that seeking works just fine with ffmpeg if you put the -ss after the -i instead of in front.

[DonMoir]

By exact timestamp seeking I mean if you request an arbitrary time, it will make a best effort to get there and not stop just because the file may only have one first keyframe.

I don't create the files but many files exist that have this problem with ffmpeg. Mostly when you run into a case like this, it tends to be a simple file that can be easily seeked to at any position with a little extra work. This is the users expected behavior regardless of how it's been encoded. It's rare for a high res file to have this problem but if it does it can be dealt with appropriately.

You try ffplay or MPlayer and see how well they do. I already have it handled in my own app. I don't mind if it's a higher level step personally, but it could give ffmpeg a better and more expected behavior.

[Carl Eugen Hoyos]

Replying to DonMoir:

I don't create the files but many files exist that have this problem with ffmpeg.

We definitely need more failing samples, please provide some.

[DonMoir]

These type of files fall into a category where the main background does not change often and it is appropriate for them to have one or just a few keyframes.

first_keyframe_only_confused.mov and first_keyframe_only_count.mkv are the same as evbpic.avi in the sense they all only have 1 first keyframe. They also can be seeked into easily and quickly if a little more work is performed when seeking.

no_keyframes_filecopy.avi has no keyframes and so the first frame must be artificially marked as a keyframe for it to work and then proceed with exact timestamp seeking on it.

The same problem is going to exist on files where the keyframes are sparse, but more than one, in that you will notice large jumps when trying to seek with ffmpeg.

[DonMoir]

only_two_keyframes_flyby.avi is an example of sparse keyframes but more than one. This is also easy to deal with.

[Michael Niedermayer]

EVBPIC.AVI does contain only 1 keyframe, seeking thus requires decoding from teh begin