Re: Liaison response - template on MIME type parameter for TimedText

On Wed, May 7, 2014 at 1:08 AM, Cyril Concolato <
cyril.concolato@telecom-paristech.fr> wrote:

> Hi Mike,
>
> Le 05/05/2014 15:58, Michael Dolan a écrit :
>
>  Cyril-
>>
>> No one (I don't think) is opposed to addressing the issue.  And, I think
>> W3C
>> has accepted the ownership of its parts of it. The questions are about the
>> technical details.
>>
>> There already is a registered media type - "application/ttml-xml".  So,
>>  one
>> of my questions was essentially why not build on that?  Dave seems to
>> prefer
>> building on the MP4 4C code and I'm still studying the two approaches.
>>
> I'm still seeing discussion on "stpp.XXXX" which is an MPEG business. I'd
> like to see discussions on:
> Content-Type: application/ttml+xml; profiles="EBU-TT-D+ISMC" (or
> equivalent)
>

Agreed, with details of the profiles or other parameters to be worked out.
I also view the MPEG usage as a derived case.


> Once this is done, MPEG can decide to adopt it and say the content of the
> "profiles" parameter is used to build the codecs parameter for that track
> as follows: "stpp.ttml.<profiles>"
> Only Dave indicated that it was a good idea. What do other people think?
>
>
>
>> As you know, the namespaces and schemaLocations are already signaling at
>> the
>> MP4 layer. They can be extracted into a codecs string, but there are
>> apparently objections to the resulting length of the string.  I thought
>> that
>> was the only real issue being addressed, no?
>>
> In some of the MP4 files I've seen, the schema location uses "C:/" so I'm
> not sure this is the right approach ...
>
> Cyril
>
>
>> Regards,
>>
>>         Mike
>>
>> -----Original Message-----
>> From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
>> Sent: Monday, May 05, 2014 4:43 AM
>> To: public-tt@w3.org
>> Subject: Re: Liaison response - template on MIME type parameter for
>> TimedText
>>
>> Hi all,
>>
>> Some points worth highlighting/repeating:
>>
>> - Aside from the MP4 problem, the problem is general. Consider a DASH MPD
>> pointing to a TTML file (not packaged in a MP4). How can a player know
>> that
>> it'll be able to play it meaningfully without downloading the entire TTML
>> file? Does it actually need to know or will it always be able to do
>> something with a TTML file? The solution to this problem will provide the
>> basis for the solution to the MP4 problem. Has the TTML WG considered
>> defining a 'codecs' or 'profile' MIME parameter for TTML?
>>
>> - the codecs parameter of MP4 files is useful for identifying the content
>> of
>> each track in the file before the file is fully downloaded.
>> In Adaptive Streaming contexts such as DASH, the initialization segment
>> can
>> also be downloaded in a first step to get information. So the codecs
>> parameter does not have to provide all information. It could just indicate
>> that the track contains some flavor of TTML and let the initialization
>> segment provide more details. In that case, the solution could be as
>> simple
>> as: codecs="stpp.ttml"
>>
>> - If more than TTML is needed, remember that a typical workflow for
>> packaging/dashing is: get one (or more) TTML file, package it into an
>> (existing) MP4 file, produce an MPD from that MP4 file. Only in the last
>> step is the 'codecs' parameter generated. In MSE cases, you don't even
>> need
>> the MPD but you need to get (most likely in JS) the codecs parameter to
>> create the source buffer. Ideally, the TTML 'codecs' string generator
>> should
>> not have to look at the content of the TTML document, only at the track
>> sample entry (similar to AVC codecs generation).
>>
>> Regards,
>> Cyril
>>
>> 03/05/2014 20:01, David Singer a écrit :
>>
>>> On May 3, 2014, at 9:06 , Glenn Adams <glenn@skynav.com> wrote:
>>>
>>>  On Fri, May 2, 2014 at 12:23 PM, David Singer <singer@apple.com> wrote:
>>>>
>>>> On Apr 30, 2014, at 16:40 , Michael Dolan <mdolan@newtbt.com> wrote:
>>>>
>>>>  Nigel, Dave and all-
>>>>>
>>>>> Is there a TTWG Proposal?
>>>>>
>>>>> Would “stpp” be registered somewhere where it would be unambiguous from
>>>>>
>>>> other Codecs strings unrelated to TTML?  I don’t mean the sample entry
>> 4C
>> code, but in the Codecs string namespace.  Wouldn’t it have to be
>> “application/mp4+stpp….”?  Or why not use “application/ttml+xml” (and
>> similar for WebVTT)?
>>
>>> The codecs string starts with the 4CC of the sample entry.  After that,
>>>>
>>> whoever defined that 4CC gets to say what’s the next element.  And they
>> get
>> to say what’s after that, and so on.
>>
>>> stpp says “some sort of XML”,
>>>>
>>>> since VTT isn't XML, then would it use something different from stpp?
>>>>
>>> yes, we have different 4CCs for text-based and XML-based formats.
>>> stpp is for XML-based
>>>
>>>     and is owned by MPEG.  So indeed the step that goes from ‘stpp’ to
>>>> ‘some
>>>>
>>> sort of TTML’ is owned by MPEG, and MPEG still needs to resolve this.
>>
>>> The thrust is that IF MPEG solves that, THEN there will be names to
>>>> identify TTML dialects, that could go next.  So you would see
>>>>
>>>> codecs=stpp.<some MPEG magic to say it is TTML
>>>> happens>.TTMLFULL+IMSC+SDPUS+EBUTT
>>>>
>>>> I would expect something more simple, e.g.
>>>>
>>>> stpp.vtt
>>>> stpp.ttml.tt1f
>>>> stpp.ttml.tt1p
>>>> stpp.ttml.tt1t
>>>> stpp.ttml.sdpu
>>>> stpp.ttml.st10
>>>> stpp.ttml.st13
>>>>
>>> indeed, MPEG is likely to say that TTML means “go to the W3C, thou
>>>
>> sluggard, and be wise”
>>
>>> where we have a registry for mapping the third IDs above to TTML profile
>>>>
>>> designators, e.g.
>>
>>> tt1f -> http://www.w3.org/ns/ttml/dfxp-full
>>>> tt1p -> http://www.w3.org/ns/ttml/dfxp-presentation
>>>> tt1t -> http://www.w3.org/ns/ttml/dfxp-transformation
>>>> tt1u -> http://www.w3.org/ns/ttml/sdp-us s10f ->
>>>> http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full
>>>> s13f ->
>>>> http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-full
>>>>
>>>> we definitely do not want to create a new syntax/language for use in
>>>> codecs that describes some way to combine profiles; that function is
>>>> already defined by the ttml profile definition document syntax
>>>>
>>> we’re not, but we have to indicate somehow that a document is compatible
>>>
>> with more than one profile.  we also are not restricted here to a
>> 4-character-name, so we can use slightly longer names if they are
>> mnemonic.
>>
>>> we can’t split into several entries as you suggest;  there is one entry
>>>
>> per track, those separated by commas.
>>
>>> codecs=stpp.ttml.tt1f,stpp.ttml.tt1p
>>>
>>> means two tracks, whereas
>>>
>>> codecs=stpp.ttml.tt1f+tt1p
>>>
>>> means one track compatible with two TTML profiles.  Big difference. (I
>>> am not wedded to plus, but comma and period are both taken already)
>>>
>>>
>>>> for example.
>>>>
>>>> For the TTWG to say “yes, we’ll take on dialect naming and forming that
>>>>
>>> second-level parameter” is important; it then means that if MPEG finds a
>> clean solution to the first level, the actual problem in hand is solved.
>> I’d like the MP4 people to realize before the July meeting that this is
>> urgent, and come up with ideas and maybe online discussion ASAP.
>>
>>> This is all provisional — on the TTWG getting agreement not only
>>>>
>>> internally, but with the partners; and on us all liking the final
>> result, of
>> course.
>>
>>> Makes sense?
>>>>
>>>>  I understand how one could signal profiles of TTML that a document
>>>>>
>>>> conformed to concurrently, as in the example – all of TTML and EBU-TT.
>>  But
>> the signaling requirements go beyond that – there is often multiple
>> namespaces in use in one document that are not, as an aggregate, a single
>> “profile”. So, these must be explicitly signaled as well since nearly all
>> profiles permit foreign namespaces.  To accommodate this, the “short
>> names”
>> have to be defined as “profiles of namespaces” I think.
>>
>>> For example, if a document uses the CFF-TT text profile of the TTML Full
>>>>>
>>>> profile, plus SMPTE-TT #608 (US captions), plus CFF-TT metadata, and it
>> was
>> compatible with IMSC, SDP-US and EBU-TT, then it might look like:
>> Codecs=xxxxx.TTMLFULL+IMSC+SDPUS+EBUTT+CFFT+CFFM+SMPTE608.
>>
>>> Regards,
>>>>>                   Mike
>>>>>
>>>>> p.s. I would give the SC29 Secretary a hint about the target of the
>>>>>
>>>> liaison (MPEG v JPEG).  And, you understand you will not receive a reply
>> until mid-to-late July, right?
>>
>>>
>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>> Sent: Wednesday, April 30, 2014 11:48 AM
>>>>> To: watanabe@itscj.ipsj.or.jp
>>>>> Cc: Timed Text Working Group
>>>>> Subject: Liaison response - template on MIME type parameter for
>>>>> TimedText
>>>>>
>>>>> Dear Mr. Watanabe,
>>>>>
>>>>> Thank you for your liaison N14444 of April 2014.
>>>>>
>>>>> We think that we can indeed find a solution together.  We are
>>>>> looking into creating a table of formal "short names" for the
>>>>> profiles of W3C TTML and the profiles of formats derived from it (such
>>>>>
>>>> as SMPTE-TT, EBU-TT, and so on).  If MPEG were to propose how to step
>> from
>> the four-character-code of the sample entry (XMLSubtitleSampleEntry and
>> XMLMetaDataSampleEntry) to something that identifies "a document
>> compatible
>> with one or more profiles of TTML", then we could propose a string
>> composed
>> of a set of one or more these short names as the next parameter.
>>
>>> For example, say W3C defines two profile short names "W3CTTML" and
>>>>> "EBUTTML", and MPEG defines the name "TTML" as referring to the
>>>>> overall family, one might see
>>>>>
>>>>> codecs=stpp.TTML.W3CTTML+EBUTTML,avc1
>>>>>
>>>>> as a codecs string of a file carrying AVC (H.264) and TTML subtitles
>>>>> that are additionally EBU-TT conformant.
>>>>>
>>>>> We would check with those deriving from TTML (e.g. at SMPTE, EBU and
>>>>>
>>>> DECE) if this approach and design are acceptable, before we formalise
>> this.
>>
>>> Kind regards,
>>>>>
>>>>> Nigel Megitt, David Singer (chairs, Timed Text Working Group, W3C)
>>>>>
>>>>> --
>>>>>
>>>>> Nigel Megitt
>>>>> Lead Technologist, BBC Technology, Distribution & Archives
>>>>> Telephone: +44 (0)3030807996
>>>>> Internal (Lync): 0807996
>>>>> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12
>>>>> 7TP
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------
>>>>>
>>>>> http://www.bbc.co.uk
>>>>> This e-mail (and any attachments) is confidential and may contain
>>>>>
>>>> personal views which are not the views of the BBC unless specifically
>> stated.
>>
>>> If you have received it in error, please delete it from your system.
>>>>> Do not use, copy or disclose the information in any way nor act in
>>>>>
>>>> reliance on it and notify the sender immediately.
>>
>>> Please note that the BBC monitors e-mails sent or received.
>>>>> Further communication will signify your consent to this.
>>>>>
>>>>> ---------------------
>>>>>
>>>>>  David Singer
>>>> Manager, Software Standards, Apple Inc.
>>>>
>>>>
>>>>
>>>>  David Singer
>>> Manager, Software Standards, Apple Inc.
>>>
>>>
>>>
>> --
>> Cyril Concolato
>> Multimedia Group / Telecom ParisTech
>> http://concolato.wp.mines-telecom.fr/
>> @cconcolato
>>
>>
>>
>>
>
> --
> Cyril Concolato
> Multimedia Group / Telecom ParisTech
> http://concolato.wp.mines-telecom.fr/
> @cconcolato
>
>
>