Skip to content

Conversation

@NicolasHug
Copy link
Contributor

See comment for an explanation why

@meta-cla meta-cla bot added the CLA Signed This label is managed by the Meta Open Source bot. label Nov 28, 2025
// 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.
Copy link
Contributor Author

@NicolasHug NicolasHug Nov 28, 2025

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().
Copy link
Contributor Author

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, while mp4 returned 0 and 250!

@NicolasHug NicolasHug merged commit 2311422 into meta-pytorch:main Dec 1, 2025
60 of 64 checks passed
@NicolasHug NicolasHug deleted the aefljnaef branch December 1, 2025 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Meta Open Source bot.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants