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

Re: proposed updated response to MPEG on codecs

From: Andreas Tai <tai@irt.de>
Date: Sun, 19 Oct 2014 16:02:48 +0200
Message-ID: <5443C488.8040807@irt.de>
To: Glenn Adams <glenn@skynav.com>, public-tt <public-tt@w3.org>, cyril.concolato@telecom-paristech.fr
Thanks, Glenn! See comments inline:

Am 18.10.2014 um 17:11 schrieb Glenn Adams:
>
> At present, the rules for registration cited at [1] include:
>
>  1. ...
>  2. Each entry must include an absolute URI that serves as the TTML
>     Profile Designator that identifies the processor profile.
>  3. Each entry should include a link that references a TTML Profile
>     Definition Document that formally specifies the processor profile
>     using TTML profile definition vocabulary.
>  4. ...
>
>
> Requirement (2) mandates the use of a "TTML Profile Designator".

This is exactly the part I am concerned about. If a specification is not 
a TTML profile (in the way that is defined by TTML 2) how can there be a 
TTML profile designator?

> Your inquiry thus raises the question of whether it is possible to 
> have a "TTML Profile Designator" for which there is no associated 
> "TTML Profile Definition Document".

Yes, that makes indeed no sense. My use case is where there is no TTML 
profile.

> Note that while the former (2) is mandated, the latter (3) is merely 
> recommended.
>
> Further, our recent consensus resolution was to have the 
> 'processorProfiles' MIME type parameter be semantically equivalent to 
> the TTML2 'ttp:processorProfiles' parameter attribute, with the only 
> difference being that the former uses a simpler syntax (short names 
> and simple combiner operators).
>
Not sure about the timeline to come to an applicable solutions but I had 
the impression there is some need for a solution before TTML 2 gets 
final recommendation status.

> Given these requirements, I'm not sure how to deal with an informal 
> profile that doesn't have an associated TTML Profile Definition Document.
I can understand that. The term "informal profile" is pretty vague.

> It would seem much simpler to define such a document and associate it 
> with this informal profile.
>
> [1] 
> https://www.w3.org/wiki/TTML/CodecsRegistry#Registration_Entry_Requirements_and_Update_Process

But my conclusion would be different. It is more to allow the signalling 
of specs that do not use the TTML profiling mechanism.

Best regards,

Andreas

>
>     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  <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 Sunday, 19 October 2014 14:03:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:18 UTC