Re: MPEG codecs parameter - discussion summary ISSUE-305

Le 10/10/2014 19:22, Nigel Megitt a écrit :
> All,
>
> There has been some off-list discussion about our profiles registry and
> the MPEG codecs parameter (Issue-305 etc). Below is a summary of where
> we're up to - the purpose of sending this to the group is to give the
> opportunity for all members to raise any concerns or proposals.
>
> SUMMARY
> -------
>
> 1. To be useful, MPEG needs our response by October 19.
>
> 2. The steps we need to take are:
>   a) agree that we will host a registry (done in principle I think, but it
> would help to formalise it with a resolution)
I agree
>   b) propose a format for the codecs parameter
To be precise, it's "propose a format for a TTML MIME type sub-parameter 
that indicates the capabilities required for processing this document". 
It will be used in the "codecs" sub-parameter of MPEG's video/mp4 MIME 
type when TTML is stored as a track in MP4 files (tbd by MPEG). And 
there seems to be some agreement in the TTWG that the TTML MIME Type 
sub-parameter be also called: "codecs".

>   c) draft a response to MPEG
>
> 3. The TTML2 processorProfiles and profile designator format will remain
> as defined now in the editor's draft.
I'm personally unclear about  those 2 attributes and their relationship 
with the new MIME sub-parameter.  In particular, I think there should be 
some rules about which value those attributes shall take when the 
document is announced with a new MIME sub-parameter's value of X. In 
particular, I'm uneasy with the "first order" concept of the current 
registry draft.

> 4. We're willing to host a registry of short names for both the standard
> designators listed in TTML1 and TTML2 and non-standard external
> designators, similar to if not identical to that at [1] - the precise
> contents of this registry can be discussed further, for example in the
> agenda slot we have set aside at TPAC. This will be external to the TTML2
> recommendation.
Yes.
>
> 5. The syntax for expressing processor profile combinations using short
> names is as described at [1].
Agree.
>
> 6. The mechanism for signalling what kind of TTML processor a given
> document needs will be included as an extension to the MIME type, i.e.
> "application/ttml+xml;[EXTENSION GOES HERE]".
Ok
>
> 7. The MP4 codecs parameter will include the MIME type including the
> extension. (this is MPEG's decision to make not ours)
Ok and in that sense, the following sentence from the registry needs to 
be deleted.
"When an entry of this registry is used in a|codecs|parameter, it (or 
the combination expression in which it appears) shall be preceded by the 
prefix|stpp.ttml.|."

>
> 8. We do not intend to create a new MIME type for TTML2 but may revise the
> existing MIME type for TTML.
>
> 9. There is a maximum string length constraint for the MIME type - what is
> that maximum though?
Agree with Dave, we probably don't need to care now that the registry is 
in place.
>
> 10. The remaining area of debate is whether to redefine the profile
> parameter in the MIME type (current registration is at [2]) or to create
> something new, for example "procprofs". If there are no implementations
> that use the current profiles addition to the MIME type then it seems most
> useful to redefine it to use the short names. Conversely if there's a need
> to maintain some form of backwards compatibility for existing
> implementations, then we should define a new parameter for processor
> profiles and deprecate the existing profiles while defining rules for
> systems that are interpreting the type so that they take the most
> appropriate action.
What is the purpose of the current "profile" parameter? Is it declaring 
content profile ?

Cyril
>
> 11. When we have concluded on the redefine profile vs define a new thing
> point (10 above) we can draft our response to MPEG, and resolve to send it
> in our meeting of Thursday 16th October. (I've assumed that we will also
> resolve to host the registry page during that meeting)
>
> OUTSTANDING QUESTIONS
> ---------------------
>
> Q1. What is the length limit we need to adhere to for the MIME type, and
> where does the requirement come from?
>
> Q2. Should we redefine profile or define a new additional parameter?
>
> REFERENCES
> ----------
>
> [1] Codecs registry draft page: https://www.w3.org/wiki/TTML/CodecsRegistry
> [2] Current TTML IANA registration:
> http://www.iana.org/assignments/media-types/application/ttml+xml
>
>
>
>


-- 
Cyril Concolato
Multimedia Group / Telecom ParisTech
http://concolato.wp.mines-telecom.fr/
@cconcolato

Received on Monday, 13 October 2014 09:27:50 UTC