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

Init segment reference to ISO BMFF byte stream format constraints is ambiguous and probably wrong #28

Open
poolec opened this issue Aug 14, 2020 · 2 comments
Labels
last-chance-for-comment Last call for comments, if no comments, will be implemented or closed

Comments

@poolec
Copy link

poolec commented Aug 14, 2020

In section 3, bullet 1b references "constraints" in the original ISO BMFF byte stream format but it's not clear exactly what text is intended to be referenced here. Most of clause 3 in the ISO BMFF byte stream spec is duplicated in the CMAF one anyway and the parts that aren't are not really "constraints" but conditions under which the append error algorithm must be run. If the intention was to reference those, then I would propose alternative wording for bullet 1b: "Any condition under which the append error algorithm is required to be run according to clause 3 of the ISO BMFF byte stream format specification [ref]".

However, looking at those conditions, it seems to me as if the first one is actually wrong. The first bullet in clause 3 of the ISO BMFF byte stream format spec reads "A File Type Box contains a major_brand or compatible_brand that the user agent does not support." This wording would require the user agent to reject the init segment just for having an unrecognised compatible_brand (even if it also had one or more supported brands). Surely it should read something like: "A File Type Box does not contain any major_brand or compatible_brand that the user agent supports"?

For clarity, I think it would be much more straightforward to delete the reference to clause 3 of the ISO BMFF byte stream format spec and copy any constraints or error conditions that are relevant into the CMAF byte stream format spec since most of the rest of section is copied. That would also allow the above condition to be corrected.

@technogeek00
Copy link

@poolec I believe your read is correct, the intention is to pull in the conditions of append error algorithm from ISO BMFF and apply to CMAF, but you are also correct that the constraints seem a little off. I'd support dropping the reference and shuttling over the constraints we want to persist.

@haudiobe haudiobe added the Public-Review Comment Provided during Public Review label Oct 5, 2020
@haudiobe
Copy link
Member

2020/11/19: Agree in principle. We should add a note similar to the one in clause 4.

@haudiobe haudiobe added agreed-needs-implementation Resolved and needs implementation last-chance-for-comment Last call for comments, if no comments, will be implemented or closed and removed agreed-needs-implementation Resolved and needs implementation labels Nov 19, 2020
@haudiobe haudiobe removed the Public-Review Comment Provided during Public Review label Dec 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
last-chance-for-comment Last call for comments, if no comments, will be implemented or closed
Projects
None yet
Development

No branches or pull requests

3 participants