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

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

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Wed, 07 May 2014 09:08:50 +0200
Message-ID: <5369DC02.9060000@telecom-paristech.fr>
To: public-tt@w3.org
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)
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
Received on Wednesday, 7 May 2014 07:09:21 UTC

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