Re: MPEG codecs parameter - discussion summary ISSUE-305

On Fri, Oct 10, 2014 at 11:22 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> 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)
>  b) propose a format for the codecs parameter
>  c) draft a response to MPEG
>
> 3. The TTML2 processorProfiles and profile designator format will remain
> as defined now in the editor's 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.
>
> 5. The syntax for expressing processor profile combinations using short
> names is as described at [1].
>
> 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]".
>
> 7. The MP4 codecs parameter will include the MIME type including the
> extension. (this is MPEG's decision to make not ours)
>
> 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?
>
> 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.
>

I prefer naming this parameter as 'codecs', which I believe was the
original proposal. The name 'profile' is already used in the current MIME
type registration (and means a single relative or absolute URI as used with
the ttp:profile attribugte). The name 'profiles' would be confused with
'profile' and also poorly distinguish the processor vs content profile
distinction. The name 'procprofs' is cryptic and abbreviations are
undesirable. On the other hand, 'codecs' clearly connotes a processor
capability and doesn't entail the confusion factor that other proposals
elicit.


>
> 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
>
>
>
>
>