Opened 8 years ago
Last modified 2 days ago
#5309 open enhancement
Apply "-accurate_seek" alike default for `ffplay`
Reported by: | Arnaud | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | ffplay |
Version: | git-master | Keywords: | seek seeking |
Cc: | MasterQuestionable | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
How to reproduce:
% ffplay -ss 5 ffmpeg version: ffplay version N-78958-g8c24523 built from latest git, on Ubuntu 14.04.3, on 2016-03-07
File is seek_not_working.mp4
The file plays well but always from the beginning: the seek isn't working.
Change History (20)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Problematic file uploaded on the ftp server upload.ffmpeg.org
I would like to help finding what is the issue and maybe fix it if I can, but I'm not expert with ffmpeg source code, so if someone more experienced has an idea about what is wrong :)
comment:4 by , 8 years ago
I didn't know ffmpeg has a seek option.
I tried it the following way:
./ffmpeg -ss 3 -i seek_not_working.mp4 -frames:v 1 out1.jpg
and yes, it works.
comment:6 by , 8 years ago
Sorry, I'm not sure I understand what you meant.
You're asking if I have the same problem with other mp4 files?
comment:7 by , 8 years ago
No, you promised me in September to search for such a sample. Did you find one?
comment:8 by , 8 years ago
Ah, ok.
No sorry: I probably lost it when my hard drive crashed some time ago :(
follow-up: 12 comment:11 by , 8 years ago
Thanks for your reply.
How can I check if the file has only on recovery point and if that can be the issue?
I tried to figure this out by adding a breakpoints in h264.c:decode_recovery_point but never get there, using my "buggy" file, but also some other files (e.g. [1] from [2]) for which seeking works.
[1]: http://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_50mb.mp4
[2]: http://www.sample-videos.com/
comment:12 by , 8 years ago
Replying to Arnaud:
[1]: http://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_50mb.mp4
This file contains many IDR frames.
I don't know the exact semantic definition of recovery points but all IDR frames can be used for seeking.
comment:13 by , 8 years ago
Oh, OK.
Indeed that seems to be the problem in my initial file: only one IDR frame.
Then I guess this bug can be closed, because there isn't much to fix on ffmpeg library or on ffplay about it, don't you think?
If I'm right VLC uses ffmpeg, and I noticed it is able to seek this file, but it seems like it reads all the frames from the IDR frame to achieve this.
So I guess it's up to applications to implement such behavior on top of ffmpeg's seek if not enough IDR frames are present.
Thanks a lot for your help :)
comment:14 by , 8 years ago
No IDR- (and no I-) frames are necessary to seek a valid H.264 stream, recovery points are sufficient. A stream analyzer is needed to find out if your stream does contain more than one recovery point.
comment:15 by , 3 months ago
It actually has 1 keyframe only, as second I frame is not a keyframe, it is not IDR (as nowadays avc includes I frames that are not keyframes, but not with ffprobe show_frames, you need -skip_frame nokey, see bug #8820).
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5309/seek_not_working.mp4
Are we planning to implement decoding seek like said in #3083?
comment:16 by , 3 months ago
͏ Codec container wrestling each other...
͏ https://www.google.com/search?hl=en&gl=ca&num=10&q=AVC|H.264|H264|x264+recovery-point
͏ https://stackoverflow.com/questions/75635925
͏ https://mpeg.chiariglione.org/tags/sei-messages
͏ .
͏ And the Open GOP (Group of Pictures) non-sense:
͏ That would be essentially identical as well-set ordinary (Closed) GOP.
͏ Ideally each GOP shall be an independent file:
͏ As in: https://github.com/MasterInQuestion/talk/discussions/3#discussioncomment-9376594
͏ And videos are not necessarily not meant to be viewed frame-by-frame. (thus any artifact unacceptable)
comment:17 by , 3 months ago
Nope.
B frame in one GOP is able to reference a frame in a different GOP. A GOP that contains any such outward-referencing frame is known as an "open GOP".
What is worse: B frames can be references. Even each B frame can be reference frame.
comment:18 by , 3 months ago
Component: | undetermined → ffplay |
---|---|
Status: | new → open |
Summary: | Seek doesn't work in some .mp4 files → Seek doesn't work in some .mp4 files in ffplay |
So the bug is only in ffplay. Actually.
comment:19 by , 3 months ago
Cc: | added |
---|
͏ Essentially such referencing could be still represented with Closed GOP...
͏ Note the final referencing is certain: not changing randomly.
͏ Probably the Open GOP design is to support certain really unusual fringe cases:
͏ Where 1 GOP would like to reference part (not all) of other GOP.
͏ And using the big GOP containing all is somehow unacceptable.
͏ However there doesn't seem to be much valid cases for such usage.
͏ Plus the apparent havoc of general interop.
͏ See also: https://trac.ffmpeg.org/ticket/11055#comment:16
͏ ----
͏ Up: https://forum.videohelp.com/threads/396068-Determining-GOP-structure-open-or-closed#post2574433
͏ No wonder why lossless H.265 may give output bigger than H.264...
͏ https://www.hevcbook.de/hevc-picture-types/
͏ .
͏ Who may explain such sophistry?
͏ Low Efficiency Video Coding: https://trac.ffmpeg.org/ticket/11155#comment:2
͏ ----
͏ Current OGOP designs are essentially no different than 2x (or 3x) size ordinary (Closed) GOP:
͏ Only pointlessly more complex and troublesome.
comment:20 by , 3 months ago
Keywords: | seeking added; h264 mov removed |
---|---|
Summary: | Seek doesn't work in some .mp4 files in ffplay → Apply "-accurate_seek" alike default for `ffplay` |
Type: | defect → enhancement |
͏ Per <Seeking> # Input seeking.
(will upload sample file)