Re: MPEG codecs parameter - discussion summary ISSUE-305

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]

   1.

   if the document interchange context
   <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-document-interchange-context>
is
   associated with a processor profile
   <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-processor-profile>
or
   with a content profile
   <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-content-profile>
from
   which a processor profile
   <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-processor-profile>
can
   be inferred, then the default processor profile
   <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-default-processor-profile>
is
   that processor profile
   <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-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
>
>
>