-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seeking failures when a B frame depends on a future I frame #403
Comments
Here's a simpler test case, H.264 this time. There are five frames, IBIBI in presentation order. If you request frame 4 (0-based) and then frame 2, you get frame 4 twice.
|
Reproduced. It is however caused by FFmpeg marking all I-frames as IDR-frames on stream copy. Most files in the world could be secretly broken. Have a nice evening. |
Given that:
I think this issue should be left open. That way it's easier to find if someone else runs into the problem, and maybe someone will even submit a patch for it, even if you never work on it. If it must be closed, at least close it as wontfix instead of completed. |
AFAIK, there is no reasonable way to support / work around this, since, for example, the Or well, there is no way to work around it unless FFmpeg decides to expose more than I, P, and B as frame types in its API, since this is the root cause of both the remuxing issue, and an inability to work around the bad remuxes. The reason broken.h264 and the mkv is busted is the same (they rely on the parser). There might be an open bug on FFmpeg Trac (as this is an FFmpeg iissue), but I didn't find one. |
I did encounter this bug when googling yesterday: https://trac.ffmpeg.org/ticket/8820 |
I looked at this a bit and I'm not sure that marking I-frames as key frames is the problem. According to this answer, FFmpeg only marks IDR-frames and recovery-point I-frames as key frames. The I-frames in With Elephant's Dream, the problem is that FFmpeg returns the packets in decoding order with no information about the correct presentation order. So Muxing to mp4 or mkv using FFmpeg doesn't solve the problem because FFmpeg writes the same bogus PTSs to the muxed file, and then trusts them when reading it later, so you end up with the same index. This is definitely a bug in FFmpeg unless I'm missing something. Muxing to mkv using MKVToolNix does solve the problem. It generates its own seemingly correct timestamps, the FFMS2 index is correct, and I wasn't able to reproduce this issue. Remuxing it with FFmpeg produces another working file, so the problem is just the initial generation of the timestamps. The file generated by MKVToolNix has cue points for all three I-frames (even though only the first is IDR), and all three I frames are marked as key frames in FFMS2's index, but it works anyway.
With |
Internally seeking is (nowadays) simply done with There's a huge number of bugs related to seeking and timestamps in FFmpeg, that's why I kinda gave up and wrote https://github.com/vapoursynth/bestsource instead which just linearly decodes everything. Snappy results on most things up to 30 min long on modern hardware. |
This video (extracted from the beginning of https://www.libde265.org/hevc-bitstreams/elephants-dream-1080-cfg02.mkv) illustrates the problem, but I think it affects any video that has the property in the title.
If you request frames starting from 0, the video decodes correctly, but if you start from 41 (which is identified as a key frame), all frames from 41 to 48 are copies of frame 48, after which it starts to decode correctly.
Frame 41 in coded order is an I frame, but it's frame 48 in presentation order, and is followed in coded order by B frames that are 44, 42, 41, 43, 46, ... in presentation order.
The above is what happens in a build from the current head (ff61bca) against ffmpeg 5.0.1. The official 2.40 binaries behave a bit differently: 41 to 44 are copies of 48, then 45 gives you 49, and all later frames are off by 4. If you start from 0 you get the correct frames.
The text was updated successfully, but these errors were encountered: