MP4Demuxer probe fix for large "emsg" payloads #5852
Merged
Conversation
This file contains 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
…ct fmp4 (Required for segments with large or many emsg boxes)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR will...
Remove 16kB constraint on "moof" offset when probing segments to detect fmp4.
Why is this Pull Request needed?
Segments with large or many emsg boxes can push the moof box offset to much further out in the segment. This is not uncommon for media carrying image data over id3 emsg.
Are there any points in the code the reviewer needs to double check?
Added a new method optimized to exit on the first moof box found and skip quickly over others. When testing how this worked with TS and unwrapped audio the method tended to exit after first iteration because
sizewas out of bounds (which is good).Resolves issues:
Checklist