-
Notifications
You must be signed in to change notification settings - Fork 12
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
MIME parameters ("codecs") for bucket ISO BMFF-wrapped TTML versus "application/ttml+xml" #76
Comments
The Timed Text Working Group just discussed
The full IRC log of that discussion<nigel> Topic: MIME parameters ("codecs") for bucket ISO BMFF-wrapped TTML versus "application/ttml+xml" #76<nigel> github: https://github.com//issues/76 <nigel> Mike: If we all look at my comment on #71 from two days ago: <nigel> -> https://github.com//issues/71#issuecomment-680222378 Mike's comment <nigel> Mike: We covered most of this, but I want to cover the character set constraint based on <nigel> .. RFC6381 "element" which makes the syntax precise. <nigel> .. The codecs parameter here is a subset of RFC6381. <nigel> .. I'm noting that it is nothing to do with RFC6381 and the citation is only for the syntax <nigel> .. This clarifies that ISOBMFF is about application/mp4 and that we also point to 14496-30 <nigel> .. which we agreed to do a moment ago. <nigel> .. I think an example would be helpful, so I produced an example. <nigel> Nigel: Isn't there an example already? <nigel> Mike: Just an abstract one. <nigel> Nigel: Oh I see, a real world one would be better. <nigel> Mike: If this is okay then I'll make a specific language proposal. <nigel> Nigel: Sounds good to me. <nigel> Mike: Let me know if we're there. <nigel> Cyril: I think we're in agreement here. <nigel> SUMMARY: @mikedo to make a language proposal. |
(Cross posting from #71) This profiles document states:
The syntax defined in this profile document, does not directly have anything to do with RFC 6381, except that the charset is constrained to that of "element", which among other things forbids ".".. The codecs parameter defined here is for media type, "application/ttml+xml". So, the use of RFC 6381 is a little misleading. The codecs parameter of media types used in ISO BMFF (specifically media type application/mp4) was created by RFC 6381 and extended by other media specifications such as 14496-30. The latter, following RFC 6381, states that the codecs parameter for a TTML document carried in ISOI BMFF has the syntax "stpp.ttml" appended with an optional profile syntax citing this W3C document (including the combinatorics operators). For example, the codecs parameter for an application/mp4 file that contains a TTML document that conforms to both IMSC1.0.1 text profile and EBU-TT-D-1 is "stpp.ttml.im1t|etd1". It would be helpful to have some of the language above in this profiles document to clarify that this codecs parameter is not the same as the RFC 6381 codecs parameter. |
Proposal: Append to the end of Section 3: The codecs parameter here is for the media type, "application/ttml+xml". IETF RFC 6381 is cited in TTML1 to constrain the charset for this codecs parameter string. There are no additional constraints or extensions related to RFC 6381 here. However, note that there is also a codecs parameter for "application/mp4". The general syntax for this codecs parameter is defined in IETF RFC 6381 and further, specifically for TTML, is defined in ISO/IEC 14496-30. This media type parameter, codecs, used in ISO BMFF, and also propagates to manifests such as DASH MPD (@codecs) and HLS (tbd). For example, a TTML document that conforms to both IMSC1.0.1 text profile and EBU-TT-D-1 codecs string is "stpp.ttml.im1t|etd1". See ISO/IEC 14496-30 for more information. |
The following is ambiguous as it gives an ISOBMFF codecs value for a TTML document:
I suggest replacing it with:
|
Sure (but it was in a paragraph only about the codecs parameter for "application/mp4"). |
The Timed Text Working Group just discussed
The full IRC log of that discussion<nigel> Topic: MIME parameters ("codecs") for bucket ISO BMFF-wrapped TTML versus "application/ttml+xml" #76<nigel> github: https://github.com//issues/76 <nigel> Nigel: Looks like there's proposed wording and an amendment that Mike is happy with. <nigel> Mike: I'll open a pull request. <nigel> Nigel: I'm a little confused about what grants the ISOBMFF codecs value the right to use <nigel> .. our codecs parameter value as the third component. <nigel> Cyril: It's in the RFC, which points to 14496-12 and 14496-30 says the first term (sample entry) <nigel> .. is stpp, the second is "ttml" and the third points to the profiles registry. <nigel> Nigel: That's clear, thank you. And it says specifically the "codecs" value? <nigel> Mike: Yes. The practical purpose is to signal indirectly via the parts in the MP4 file, which <nigel> .. might be extracted into the DASH manifest to identify the media types. <nigel> Nigel: Thank you that really clarifies it in my mind. <nigel> Mike: Yes, it's the same parameter name, perhaps in hindsight we could have picked a different name, but it will work out. <nigel> SUMMARY: @mikedo to raise a pull request |
Both of these are wrong - codecs is about specifying the required profile support in processors, not the contents of documents. It needs further rewording. Over in #78 I just pushed 323193f that uses language that's closer to what I think we need here. |
Indeed. I forgot about that years-long discussion. Thx. |
RFC6381 defines MIME type parameters "codecs" and "profiles" for ISO BMFF-wrapped content. We are defining "codecs" for "application/ttml+xml". We should clarify in the TTML IANA registration text so that DASH @codecs gets set correctly.
The text was updated successfully, but these errors were encountered: