Re: proposed updated response to MPEG on codecs

On Sun, Oct 19, 2014 at 8:02 AM, Andreas Tai <tai@irt.de> wrote:

>  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.
>

Since I haven't seen a rationale for avoiding use of the TTML profile
mechanism in a specification defining activity, I am not willing to
concede. Note that one can use the TTML profile mechanism in a defining
activity without necessarily requiring a processor to use it.


>
>
> 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> 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]
>>>>>>> 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 <%2B49%2089%2032399-389> | Fax: +49 89
>>>> 32399-200 <%2B49%2089%2032399-200>
>>>> http: www.irt.de | Email: 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
>>> ------------------------------------------------
>>>
>>>
>>
>>
>> --
>> ------------------------------------------------
>> 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
>> ------------------------------------------------
>>
>>
>
>
> --
> ------------------------------------------------
> 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
> ------------------------------------------------
>
>