- Notifications
You must be signed in to change notification settings - Fork72
RenamegetKeyFrameIndexForPts intogetKeyFrameIdentifier#1076
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| // TODO we should understand why (is it because it reads the file?) and | ||
| // potentially optimize it. E.g. we may not want to ever seek, or even *check* | ||
| // if we need to seek in some cases, like if we're going to decode 80% of the | ||
| // frames anyway. |
NicolasHugNov 28, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Drive-by, my previous comment above is incorrect:getKeyFrameIndexForPts() in approximate mode is not slow. But it's not accurate (it doesn't return what we want it to return), so it's still the cause for the slowness. See#1077 for more details.
| // in [0, num_frames) like for mp4. It really depends on the container. | ||
| // | ||
| // The range of the "identifier" doesn't matter that much, for now we only | ||
| // use it to uniquely identify a key frame in canWeAvoidSeeking(). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I can confirm the above on some test videos with 2 key frames.mkv would return 0 and 1 like in exact mode, whilemp4 returned 0 and 250!
See comment for an explanation why