Ticket #1017 (closed defect: fixed)
MKV keyframe seek performance problems
| Reported by: | rpr | Owned by: | TheFluff |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1.8 |
| Component: | Video | Version: | 2.1.7 |
| Severity: | minor | Keywords: | |
| Cc: | Platform: | Windows | |
| Sub Component: | VProvider - FFMS |
Description (last modified by verm) (diff)
It takes forever to seek to keyframes on MKV video. To test this, grab a h.264 video in MP4 container. Load it ion Aegisub, hold shift and seek. Seeking is very fast as expected.
Now remux the same video to MKV. Load it in Aegisub. The keyframes are still there, but seeking is slow. And by slow I mean orders of magnitude slower - I fear it might be decoding everything from the previous keyframe.
In fact, I'm pretty sure that's what it's doing, because it takes much longer to seek to keyframes which are very distant to the previous one.
I've tested this on two very different machines, and it happens with every file.
I don't think seeking to non-keyframes is affected (difficult to test rigorously).
Change History
comment:2 Changed 2 years ago by TheFluff
- Milestone set to 2.1.8
Forgot: for info on how to install/use the experimental builds see http://www.mod16.org/hurfdurf/?page_id=19
This is known and was caused a bug in FFMS2 that was fixed in 2.11 or maybe 2.12, I don't remember which. It will hence be fixed in 2.1.8 when it is eventually released. Thanks for your report anyway, though!
If you need the fix now you can try the a 2.2 experimental build but be aware that it is, well, experimental and may break things. The 2.1.8 branch builds have not yet had this change backported in, but it's going to be done before it gets released.