Repository navigation
obu: refuse a frame size override past the sequence header's maximum - #1513
Open
josefguenther wants to merge 1 commit into
Open
josefguenther wants to merge 1 commit into
josefguenther wants to merge 1 commit into
Conversation
§5.9.5 requires `frame_width_minus_1 <= max_frame_width_minus_1` and the same for the height. `parse_frame_size` read both fields and compared neither, so a frame header could state any shape its bits allow, bounded after that only by `frame_size_limit`'s area. libaom refuses such a frame. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
The AV1 spec (§5.9.5) requires a frame's width and height to stay within the sequence header's maximums. When a frame overrides its size, rav1d reads both and never compares them with those maximums, so a frame header can state any shape up to 2^16 on each axis. Only the frame size limit, an area, bounds it after that. libaom refuses such a frame ("Frame dimensions are larger than the maximum values").
It matters to a caller that budgets memory from the sequence header or the container's extent. Pictures are padded to 128 rows and columns, so a thin frame of an allowed area (65,536 x 1 under a 256 x 256 maximum) allocates a picture about 128 times what the sequence header implies, shown or hidden, and a hidden one stays in the reference slots.
Repro over a constructed stream, in the new tests: a non-reduced sequence header with a maximum of 64 x 64, then a key frame header overriding its size.
This returns the same error as the frame size limit check. A frame that takes its size from a reference needs no check of its own, because the reference was decoded under the same sequence header (a changed sequence header drops the references). The dav1d-test-data suite passes unchanged.
dav1d has the same gap, if you'd rather it went there first.
Written with AI assistance (Claude Code); I have reviewed the change.