-
Notifications
You must be signed in to change notification settings - Fork 73
Fallback to container duration in approximate mode #989
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
Merged
mollyxu
merged 8 commits into
meta-pytorch:main
from
mollyxu:fallback-container-duration
Nov 19, 2025
Merged
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
389c078
fallback to container duration in approximate mode when stream durati…
0539566
Merge branch 'main' into fallback-container-duration
mollyxu 51b0a74
Merge branch 'meta-pytorch:main' into fallback-container-duration
mollyxu 95eedb1
Merge branch 'meta-pytorch:main' into fallback-container-duration
mollyxu 27718be
update pr to reflect refactor
2979900
Merge branch 'meta-pytorch:main' into fallback-container-duration
mollyxu ec12f87
Merge branch 'meta-pytorch:main' into fallback-container-duration
mollyxu 68e48db
address feedback
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Rather than assigning the container's duration to the stream's duration, I think we should do something like:
I think that keeps it clear where we're getting our information from. So far, we've kept that explicit in our existing metadata fields.
One wrinkle here is that the metadata we report to users in Python is
VideoStreamMetadata. That is, it's explicitly the stream metadata. We don't have a hierarchically clean way to add the container metadata there. So while it's kinda odd, maybe we should add a field forduration_seconds_from_containeron the Python side.To be clear, my current thinking is that:
durationSecondsFromContainerfield toStreamMetadata.duration_seconds_from_containertoStreamMetadata, and we have logic to fall back to it induration_seconds.@NicolasHug, @Dan-Flores, I'm curious to hear your thoughts as well.
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.
@scotts can you help me understand where you think we should add this?
I agree with your general point that we should avoid setting the stream metadata to the container metadata.
We might be able to avoid defining a new
*_from_containerattribute on theStreamMetadata: theContainerMetadatametaclass exists in Python. We just don't expose it currently.The original error happens here:
torchcodec/src/torchcodec/decoders/_video_decoder.py
Lines 413 to 418 in 75a3325
and this is a place where we do know the
ContainerMetadata. Maybe we can just fallback to it in that function only (I haven't checked that this would solve the original issue). And, whether we want to exposeContainerMetadatais kind of a separate issue.As a side note, reasoning about all these fallbacks hurts my brain. We have fallbacks in the Python
StreamMetadataclass, in the C++initializeDecoder(), and in the C++ helpers likegetNumFrames. It might be time we address our long-time issue of centralizing all of the fallback logic in C++ (#125 (comment))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.
@scotts @NicolasHug Thank you for the feedback!
I tried implementing fallback at line 413-418 in
_video_decoder.pybut I think thatnum_frameswould be none. This is due tometadata.num_framesnot having the container duration when it computesnum_framesusingduration_seconds_from_headerwhennum_framesis missing from the video.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.
@NicolasHug,
Right now, there's only one place we really use the duration's value in C++:
getMaxSeconds(). That would become:Agreed that now may be the time to consolidate all of this fall back logic in C++. The fallback logic in Python is not straight-forward to understand because it's close to being a state machine. We're trying to be as tolerant of missing values as possible, which means that value
amay try to fallback to valuebin some instances, but valuebmay also try to fallback to valueain other instances. Implementing this logic in one place, for all uses, will at least make sure that we're consistent across Python and C++.Part of why this logic is convoluted in Python is that the Python metadata class has no knowledge of seek modes. Instead, it has fallback logic exclusively based on what values are present.