RE: Draft TTML Codecs Registry

Maybe "highly undesirable", but if we don't address the A + B signaling
explicitly, then profiles need to be created for all the combinitorics of
namespaces in practice. Not the end of the world, but virtually prevents the
simple signaling of 3rd party namespaces already provided by the
namespace/schemaLocation mechanism today. No I am not proposing we use that
- I am pointing out a deficiency in this proposal that we already address
today in 14496.

Anyway, we need to go through the points in my email a week ago - if not
today, then on the 29th.

	Mike

-----Original Message-----
From: David Singer [mailto:singer@mac.com] 
Sent: Thursday, May 15, 2014 5:20 AM
To: Glenn Adams
Cc: TTWG
Subject: Re: Draft TTML Codecs Registry

OK

Though it will be a sub-parameter of the codecs parameter for the MP4 file
type, from the point of view of TTML it's actually a profile short name
registry rather than codecs registry, so I think we should rename it.

the values here should be usable in both
a) the profiles parameter for the TTML mime type
b) the codecs parameter for the MP4 mime type

so, also "named codecs" -> "named profiles"



I agree with Cyril that we only need a single operator here (implement one
of these profiles and you're good to go), both because we don't need the
complexity, and because a "implement both/all of these" is effectively
inviting file authors to make up new profiles ("to process this document you
have to implement both A and B"), which is (IMHO) highly undesirable.



On May 15, 2014, at 9:55 , Glenn Adams <glenn@skynav.com> wrote:

> See [1].
> 
> [1] https://www.w3.org/wiki/TTML/CodecsRegistry

Dave Singer

singer@mac.com

Received on Thursday, 15 May 2014 13:58:27 UTC