- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Wed, 07 May 2014 14:09:05 +0200
- To: public-tt@w3.org
Hi Nigel, >> 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? > I would prefer not to define multiple solutions to the same problem > occurring in multiple places so I'm in favour too! Good! Let's work on this problem first, and then we'll tackle the MPEG problem. > > We've only been presented with the problem (until your point) in the > context of MPEG and the codecs parameter, so were attempting to solve it > for that case first. Sorry if the liaison wasn't clear. That was the intent of the paragraph: " In particular, for the case of TTML, MPEG believes the definition of a parameter for the TTML MIME type is needed, to enable identifying the different configurations of TTML. We take note of the content profile work in W3C TTML2, which may be relevant. If a parameter were defined by the owning organizations (e.g. W3C as the owner of the base TTML specification), MPEG would probably reuse it." > > Looking at RFC6381 [1] it appears that we could adopt the same syntax and > semantics, ask to add application/ttml+xml to the set in §4.2 whose media > type can carry a profiles parameter and ask to add RFC6381 as an > additional reference to the application/ttml+xml registration at IANA [2]. > We would use the same short labels for identifying a variant of TTML in > both the codecs parameter and the profiles parameter. This is indeed a good direction. I don't know if you need to add something to RFC6381 or only to update the application/ttml+xml registration at IANA to add a parameter. Then I'm not sure what the codecs parameter would mean for TTML. RFC6381 says: "When the 'codecs' parameter is used, it MUST contain all codecs indicated by the content present in the body part." I don't think it's applicable in that sense, that's why I only used the "profiles" parameter in the above example. But I'm not even sure that the semantics of "profiles" as given in RFC6381 are applicable here. Maybe the editor of that RFC will shed some light on this here. Maybe just defining a parameter name and associated semantics in the TTML MIME type registration will suffice. Cyril > > [1] https://tools.ietf.org/html/rfc6381 > [2] http://www.iana.org/assignments/media-types/media-types.xhtml > > Would that resolve both problems? What new problems would it introduce? > > Nigel > >>> 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 >> >> > > > ----------------------------- > 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. > ----------------------------- > -- Cyril Concolato Multimedia Group / Telecom ParisTech http://concolato.wp.mines-telecom.fr/ @cconcolato
Received on Wednesday, 7 May 2014 12:09:39 UTC