- From: Andreas Tai <tai@irt.de>
- Date: Fri, 17 Oct 2014 16:23:31 +0200
- To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- CC: public-tt@w3.org
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] >>> 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] >>> 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> 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> wrote: >>>> On Oct 16, 2014, at 10:22 , Michael Dolan <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] >>>>> 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> 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] >>>>> 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> >>>>> Date: Thursday, 16 October 2014 16:29 >>>>> To: 'Timed Text Working Group' <public-tt@w3.org> >>>>> Subject: proposed updated response to MPEG on codecs >>>>> Resent-From: <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 >>>>> 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 | 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 Friday, 17 October 2014 14:24:57 UTC