- From: Andreas Tai <tai@irt.de>
- Date: Sat, 18 Oct 2014 12:56:51 +0200
- To: Glenn Adams <glenn@skynav.com>
- CC: Cyril Concolato <cyril.concolato@telecom-paristech.fr>, TTWG <public-tt@w3.org>
- Message-ID: <54424773.9080504@irt.de>
Understood. One question: A specification that builds on TTML and but has not a normative list of TTML features and extensions is not a TTML profile, correct? Best regards, Andreas Am 17.10.2014 um 18:53 schrieb Glenn Adams: > I'm afraid I will have to object to the notion of creating a thing > called a TTML "dialect" that is not describable as a TTML "profile". > We definitely *do not* need an alternative characterization of TTML > processor requirements or content constraints. > > On Fri, Oct 17, 2014 at 8:23 AM, Andreas Tai <tai@irt.de > <mailto:tai@irt.de>> wrote: > > Hi Cyril, > > Thanks for the quick feedback! See some comment inline. > > Am 17.10.2014 um 15:32 schrieb Cyril Concolato: > > Hi Andreas, > > Le 17/10/2014 14:33, Andreas Tai a écrit : > > As I understand the main intent of this communication is > to define the responsibilities of the MPEG and TTWG for > the signalling of "TTML document dialects" in an MP4 > container. There seems an agreement to use the MPEG codecs > parameter where MPEG has the task to define a prefix and > TTWG to define suffix. > > How the W3C/TTWG defines that suffix is not of core > interest for the MPEG group (as long the general syntax > for codecs parameter is followed). I highlight this > because my following comment may not stop this letter > because the "Suffix" definition is not decided yet and in > the responsibility of the TTWG. > > Regarding the proposed solution in the liaison letter (and > in this thread) more discussion seems to be needed. From > my current review it may not be applicable for all "TTML > dialects". Some "dialects", like EBU-TT-D, do not rely on > the defined semantics of TTML profiles. Therefore I do not > think that it is a good idea to make "TTML profiles" as a > central concept for the codecs registry for "TTML dialects". > > The idea would be that EBU-TT-D would be registered and have a > short name to be used as a dialect in the processorProfiles > parameter. > > In general this would meet an important requirement from decoder > implementers. > > EBU-TT-D may not "rely on the defined semantics of TTML > profiles" but it can be viewed as a "dialect" of TTML. Is that > clearer? > > > I think that the general pattern is a adequate solution. The > problem I see is with the definition what is meant by a processor > profile. A processor profile has defined semantics. It reference > the TTML profile mechanism. This mechanism is a formally > well-thought-out concept. But it is not used consistently or not > used by some TTML dialects. As well it has not been fully > understood by some implementers. Therefore it would be good to > have the (additional) possibility to just reference the > specification of the "TTML dialect" without using the profile > semantics. > > Maybe the terms profiles or processorProfiles are misleading, > I don't know. > > In the current registry proposal (and in the TTML2) draft > "processor profile" has defined semantics. I think it was chosen > on purpose (although I do not agree that this is the best solution). > > | Maybe we should talk about dialects to cover not just profiles > of TTML but extensions too. > > I think the use of an alternative term would be a good idea > because "profile" has a link to the semantic concept of TTML > profiles and often this linkage is not intended. > > Best regards, > > Andreas > > > > Cyril > > > Best regards, > > Andreas > > Am 17.10.2014 um 00:16 schrieb Michael Dolan: > > Take 2 on the communication to MPEG - attached. Over > to Dave (really this > time). > > -----Original Message----- > From: Michael Dolan [mailto:mdolan@newtbt.com > <mailto:mdolan@newtbt.com>] > Sent: Thursday, October 16, 2014 1:35 PM > To: 'Timed Text Working Group' > Subject: RE: proposed updated response to MPEG on codecs > > That would be the proper thing to do. > > -----Original Message----- > From: David Singer [mailto:singer@apple.com > <mailto:singer@apple.com>] > Sent: Thursday, October 16, 2014 1:07 PM > To: Glenn Adams > Cc: Michael Dolan; Timed Text Working Group > Subject: Re: proposed updated response to MPEG on codecs > > Seems that way > > On Oct 16, 2014, at 12:57 , Glenn Adams > <glenn@skynav.com <mailto:glenn@skynav.com>> wrote: > > we could always define this new MIME media type > parameter in TTML2, > but > > wouldn't we need to update the current registration? > > On Thu, Oct 16, 2014 at 1:01 PM, David (Standards) > Singer > > <singer@apple.com <mailto:singer@apple.com>> wrote: > > On Oct 16, 2014, at 10:22 , Michael Dolan > <mdolan@newtbt.com <mailto:mdolan@newtbt.com>> wrote: > > I cannot support defining a formal media type > string (including any > of > > its parameters) on an informal wiki. This is highly > irregular. > > agreed. I think that MPEG should say "the mime > type the contents > would > > have if in a separate file goes here, with any > optional parameters" and stop > at that. > > So, MPEG doesn't care how irregular we are, but we > should not be > > irregular, of course. > > I believe its general syntax and semantics > must be normatively > defined > > in TTML2 as part of the media type (and preferably in > my view) then > registered with IANA (not the other way around either). > > yup > > Mike > > From: Nigel Megitt > [mailto:nigel.megitt@bbc.co.uk > <mailto:nigel.megitt@bbc.co.uk>] > Sent: Thursday, October 16, 2014 9:23 AM > To: Michael Dolan > Cc: Timed Text Working Group > Subject: Re: proposed updated response to MPEG > on codecs > > > > > On 16 Oct 2014, at 16:52, Michael Dolan > <mdolan@newtbt.com <mailto:mdolan@newtbt.com>> > wrote: > > Thanks for fixes. I assume Dave will update > before posting. > > As for the your second point, I am not sure > that I follow. We must > > define the new media type parameter formally in TTML2 > or our decisions and > this communication are meaningless. Is your point > that we did not agree as > a group to register the update with IANA? I agree, > but I also did not say > that to MPEG (although I personally think we should). > > > I was expecting the MIME type parameter to be > external to TTML2 and > > defined on the registry page. I'm not against updating > the IANA registration > if that's useful but we haven't decided to do that. If > we do, then clearly > the relevant part of the TTML 2 spec would need > updating to match. If we > don't, then there may be no changes resulting, in TTML2. > > Since there may therefore be no change in TTML > 2 I don't want to > give > > the wrong impression. > > Nigel > > > > Mike > > From: Nigel Megitt > [mailto:nigel.megitt@bbc.co.uk > <mailto:nigel.megitt@bbc.co.uk>] > Sent: Thursday, October 16, 2014 8:39 AM > To: Michael Dolan; 'Timed Text Working Group' > Subject: Re: proposed updated response to MPEG > on codecs > > Thanks for the quick turnaround Mike. 3 things: > > typo: s/medaType/mediaType > correction: s/procProfile/processorProfiles > > Query: do we want the sentence "Its parameters > will be extended in > TTML2 > > to include the proposed syntax above." ? Unless we're > changing the IANA > registration then I do not think we have agreed to do > this. > > Kind regards, > > Nigel > > > From: Michael Dolan <mdolan@newtbt.com > <mailto:mdolan@newtbt.com>> > Date: Thursday, 16 October 2014 16:29 > To: 'Timed Text Working Group' > <public-tt@w3.org <mailto:public-tt@w3.org>> > Subject: proposed updated response to MPEG on > codecs > Resent-From: <public-tt@w3.org > <mailto:public-tt@w3.org>> > Resent-Date: Thursday, 16 October 2014 16:30 > > Per my action item from today, please see the > attached. > > Over to Dave and Nigel for review to see if I > captured where we > ended up > > in today's call; then over to Dave to upload to MPEG > (or I can if needed). > > Time is very short and should be posted Sunday > morning CEDT. > > Regards, > > Mike > > Michael A DOLAN > TBT, Inc. PO Box 190 > Del Mar, CA 92014 > (m) +1-858-882-7497 <tel:%2B1-858-882-7497> > mdolan@newtbt.com <mailto:mdolan@newtbt.com> > > David Singer > Manager, Software Standards, Apple Inc. > > > > David Singer > Manager, Software Standards, Apple Inc. > > > > > > > > > -- > ------------------------------------------------ > Andreas Tai > Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH > R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR > Floriansmuehlstrasse 60, D-80939 Munich, Germany > > Phone: +49 89 32399-389 <tel:%2B49%2089%2032399-389> | Fax: +49 89 > 32399-200 <tel:%2B49%2089%2032399-200> > http: www.irt.de <http://www.irt.de> | Email: tai@irt.de > <mailto:tai@irt.de> > ------------------------------------------------ > > registration court& managing director: > Munich Commercial, RegNo. B 5191 > Dr. Klaus Illgner-Fehns > ------------------------------------------------ > > > > -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de | Email: tai@irt.de ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------
Received on Saturday, 18 October 2014 10:58:51 UTC