W3C home > Mailing lists > Public > public-tt@w3.org > May 2014

RE: Draft TTML Codecs Registry

From: Michael Dolan <mdolan@newtbt.com>
Date: Thu, 15 May 2014 06:57:50 -0700
To: "'TTWG'" <public-tt@w3.org>
Message-ID: <041501cf7045$aaac59f0$00050dd0$@newtbt.com>
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.


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


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:43:35 UTC