RE: MPEG codecs parameter - discussion summary ISSUE-305

I like “codecs”

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Friday, October 10, 2014 5:11 PM
To: Nigel Megitt
Cc: Timed Text Working Group
Subject: 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