Opened 5 years ago

Last modified 3 years ago

#296 open enhancement

support seeking by decoding from the begin

Reported by: ami_stuff Owned by:
Priority: wish Component: undetermined
Version: git-master Keywords: msvideo1 seek
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Attachments (4)

first_keyframe_only_confused.mov (619.9 KB) - added by DonMoir 4 years ago.
first_keyframe_only_count.mkv (20.2 KB) - added by DonMoir 4 years ago.
no_keyframes_filecopy.avi (9.3 KB) - added by DonMoir 4 years ago.
only_two_keyframes_flyby.avi (1.2 MB) - added by DonMoir 4 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 years ago by cehoyos

  • Reproduced by developer set
  • Status changed from new to open
  • Version changed from unspecified to git-master

Isn't this more related to msvideo1 than avi?

comment:2 Changed 5 years ago by cehoyos

  • Keywords msvideo1 seek added

comment:3 Changed 4 years ago by DonMoir

This 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.

Version 0, edited 4 years ago by DonMoir (next)

comment:4 Changed 4 years ago by 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.

comment:5 follow-up: Changed 4 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 4 years ago by cehoyos

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.

Changed 4 years ago by DonMoir

Changed 4 years ago by DonMoir

Changed 4 years ago by DonMoir

comment:7 Changed 4 years ago by 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.

Last edited 4 years ago by DonMoir (previous) (diff)

Changed 4 years ago by DonMoir

comment:8 Changed 4 years ago by DonMoir

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

Last edited 4 years ago by DonMoir (previous) (diff)

comment:9 Changed 4 years ago by michael

  • Summary changed from avi file can't be seeked to support seeking by decoding from the begin
  • Type changed from defect to enhancement

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

comment:10 Changed 3 years ago by richardpl

  • Priority changed from normal to wish
Note: See TracTickets for help on using tickets.