Skip to content
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

assume values not found in WebM have their default value #278

Closed
wants to merge 2 commits into from

Conversation

robUx4
Copy link
Contributor

@robUx4 robUx4 commented Oct 11, 2018

WebM doesn't use all our elements but sometimes they are implied even though
they don't define it. For example ContentEncodingOrder.

The elements must not be in WebM files (for compliance) but a parser may need
the actual value (of ContentEncodingOrder) to make any sense. So we assume
elements have their default values if they are not found.

If this is too loose, we may have to list the elements not in WebM but which
default value should be used.

@robUx4 robUx4 added enhancement clarifications webm WebM specific documentation labels Oct 11, 2018
@robUx4 robUx4 requested review from mbunkus and dericed October 11, 2018 09:32
@robUx4 robUx4 force-pushed the webm-defaults branch 2 times, most recently from 38ef7d2 to 28d641d Compare October 11, 2018 09:34
WebM doesn't use all our elements but sometimes they are implied even though
they don't define it. For example ContentEncodingOrder.

The elements must not be in WebM files (for compliance) but a parser may need
the actual value (of ContentEncodingOrder) to make any sense. So we assume
elements have their default values if they are not found.

If this is too loose, we may have to list the elements not in WebM but which
default value should be used.
If not the presence of a (possibly empty) element may signal something, and
that not compatible with what is found in WebM.
@robUx4
Copy link
Contributor Author

robUx4 commented Oct 12, 2018

For the record ContentEncodingOrder is defined for WebM. But the general principle stands. Even for new elements we might add.

@robUx4 robUx4 added the spec_main Main Matroska spec document target label Dec 18, 2018
@dericed dericed self-assigned this Dec 18, 2018
@mkver
Copy link
Contributor

mkver commented Feb 12, 2019

The problem that this issue is about not only exists between closely related EBML Schemas like Matroska and Webm, but also between different version of the same EBML Schema. See EBML-issue #221.

@robUx4
Copy link
Contributor Author

robUx4 commented May 8, 2019

Technically Matroska and WebM are 2 different DocTypes so there's not really direct compatibility at the EBML level. Especially the DocTypeVersion may not match at all (I don't even know what's the current value for WebM), neither minver and maxver. IMO a separate EBML Schema should be done for WebM. And then we can wonder if we actually want to define WebM at the IETF, this is not out responsibility.

So I think we should drop the "webm" attribute of the EBML Schema (which is not a valid attribute anyway) and keep on for WebM, which we may never use.

@mcr mcr closed this Mar 31, 2020
@robUx4 robUx4 deleted the webm-defaults branch July 2, 2023 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarifications enhancement spec_main Main Matroska spec document target webm WebM specific documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants