- From: Andreas Tai <tai@irt.de>
- Date: Sat, 18 Oct 2014 16:54:04 +0200
- To: Glenn Adams <glenn@skynav.com>
- CC: Cyril Concolato <cyril.concolato@telecom-paristech.fr>, TTWG <public-tt@w3.org>
- Message-ID: <54427F0C.8070504@irt.de>
Am 18.10.2014 um 16:37 schrieb Glenn Adams: > > On Sat, Oct 18, 2014 at 4:56 AM, Andreas Tai <tai@irt.de > <mailto:tai@irt.de>> wrote: > > 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? > > > Correct, it would not be a "TTML profile" in the formal sense of how > TTML uses the term profile. However, in a general sense it might be > considered an "informal profile of TTML". In any case, it would > certainly confuse users and authors, and to some extent, would subvert > the intended use of TTML. > > Thanks, Glenn! I think it is important that the proposed mechanism can be used by a wide range of subtitle format specifications that are based on TTML and have a potential use case to be transmitted in MP4. The mechanism should not be exclusive to specifications that make explicit use of TTML profiles. A solution for the discussed scenario should make this very clear. Best regards, Andreas > 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 <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 14:55:43 UTC