W3C home > Mailing lists > Public > public-tt@w3.org > October 2014

Re: MPEG codecs parameter - discussion summary ISSUE-305

From: David (Standards) Singer <singer@apple.com>
Date: Mon, 13 Oct 2014 16:31:21 -0700
Cc: Cyril Concolato <cyril.concolato@telecom-paristech.fr>, TTWG <public-tt@w3.org>
Message-id: <09EEA3F8-43BB-4494-AFCA-0CEE6843437D@apple.com>
To: Glenn Adams <glenn@skynav.com>
I wonder whether ‘codecs’ is a good name.  I think we’re talking about processor profiles, yes?

perhaps we should be clear, and call it procprofs, or the like?

application/application/ttml+xml;procprofs=glenn|cyril

?

On Oct 13, 2014, at 9:50 , Glenn Adams <glenn@skynav.com> wrote:

> 
> On Mon, Oct 13, 2014 at 3:27 AM, Cyril Concolato <cyril.concolato@telecom-paristech.fr> wrote:
> 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.
> 
> It has to be first order only because the document itself may:
> 	• may declare use of a different profile
> 	• may refine (semantically extend or restrict) a different profile
> 	• may define (internally in the document) an undesignated profile that may or may not be equivalent to an externally cited 'codec'|'profile'
> In all of these cases, a conforming TTML processor that supports the #profile feature needs to actually parse and make use of the internal profile related declarations.
> 
> The only use a TTML processor may make of the information in a 'codecs' parameter comes from step (1) of [1], specifically in terms of "the document interchange context" being associated with "a processor profile":
> 
> [construct default processor profile]
> 	• if the document interchange context is associated with a processor profile or with a content profile from which a processor profile can be inferred, then the default processor profile is that processor profile;
> 
> [1] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#semantics-procedure-construct-default-processor-profile
>  
> 
> 
> 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 ?
> 
> The TTML1 ttp:profile parameter attribute effectively declared a processor profile which specified a set of features for which support was required in order to process the document.
> 
> Due to a desire to declare a content profile (i.e., a claim about conformance with a named content format or subset), TTML2 introduces ttp:contentProfiles and ttp:processorProfiles parameter attributes, and deprecates ttp:profile, which some find ambiguous regarding whether a processor or content profile is being designated.
> 
> At the same time, TTML2 provides a mechanism for inferring a processor profile from a content profile in the case that only the latter (content profile) is specified. Further, TTML2 formalizes the mechanism for combining multiple profiles to compose a new 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
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.
Received on Monday, 13 October 2014 23:31:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:18 UTC