- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Wed, 07 May 2014 09:08:50 +0200
- 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