Re: Draft TTML Codecs Registry - Issue-305

On Mon, May 19, 2014 at 8:34 PM, John Birch <John.Birch@screensystems.tv>wrote:

>  Hi Glenn,
>
>
>
> Thanks enormously for the clarifications…
>
> W.R.T.  This is not quite what is meant by a processor profile in TTML.
> In particular, it does not signal what features are used, it signals which
> features must be implemented by processor, which may be more or less than
> what is used by a document.
>
>
>
> I am not sure of the usefulness of “signals which features must be
> implemented by processor, which may be more or less than what is used by a
> document” ?
>

As a content author, I might decide that I want processors of document X,
Y, and Z to support the union of features used by X, Y, and Z; or,
alternatively, I might be satisfied with processors that support the
intersection of features used by X, Y, and Z. In the former case, I may end
up specifying requirements that exceed what is used in any of X, Y, or Z
taken by themselves; in the latter case, I may end up specifying
requirements that don't include all features used in X, Y, or Z taken
together. It is my choice as a content author to determine what I want and
what I will minimally accept in a processor.


>  What is the point in signalling features within a document instance that
> are not used by that document instance?
>

There is an overhead to defining a processor profile. Some simple
processors may only recognize a pre-defined set of processor profile
designators, and not support parsing an inlined (embedded) profile
definition that is closely associated with a specific document instance.



> Unless the distinction you are making is to do with feature sets… i.e. the
> document instance uses just some part of a more complete set of features
> identified by a single specific feature tag?
>

Labeled pre-defined processor profiles provide a way for processor
implementors to support a specific feature set, which may exceed the
features used by any given document.


>
>
> And I am further unsure as to the benefits in placing the processor
> requirements within the document… rather than associating / containing them
> within a content profile.
>

Processor constraints are unrelated to content constraints. A profile that
intentionally or inadvertently mixes the two types of constraints fails to
understand the use and necessity of the different types of constraints.


>  I admit to finding it difficult to distance content profiles from
> processing profiles, although I do of course understand that the scope of
> feature tags in each domain is different. *E.g. content tags X, Y and Z
> may all require processing feature J. But processing feature J does not
> imply that X, Y and Z appear in all documents that need feature J. *
>
>
>
> For me, it is enough to  be able to declare that Ecosystem Z requires
> feature J and documents may contain X, Y and Z.
>

I think this is because you have been accustomed to working in the A/V
world of specs where there are only one kind of profile and it co-defines
both encoding requirements (i.e., content format requirements) and decoding
requirements (i.e., content decode/processing requirements).

The world of markup, where may content features are optional, and where one
cannot assume that a processor supports all content features is very
different, and requires treating the two separately. One needs content
profiles for validation, but needs processor profiles for guaranteed
decoder/processing interoperability.


>
>
> Nigel makes the point that the discussed approach allows migration into
> ISO workflows, by carrying the processing profile information within the
> documents… however, I do not believe that most creation workflows will
> generate documents that are this well described.
>

That's a potential issue, but it is somewhat orthogonal to defining a way
to define and use standard or private profiles.


>  I find it more likely that such additional metadata about the document
> content and processing requirements will be added to content when it is
> migrated, and as such may need to be added by *automated examination of
> the document contents*.
>
>
That's possible. However, note that as defined, TTML1 specifies that either
a ttp:profile attribute *or* a ttp:profile element *should* be specified in
a document instance. The TTV tool will warn if both of these are missing.


>
>
> Best regards,
>
> John
>
>
> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
> Mobile : +44 7919 558380 | Fax : +44 1473 830078
> John.Birch@screensystems.tv | www.screensystems.tv |
> https://twitter.com/screensystems
>
>
> *Visit us at Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
> 5E4-01*
>
> *P** Before printing, think about the environment*
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* 19 May 2014 12:16
> *To:* John Birch
> *Cc:* Nigel Megitt; mdolan@newtbt.com; public-tt@w3.org
>
> *Subject:* Re: Draft TTML Codecs Registry - Issue-305
>
>
>
>
>
>
>
> On Mon, May 19, 2014 at 6:47 PM, John Birch <John.Birch@screensystems.tv>
> wrote:
>
> Thanks, understood…
>
> However, I believe most of my comments still stand in that respect.
>
>
>
> Are these agreed requirements and appropriate semantics?
>
>
>
> 1.       A need to signal the constraints / features used in a set of
> documents (content profile). Used in a specification.
>
> I would agree there are use case for defining a content profile. A
> specification that purports to define a content conformance regime should
> define one or more content profiles.
>
>
>
>
>
> 2.       A need to signal conformance to a content profile. Used in a
> document instance.*
>
>  I would agree there are use cases for signaling that a document adheres
> to one or more content profiles, e.g., for validation processing, for
> maintaining invariants in downstream transformations, etc.
>
>
>
> 3.       A need to define the constraints / features used within a
> document instance (processor profile).
>
>  This is not quite what is meant by a processor profile in TTML. In
> particular, it does not signal what features are used, it signals which
> features must be implemented by processor, which may be more or less than
> what is used by a document.
>
>  Used in a document instance and by a processor (and perhaps to describe
> a processor?).
>
>  Both use cases are legitimate: (1) signaling what features must be
> supported in order to process a document, and (2) serving as a convenient
> label (description) of a specific subset of features supported by a
> processor.
>
>
>
>
>
> *A generic processor profile can be inferred from a specified content
> profile (assuming versioning is taken care of), but such an inferred
> processing profile may include constraints/features that have not been used
> in the specific document instance.
>
>
>
> There is more than one reasonable mapping from a content profile to a
> processor profile, so some mapping will have to be selected as a default
> and others will have to be specified within a document instance.
> Alternatively, the document instance can explicitly signal the processor
> profile removing the need to infer it. Indeed, in TTML1, one can only
> signal a processor profile, and cannot signal a content profile.
>
>
>
>
>
> For me, 1 and 2 are crucial… I can live with the inefficiencies of not
> having 3.
>
>
>
> In TTML1, 3 is all we have. TTML2 will add 1 and 2.
>
>
>
>
>
> Best regards,
>
> John
>
>
>
>
> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
> Mobile : +44 7919 558380 | Fax : +44 1473 830078
> John.Birch@screensystems.tv | www.screensystems.tv |
> https://twitter.com/screensystems
>
>
> *Visit us at Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
> 5E4-01*
>
> *P** Before printing, think about the environment*
>
>
>
> *From:* Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
> *Sent:* 19 May 2014 10:36
> *To:* John Birch; Glenn Adams
> *Cc:* mdolan@newtbt.com; public-tt@w3.org
>
>
> *Subject:* Re: Draft TTML Codecs Registry - Issue-305
>
>
>
> Hi John,
>
>
>
> The (now ancient) history of this thread is that organisations creating
> 'deliberately constrained patterns' want to be able to signal within the
> unconstrained world of ISO 14496 what their constraints are, rather than
> leaving the detail out and hoping that mechanisms completely out of band
> are used to ensure successful processing. By signalling more precisely it
> is more likely that the documents/streams that are generated can safely be
> passed to other receiving systems and generate sensible outcomes for the
> audience. These more generalised decoders do need to make a decision about
> ability to process.
>
>
>
> Kind regards,
>
>
>
> Nigel
>
>
>
>
>
> On 19/05/2014 10:24, "John Birch" <John.Birch@screensystems.tv> wrote:
>
>
>
>  Hi Glenn,
>
>
>
> For me Validation is the highest priority. Current workflows for audio /
> visual presentations, regardless of delivery mechanism, all rely upon
> validation of the content.
>
> *The ground rule is that all the content is validated and therefore will
> work on a mandatorily compliant processor / decoder that must include the
> features required for the content profile … *
>
>
>
> There is no scope (or concept) of the decoding processor needing to make
> decisions about whether it can process the content, or what it should do
> with parts of the content it does not understand.
>
> These concepts are superfluous non-issues when a) all content is validated
> to an agreed specification… b) all processors / decoders are expected to
> handle all features of that specification, c) any intentional graceful
> degradation of capabilities (features) is already built into the
> specification.
>
>
>
> Thus, for me the two crucial priorities are a mechanism to allow effective
> validation and a mechanism to allow effective specification (by sub-setting
> of TTML features and the usage of those features).
>
>
>
> I appreciate that you are tackling the generic case of an ‘unknown
> provenance content’ being decoded by a ‘processor with unknown (to the
> author) capabilities’. However, deployed standards derived from TTML
> operate in deliberately constrained patterns, patterns that intentionally
> reduce the potential for mismatches between content creation and content
> presentation.
>
>
>
> RE: Now, if I author content using tts:opacity in a way that conforms to
> a content profile, then that says nothing whatsoever about whether a
> presentation processor will actually implement and use that opacity when
> presenting content. This is why a process profile declaration is important.
> It allows me to say: only present this on a processor that understands and
> uses opacity. This is not a specious use case.
>
>
>
> I cannot imagine a situation (in deployed AV broadcast workflows using
> TTML derived standards) where a content author would actually use a feature
> that might not be present in all the targeted decoders… the need for
> ‘content to present’ would pretty much dictate the use of the lowest common
> denominator of features that the author has experienced as working in the
> majority of decoders. This has been proven in practise. So I think the
> above is only half the use case, the second part of this use case would be
> provide a mechanism for alternative behaviour.
>
>
>
> I.e., should an author deliberately wish to use advanced features, I
> believe they would do so only if there was a clear ‘fall back strategy’,
> this would either be implemented as part of the specification… e.g.
> “opacity if not supported should be presented as fully opaque”, or by
> putting a switch in the content along the lines of “if processor supports
> opacity then X, else Y”. A classic example of a fall back strategies
> deployed in previous timed text implementations is the Teletext mechanism
> for extending the character set of basic Teletext to include accented
> characters. In this mechanism a basic level ‘base character’ is
> transmitted, and then the extended accent character is transmitted… the
> extended characters have an intrinsic backspace, so advanced decoders
> overwrite the base character… basic decoders do not eat the extended
> characters so they remain displaying the base character.
>
>
>
> RE: Furthermore, if a document that uses opacity does not declare (or
> otherwise signal) a processor profile, but only a content profile, then a
> process that infers the former from the latter is ambiguous (without
> further directives) since it is not a logical conclusion that support for
> opacity must be present in a processor when the use of opacity in content
> is optional. This is where I suggested in a previous thread the need for
> something like:
>
>
>
> I see no strong use case for supporting a situation where a content
> profile defines a feature as optional and processors are then free to
> either support that feature or not. This would result in a situation where
> some content that conforms to the content profile would display correctly
> (by which I mean as intended) on some compliant processors, but not display
> correctly on other processors that could still be called compliant. That is
> not a route to ‘interoperability of content’. So I contend that it is
> ‘logical’ to conclude as a practical implementer that if a feature is
> optional in content I should support it in my processor, since ‘logically’
> I may be expected to decode content that may include that feature.
>
>
>
> I can however see some small utility in being able to say ‘this feature is
> not used in this document instance’ – since that might allow a processor to
> optimise itself for processing that document instance, (e.g. by not loading
> heavy libraries of code etc.). However, I am unconvinced that most
> processor implementations would dynamically adapt to each document instance.
>
>
>
> RE my closing comment “"strategy for TTML2 that requires general web
> access, etc." – what I meant is that any new capabilities in TTML2 that are
> defined to address these issues need to be non-referential. I.e. it must be
> possible to have content that can be validated independently of the
> Internet, and processors that can determine the requirements to decode any
> content without access to the internet. Further, the process of determining
> processing requirements should be lightweight, since the processors are in
> many deployed cases likely to be operating in constrained environments.
>
>
>
> With best regards,
>
> John
>
>
>
>
> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
> Mobile : +44 7919 558380 | Fax : +44 1473 830078
> John.Birch@screensystems.tv | www.screensystems.tv |
> https://twitter.com/screensystems
>
>
> *Visit us at Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
> 5E4-01*
>
> *P** Before printing, think about the environment*
>
>
>
> *From:* Glenn Adams [mailto:glenn@skynav.com <glenn@skynav.com>]
> *Sent:* 18 May 2014 22:46
> *To:* John Birch
> *Cc:* nigel.megitt@bbc.co.uk; mdolan@newtbt.com; public-tt@w3.org
> *Subject:* Re: Draft TTML Codecs Registry - Issue-305
>
>
>
>
>
> On Sun, May 18, 2014 at 5:39 PM, John Birch <John.Birch@screensystems.tv>
> wrote:
>
> An extremely important context for content profile is for an 'application'
> (validator) to be able to determine if any given document conforms to a
> specific profile. Note this is not necessarily the same as that application
> being able to decode or present the document.
>
>
>
> I've already stated that validation is a use case for content profile.
> However, we have yet to specify validation semantics for a TTML Content
> Processor, though it is on my list to add a @validation property.
>
>
>
>
> In fact the 'processor A can determine if it can decode document X' debate
> is somewhat specious, since (at least in the context of most current TTML
> derived specifications) most processors should be able to safely assume
> that the documents they are 'asked' to decode conform to a specific
> 'standard', having been passed through a validation step before being
> presented.
>
>
>
> The ability to decode is not as important as the ability to process the
> explicit/implied semantics of a particular feature/extension. All TTML
> processors must be able to instantiate an abstract TTML document instance,
> so, in that sense, every processor can decode any TTML profile. It is
> whether they do something with what they decode that is relevant.
>
>
>
> It is not specious to state that a content author may wish to ensure that
> a processor will support (respect) the semantics of some feature. For
> example, take the #opacity feature, as denoted by the tts:opacity style
> attribute. This is an optional feature in all content profiles defined thus
> far. Optional in the sense that it may be used but need not be used.
>
>
>
> Now, if I author content using tts:opacity in a way that conforms to a
> content profile, then that says nothing whatsoever about whether a
> presentation processor will actually implement and use that opacity when
> presenting content. This is why a process profile declaration is important.
> It allows me to say: only present this on a processor that understands and
> uses opacity. This is not a specious use case.
>
>
>
> Furthermore, if a document that uses opacity does not declare (or
> otherwise signal) a processor profile, but only a content profile, then a
> process that infers the former from the latter is ambiguous (without
> further directives) since it is not a logical conclusion that support for
> opacity must be present in a processor when the use of opacity in content
> is optional. This is where I suggested in a previous thread the need for
> something like:
>
>
>
> ttp:inferProcessorProfileMethod = (loose|strict) : loose
>
>
>
> where loose maps optional content features to optional support in
> processor profile, and strict maps optional in content to required in
> processor. The fact that such a directive is required demonstrates that
> content profiles and processor profiles are different and must be treated
> so.
>
>
>
>
>
>
>
>
> Why, because typical current TTML decoders are operating in constrained
> environments. Usually restricted access to the web. Speed expectations of
> decoding and limited Cpu and memory. IMHO a strategy for TTML2 that
> requires general web access, or anticipates building upon extensive web
> infrastructures and code bases will not resolve the issues faces by current
> TTML implementations in Smart TV, disc/pvr players or set-top boxes.
>
>
>
> I'm not sure where this latter sentence is coming from. What do you refer
> to when you say "strategy for TTML2 that requires general web access, etc."?
>
>
>
>
> Best regards,
> John
>
>
>
> *From*: Glenn Adams [mailto:glenn@skynav.com]
>
> *Sent*: Sunday, May 18, 2014 02:39 AM GMT Standard Time
> *To*: Nigel Megitt <nigel.megitt@bbc.co.uk>
> *Cc*: Michael Dolan <mdolan@newtbt.com>; TTWG <public-tt@w3.org>
> *Subject*: Re: Draft TTML Codecs Registry - Issue-305
>
>
>
>
> On Fri, May 16, 2014 at 2:51 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
> On 15/05/2014 23:45, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
>
>   Could you cite the exact documents/sections that you are referring to
> by "quoted text"?
>
>
>
> I was referring to the text from ISO/IEC 14496-12, AMD2 that Mike included
> in his email.
>
>
>
> I assume you refer to:
>
>
>
> From 14496-12, AMD2:
>
> namespace is a null-terminated field consisting of a space-separated
> list, in UTF-8 characters, of
> one or more XML namespaces to which the sample documents conform. When
> used for metadata,
> this is needed for identifying its type, e.g. gBSD or AQoS [MPEG-21-7] and
> for decoding using XML
> aware encoding mechanisms such as BiM.
>
> schema_location is an optional null-terminated field consisting of a
> space-separated list, in UTF-
> 8 characters, of zero or more URL’s for XML schema(s) to which the sample
> document conforms. If
> there is one namespace and one schema, then this field shall be the URL of
> the one schema. If there
> is more than one namespace, then the syntax of this field shall adhere to
> that for xsi:schemaLocation
> attribute as defined by [XML]. When used for metadata, this is needed for
> decoding of the timed
> metadata by XML aware encoding mechanisms such as BiM.
>
>
>
> This tells me nothing of why one would want to signal content profile or
> why one would want to communicate namespace usage separately (from XMLNS
> declarations found in the document).
>
>
>
>
>
>
>
>
>
> Regarding
>
>
>
> The processing behaviour may or may not be expressed in terms of
> TTML1-style profile features. There's no other language other than prose
> available for this purpose (that I know of).
>
>
>
> If a specification defines processing semantics that must be supported in
> order for a processor to conform to the specification, and if that
> specification does not define any feature/extension, then I would firstly
> view that as a broken specification; however, another potential
> interpretation is that the specification implies an otherwise unnamed
> feature/extension whose feature/extension designation corresponds to the
> profile designation. That is, the profile designation serves as a
> high-level, un-subdivided designation of the set of semantics mandated by
> compliance with the defined profile.
>
>
>
> Concerning 'broken' I note also TTML1SE §3.3 [1] does require an
> implementation compliance statement (ICS) to support claims of compliance –
> it would seem reasonable to require this as an input to the registration
> process. Or in TTML2 weaken this requirement.
>
>
>
> [1] http://www.w3.org/TR/ttml1/#claims
>
>
>
>
>
> This might be a way out of this without having to have such specifications
> define individual, fine-grained feature/extension designations.
>
>
>
> Yes, that would be helpful to lower the barrier to entry.
>
>
>
>
>
> Anyway, I'm still waiting for a someone to articulate a use case for
> signaling a content profile, or any aspect of a content profile (e.g.,
> namespaces, schemas).
>
>
>
> Did Mike's email including the relevant sections from 14496-12 not do this?
>
>
>
> No, it does not. I repeat, signaling content profile can only have two
> purposes in the context of decoding/processing as far as I can tell:
>
>
>
> (1) to validate incoming document, which is not yet done by any TTML
> processor, though we are looking at adding a @validation attribute in TTML2
> that could be used to require this;
>
>
>
> (2) to imply a processor (decoder) profile in lieu of explicitly signaling
> of a processor profile;
>
>
>
> In the context of the current thread, it seems only the second of these is
> potentially relevant. However, I have to ask why one wouldn't simply signal
> a processor profile instead of using a more complex process of signaling a
> content profile and then having the decoder/processor infer a processor
> profile from that content profile.
>
>
>
> If there are other reasons for signaling content profile (in the context
> of the current thread) then I haven't seen them articulated.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, May 15, 2014 at 1:28 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
>   Since namespaces and schemas define and constrain document contents
> without defining processing behaviour the quoted text defines a content
> profile declaration. It isn't asking for anything concerning specific
> processor capabilities but is merely describing  the contents of the
> document. The information may be used for downstream processing by context
> aware processors. The reference to namespace-aware compression makes clear
> that the mapping from whatever label scheme we choose to namespaces and
> schemas is important.
>
>
>
> However it's clear that we expect the receiving system to use the
> information to direct its processing, as described previously.
>
>
>
> Consider that the specification of a TTML variant x consists of the union
> of a content profile Cx and a description of processing behaviour Bx, which
> I'll express as S = C + B. The content profile shall itself reference one
> or more namespaces and schema locations. The processing behaviour may or
> may not be expressed in terms of TTML1-style profile features. There's no
> other language other than prose available for this purpose (that I know of).
>
>
>
> It is possible to define two specifications S1 and S2 where S1 = Cx + Bx
> and S2 = Cx + By, i.e. the same contents are processed with different
> behaviour. By the quoted text there is no need to differentiate between
> them from an ISO 14496 perspective. However we understand from our
> knowledge of the problem space that it may be useful to signal to a
> receiving system which behaviour set is desirable. And it may be helpful in
> a receiving system to differentiate between the available behaviours in
> order to provide the optimal experience.
>
>
>
> Would it be contrary to the spirit of the ISO wording to assign short
> labels each corresponding to some Specification, and for receiving systems
> to be expected to dereference (using a cached lookup table!) from those
> labels to the namespaces and schema locations contained within that
> specification's content profile? This would satisfy the ISO requirements
> and permit us to signal additionally the processor features and behaviours.
> At this stage the expression of those is not our concern – just that there
> is a document somewhere that describes how the implementation should work.
>
>
>
> Going back to the previous example, if a document conforms to Cx then it
> could be signalled either as S1 or S2 or both, and if the content provider
> has verified that presentation will be acceptable either way then both S1
> and S2 would be declared, otherwise just one of them (or neither if there's
> some other Sn that also uses Cx).
>
>
>
> With this scheme combinatorial logic wouldn't really make sense – you
> could infer something about unions and intersections of content profiles
> but since the language used to describe processor behaviours can't be
> mandated (okay it could in theory, but it wouldn't be accepted in practice)
> it wouldn't be a well defined operation. Incidentally this is in no way a
> critique of the effort put in by Glenn, and its outcomes, in terms of
> defining content and processor profiles – though it might be nice to verify
> that this simple expression can be expanded into that scheme should a
> specification writer choose to do so.
>
>
>
> This implies that every combination of content profiles and behaviours
> must be considered carefully and registered as a new specification with a
> new label. It also implies that if a document declares conformance with a
> set of specifications then it must conform to every member of the set of
> content profiles and it may be processed according to any one of the set of
> processing behaviours.
>
>
>
> The expression of that set is as described previously, where we pick our
> favourite delimiter out of a hat made out of ampersands.
>
>
>
> Also: this topic was discussed in summary briefly on the call today and a
> new suggestion arose, that some guidance for 'reasons why the TTWG would
> reject an application for registration' would be helpful. When requiring
> combinations to be registered separately there's a greater need to ensure
> that the registration process is quick and painless, and this guidance
> would help us and those who may follow to expedite it.
>
>
>
> Nigel
>
>
>
>
>
> On 15/05/2014 18:00, "Michael Dolan" <mdolan@newtbt.com> wrote:
>
>
>
>    I believe the problem statement is to replace the potentially unwieldy
> long strings in the namespace & schema_location fields defined in 14496-12
> and 14496-30 with a more compact string suitable for the DASH manifest
> codecs field.
>
>
>
> From 14496-12, AMD2:
>
>
>
> namespace is a null-terminated field consisting of a space-separated
> list, in UTF-8 characters, of
>
> one or more XML namespaces to which the sample documents conform. When
> used for metadata,
>
> this is needed for identifying its type, e.g. gBSD or AQoS [MPEG-21-7] and
> for decoding using XML
>
> aware encoding mechanisms such as BiM.
>
>
>
> schema_location is an optional null-terminated field consisting of a
> space-separated list, in UTF-
>
> 8 characters, of zero or more URL’s for XML schema(s) to which the sample
> document conforms. If
>
> there is one namespace and one schema, then this field shall be the URL of
> the one schema. If there
>
> is more than one namespace, then the syntax of this field shall adhere to
> that for xsi:schemaLocation
>
> attribute as defined by [XML]. When used for metadata, this is needed for
> decoding of the timed
>
> metadata by XML aware encoding mechanisms such as BiM.
>
>
>
> I’m warming up to the idea of requiring TTML content profiles be created
> for the combinations.
>
>
>
>                 Mike
>
>
>
>
> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
> Mobile : +44 7919 558380 | Fax : +44 1473 830078
> John.Birch@screensystems.tv | www.screensystems.tv |
> https://twitter.com/screensystems
>
>
> *Visit us at Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
> 5E4-01*
>
> *P** Before printing, think about the environment*
>
>
>
> *From:* Glenn Adams [mailto:glenn@skynav.com <glenn@skynav.com>]
> *Sent:* Thursday, May 15, 2014 9:15 AM
> *To:* Nigel Megitt
> *Cc:* Michael Dolan; TTWG
> *Subject:* Re: Draft TTML Codecs Registry
>
>
>
> My understanding from Dave was that the problem is how to answer the
> following method:
>
>
>
> boolean canPlay(String contentTypeWithParameters)
>
>
>
> I have not seen any statement of a problem that relates to signaling
> content conformance.
>
>
>
> As for requirements driving the ability to express a combination of
> profiles, we already have (in TTML1) and will have more (in TTML2) that
> permits a user to characterize processing requirements by means of a
> combination of existing profiles. Consequently, any shorthand signaling of
> first-order processor support needs to be able to repeat the expression of
> such combinations.
>
>
>
> I don't buy any "its too complex" argument thus far, primarily because
> nobody has stated what is (overly) complex in sufficient detail to
> understand if there is a problem or not.
>
>
>
> My perception of the TTML profile mechanism is that it is easy to
> understand and implement, and, further, that it is a heck of lot easier to
> understand and implement than XML Schemas.
>
>
>
>
>
> On Thu, May 15, 2014 at 9:58 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
> Agreed there's a gulf of understanding/expectation that we need to bridge.
>
>
>
> Can anyone volunteer to draft a set of requirements for this
> functionality, in the first instance being the smallest set needed to meet
> the ISO specs? (Mike, I guess I'm thinking of you, following our discussion
> at the weekly meeting earlier)
>
>
>
>
>
> On 15/05/2014 16:48, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
>
>  i can see this subject is not going to be resolved easily as we clearly
> have a large gap about requirements; e.g., i think there are no
> requirements to signal content conformance, but only client processor
> requirements, i think we must use the TTML profile mechanism, etc
>
> On Thursday, May 15, 2014, Michael Dolan <mdolan@newtbt.com> wrote:
>
> Maybe "highly undesirable", but if we don't address the A + B signaling
> explicitly, then profiles need to be created for all the combinitorics of
> namespaces in practice. Not the end of the world, but virtually prevents
> the
> simple signaling of 3rd party namespaces already provided by the
> namespace/schemaLocation mechanism today. No I am not proposing we use that
> - I am pointing out a deficiency in this proposal that we already address
> today in 14496.
>
> Anyway, we need to go through the points in my email a week ago - if not
> today, then on the 29th.
>
>         Mike
>
> -----Original Message-----
> From: David Singer [mailto:singer@mac.com <singer@mac.com>]
> Sent: Thursday, May 15, 2014 5:20 AM
> To: Glenn Adams
> Cc: TTWG
> Subject: Re: Draft TTML Codecs Registry
>
> OK
>
> Though it will be a sub-parameter of the codecs parameter for the MP4 file
> type, from the point of view of TTML it's actually a profile short name
> registry rather than codecs registry, so I think we should rename it.
>
> the values here should be usable in both
> a) the profiles parameter for the TTML mime type
> b) the codecs parameter for the MP4 mime type
>
> so, also "named codecs" -> "named profiles"
>
>
>
> I agree with Cyril that we only need a single operator here (implement one
> of these profiles and you're good to go), both because we don't need the
> complexity, and because a "implement both/all of these" is effectively
> inviting file authors to make up new profiles ("to process this document
> you
> have to implement both A and B"), which is (IMHO) highly undesirable.
>
>
>
> On May 15, 2014, at 9:55 , Glenn Adams <glenn@skynav.com> wrote:
>
> > See [1].
> >
> > [1] https://www.w3.org/wiki/TTML/CodecsRegistry
>
> Dave Singer
>
> singer@mac.com
>
>
>
> ----------------------------
>
>
>
> 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.
>
> ---------------------
>
>
>
>
>
>
>
> This message may contain confidential and/or privileged information. If
> you are not the intended recipient you must not use, copy, disclose or take
> any action based on this message or any information herein. If you have
> received this message in error, please advise the sender immediately by
> reply e-mail and delete this message. Thank you for your cooperation.
> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
> Suffolk, IP6 0EQ
>
>   ­­
>
>
>
>
>
> This message may contain confidential and/or privileged information. If
> you are not the intended recipient you must not use, copy, disclose or take
> any action based on this message or any information herein. If you have
> received this message in error, please advise the sender immediately by
> reply e-mail and delete this message. Thank you for your cooperation.
> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
> Suffolk, IP6 0EQ
>
>   ­­
>
>
>
> This message may contain confidential and/or privileged information. If
> you are not the intended recipient you must not use, copy, disclose or take
> any action based on this message or any information herein. If you have
> received this message in error, please advise the sender immediately by
> reply e-mail and delete this message. Thank you for your cooperation.
> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
> Suffolk, IP6 0EQ
>
>   ­­
>
>
>
>  This message may contain confidential and/or privileged information. If
> you are not the intended recipient you must not use, copy, disclose or take
> any action based on this message or any information herein. If you have
> received this message in error, please advise the sender immediately by
> reply e-mail and delete this message. Thank you for your cooperation.
> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
> Suffolk, IP6 0EQ
>    ­­
>