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

On Tue, May 6, 2014 at 3:55 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> There's a more substantive issue IMHO. Namespace and schemaLocation do not
> adequately identify a particular variant of TTML, nor is it clear how they
> should be derived. There are two issues, at least:
>
> 1. If a profile uses a mutable namespace (which I would normally expect)
> then different versions of the same profile will have the same namespace
> and schemaLocation and thus not be distinguishable.
>

this is why I've introduced the ttp:version attribute (on <tt:tt>) in
TTML2; further, I defined new TTML2 flavors of transformation,
presentation, and full profiles [1], since we can't retroactively change
the DFXP profile definitions found in TTML1;

[1]
https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#vocabulary-profile-designators


> 2. It is unclear whether all of the namespaces used in a document must be
> listed or just those that are relevant for downstream processing.


i'm not sure why there is so much (or any) discussion of namespaces or
schemas here; there is no requirement to use a schema when processing a
TTML document, unless validation is signaled (note I have ACTION-232 to
consider adding a @validation attribute to signal that validation is
required)

if a document uses an element or an attribute defined in a namespace, then
that namespace must be declared in scope of that element or attribute; if
it isn't, then the document is not a well formed XML document;

so, what would the purpose be to extract namespace binding information and
externalize this information?


> If a
> processor sees a namespace that was not listed what should it's behaviour
> be?


it will not matter to the TTML processor what external metadata is provided
in an external context; all that matters to the processor is if the
document is well formed XML (and therefore must have namespace bindings)
and whether the TBD @validation attribute signals validation is required,
in which case the processor would need all schema resources associated with
used namespaces);

since we haven't even defined @validation attribute yet, the current
discussion is probably best limited to current syntax/semantics (without
@validation);


> I do not believe that we are trying to create something here that
> should have an impact during processing of the document;


agreed; none of this codecs business matters to the TTML processor or how
it processes a document;


> rather the
> parameter can be used either to select an appropriate document or to
> decide whether or not to download and process a document or ignore it.
>

yes, it is an out-of-band signaling with semantics at a level higher than
the TTML processor per se; however, we should avoid defining such a higher
level semantics that intends to replicate (wholly or partially) or subsume
the already defined profile processing semantics of TTML;


> Similarly it should not be a requirement for the MP4 packager to parse the
> document to work out all of the namespaces that are actually used.
>

since i don't see any need or requirement to collect a list of namespaces,
this is a moot point IMO


>
> Returning to the current alternative proposal, I have a question about the
> stpp.TTML.[short name1]+[short name 2]+[etc] idea: what is the order of
> precedence if we use the + symbol?
>
> I can imagine stpp.TTML.DFXP+IMSC being interpreted either as "this
> document is a DFXP TTML document and an IMSC TTML document" or "this
> document is a DFXP TTML document and some other unregistered thing called
> IMSC". Are we free to say that the + operator has higher precedence than
> the . "operator" to ensure that the former interpretation holds?
>
> This isn't as obvious as it looks at first: in TTML §4 [1] we say abstract
> document types can be validated by pruning all content in non-TT
> namespaces. Consider an alternate format XX that has a similar rule that
> prunes all non-XX namespace content. Someone constructs a document that
> contains both TT namespace elements and XX namespace elements at the top
> level. The document now serves dual purposes (ignoring for the moment
> whether or not this is a good idea), and could potentially be described
> either as "stpp.TTML.tt1f+stpp.XX" or as "stpp.TTML.tt1f+XX" - which of
> these is correct depends on how we and MPEG collectively define the syntax
> in the codecs parameter.
>
> [1] http://www.w3.org/TR/ttml1/#profiles
>
> In the current proposal there is no way to signal conformance to two
> mutually independent XML formats that can legally be combined in the same
> document.
>
> (in case you're wondering, no, I don't actually want to do this but I'm
> just observing the effect of the undefined parts of the current proposal)
>
> Nigel
>
>
> On 05/05/2014 14:58, "Michael Dolan" <mdolan@newtbt.com> wrote:
>
> >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.
> >
> >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?
> >
> >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
> >
> >
> >
>
>
>
> -----------------------------
> 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.
> -----------------------------
>