Conversation
Section 7.2 of the current ebml spec (rfc 8794) states that uint elements with length 0 are permitted. There was a previous commit ef020c1 about 11 years ago that addressed this issue for several elements. The uint element was among these; functions like ebml_read_uint were changed, but it seems this particular section may have been overlooked. Prior to this change, mkv files with 0-length uint elements were not playable by mpv. These same files were otherwise playable or parsable without issues by other applications like ffplay, vlc, mkvinfo, etc.
not43s
force-pushed
the
allow-zero-length-ebml-uints
branch
from
August 8, 2026 04:33
bdf6272 to
da19749
Compare
Member
|
When size is 0, the value has to be initialized to 0 or default value for this element, if available. Hence this implementation is not complete. |
Author
|
This was only a minimal change to make uint consistent with the behavior of the other numeric types. As far as I can tell, the current implementation in ebml.c is not handling default values for any of the numeric types. |
Member
I think we should make it work, instead of silently producing wrong playback. I've implemented default values here #18367 |
kasper93
added a commit
to kasper93/mpv
that referenced
this pull request
Aug 14, 2026
An EBML element is permitted to have a zero-length data payload. It's then interpreted as the element's RFC declared default value, or zero. Before this change all zero-length elements were initialized to empty or rejected in case of uint. Fixes: mpv-player#18351
Author
|
Very cool. Thanks. |
kasper93
added a commit
that referenced
this pull request
Aug 14, 2026
An EBML element is permitted to have a zero-length data payload. It's then interpreted as the element's RFC declared default value, or zero. Before this change all zero-length elements were initialized to empty or rejected in case of uint. Fixes: #18351
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
2 participants
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.
Section 7.2 of the current ebml spec (rfc 8794) states that uint elements with length 0 are permitted.
There was a previous commit ef020c1 about 11 years ago that addressed this issue for several elements. The uint element was among these; functions like ebml_read_uint were changed, but it seems this particular section may have been overlooked.
Prior to this change, mkv files with 0-length uint elements were not playable by mpv. These same files were otherwise playable or parsable without issues by other applications like ffplay, vlc, mkvinfo, etc.
Thanks.