#296: avi file can't be seeked -----------------------+--------------------------- Reporter: ami_stuff | Owner: Type: defect | Status: open Priority: normal | Component: undetermined Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced: 1 Analyzed: 0 | -----------------------+--------------------------- Changes (by cehoyos): * status: new => open * version: unspecified => git-master * reproduced: 0 => 1 Comment: Isn't this more related to msvideo1 than avi? -- Ticket URL: <https://avcodec.org/trac/ffmpeg/ticket/296#comment:1> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#296: avi file can't be seeked -------------------------------------+------------------------------------- Reporter: ami_stuff | Owner: Type: defect | Status: open Priority: normal | Component: Version: git-master | undetermined Keywords: msvideo1 | Resolution: seek | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (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. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/296#comment:3> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#296: avi file can't be seeked -------------------------------------+------------------------------------- Reporter: ami_stuff | Owner: Type: defect | Status: open Priority: normal | Component: Version: git-master | undetermined Keywords: msvideo1 | Resolution: seek | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (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. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/296#comment:5> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#296: avi file can't be seeked -------------------------------------+------------------------------------- Reporter: ami_stuff | Owner: Type: defect | Status: open Priority: normal | Component: Version: git-master | undetermined Keywords: msvideo1 | Resolution: seek | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by DonMoir): These type of files fail 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 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. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/296#comment:7> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#296: support seeking by decoding from the begin -------------------------------------+------------------------------------- Reporter: ami_stuff | Owner: Type: enhancement | Status: open Priority: normal | Component: Version: git-master | undetermined Keywords: msvideo1 | Resolution: seek | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by michael): * type: defect => enhancement Comment: EVBPIC.AVI does contain only 1 keyframe, seeking thus requires decoding from teh begin -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/296#comment:9> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker