RE: MPEG codecs parameter - discussion summary ISSUE-305

Thanks, Nigel.

Some clarifications:

Regarding item 6, it is not an "extension".  It is a media type parameter.  Today, a fully qualified media type string for TTML is, for example:

 "application/ttml-xml;charset=utf-8;profile= http://www.w3.org/ns/ttml/profile/dfxp-full"

We're discussing adding/replacing a parameter to support the short name profile syntax proposed in TTML2 (e.g. Q2 below).

And, in #7, the media type above is TTWG's decision not MPEG's.  The full codecs parameter (which will use the media type string) is MPEG's domain.

#9 and Q1 was a input from MPEG without being very prescriptive, except that sets of namespace or profile strings is "too long" and sets of short registry names is "probably short enough". 

 Mike

-----Original Message-----
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
Sent: Friday, October 10, 2014 10:22 AM
To: 'Timed Text Working Group'
Subject: MPEG codecs parameter - discussion summary ISSUE-305

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.

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

Received on Friday, 10 October 2014 17:40:23 UTC