Skip to content

Avoid seeking checks when decoding frames sequentially #1028

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+10 −3
Open

Avoid seeking checks when decoding frames sequentially #1028

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions src/torchcodec/_core/SingleStreamDecoder.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -618,9 +618,15 @@ FrameOutput SingleStreamDecoder::getFrameAtIndexInternal(
}
validateFrameIndex(streamMetadata, frameIndex);

int64_t pts = getPts(frameIndex);
setCursorPtsInSeconds(ptsToSeconds(pts, streamInfo.timeBase));
return getNextFrameInternal(preAllocatedOutputTensor);
// Only set cursor if we're not decoding sequentially
if (frameIndex != lastDecodedFrameIndex_ + 1) {
int64_t pts = getPts(frameIndex);
setCursorPtsInSeconds(ptsToSeconds(pts, streamInfo.timeBase));
}

auto result = getNextFrameInternal(preAllocatedOutputTensor);
lastDecodedFrameIndex_ = frameIndex;
return result;
Copy link
Contributor Author

@NicolasHug NicolasHug Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO for myself: explain why that's crucially important.

Copy link
Contributor

@scotts scotts Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised that changing this logic avoids calling canWeAvoidSeeking() because this logic doesn't actually call that function. Does not updating the cursor change the conditions for which we call canWeAvoidSeeking()? Is it maybe clearer to directly update those conditions? These calls don't seem that expensive (although of course they'll cost something). I'm a little worried that we have some assumption elsewhere that we're always updating the cursor, and now we're not.

Copy link
Contributor Author

@NicolasHug NicolasHug Nov 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is very indirect and yes, based on assumptions.

canWeAvoidSeeking() is only called if the cursor was set:

torchcodec/src/torchcodec/_core/SingleStreamDecoder.cpp

Lines 1174 to 1177 in 7d27c15

if (cursorWasJustSet_) {
maybeSeekToBeforeDesiredPts();
cursorWasJustSet_ = false;
}

and the cursor is only set if we call setCursorPtsInSeconds.

I'm happy to revisit the core logic of how we handle this. TBH, I'm a little bit into a speed-running mode at the moment.

Half of the reason I'm submitting the PR as-is is to check the CI and make this issue visible as early as possible.

}

FrameBatchOutput SingleStreamDecoder::getFramesAtIndices(
Expand Down
1 change: 1 addition & 0 deletions src/torchcodec/_core/SingleStreamDecoder.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -345,6 +345,7 @@ class SingleStreamDecoder {
bool cursorWasJustSet_ = false;
int64_t lastDecodedAvFramePts_ = 0;
int64_t lastDecodedAvFrameDuration_ = 0;
int64_t lastDecodedFrameIndex_ = INT64_MIN;

// Stores various internal decoding stats.
DecodeStats decodeStats_;
Expand Down
Loading