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

Re: New Change Proposal 28 on IMSC 1: Profile refactoring

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 14 Aug 2014 13:33:21 +0000
To: Pierre-Anthony Lemieux <pal@sandflow.com>
CC: "public-tt@w3.org" <public-tt@w3.org>
Message-ID: <D01273FC.FDEB%nigel.megitt@bbc.co.uk>
Hi Pierre,

Thanks for this, CIL:

On 14/08/2014 13:57, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:

>Hi Nigel,
>
>Thanks for capturing your thoughts in the change proposal.
>
>I have the following observations:
>
>[*] constraints on document complexity are key to the IMSC Text and
>Image profiles: without such constraints, it is not possible to ensure
>rendering of a document across implementations.

Itıs certainly one approach but only works in a limited set of
circumstances. Other things can also impact successful rendering, that are
not and probably can not be verified by inspection of a document. For
example, the capacity to support a potentially unlimited number of fonts.

(Incidentally that example is potentially of much more consequence than
the maximum number of simultaneous regions constraint, because at least in
the case of regions thereıs an upper bound to the size of the graphics
buffer, equal to the root extent. But I digressŠ)

>It is therefore important that the HRM and associated performance
>parameters remain part of the existing Text and Image profiles. I also
>see no rationale for changing the names of the two profiles.

The names are less important to me than the concept.

>If there is interest, a set of users may wish to propose a separate,
>additional unconstrained profile based on the Text Profile, e.g.
>"Unconstrained Text Profile".

Thatıs what I did in CP28.

>[ed.: I personally believe that a distribution profile without
>document complexity constraint is much less valuable, based on my
>experience in D-Cinema.]
>
>[*] the Change Proposal states "the key constraint in broadcast
>environments is often delivery bit rate rather than document
>complexity".
>
>While delivery bit rate might have been the ultimate constraint with
>teletext and 608, it is not directly applicable to TTML AFAIK. The HRM
>proposes a complexity model for TTML documents.

There are draft specs of broadcast standards in other groups that include
flavours of TTML and will be delivered over bitrate constrained channels,
so, yes, this is directly applicable.


>Also, I would think a more practical constraint (in all environments)
>is probably the audience reading rate (e.g. 180 words/min). Assuming:
>
>- no glyph is ever repeated across ISDs (worst case)
>- the height of characters are 1/24 the height of the root container
>(24*40 grid)
>- no CJK characters
>
>The default HRM performance parameters allow an average character rate
>per second M equal to
>
>M = 1/ (time to render one character)
>    = Ren(Gi) / NRGA(Gi)
>    = 1.2/(1/24)^2
>    = 691 characters per second.

This is a rendering rate not a reading rate. Real world scenarios donıt
present characters in a continuous stream with a Œcharacters per secondı
rate.


>
>The default values can be overridden by specific applications if needs be.

I have proposed a mechanism in IMSC for doing this, using extension
designators to define conformance to the HRM: that should include
designators for specific threshold values.


>[*] In general, I think the group needs more specific use cases for
>such an additional profiles before undertaking major changes to the
>specification.

I would very much welcome a full set of use cases or requirements for IMSC
as it currently stands, so we can add to it without duplication, and also
so we can demonstrate the conformance to those requirements that IMSC
achieves.


>For instance, is the intent for others to define their own HRM, to
>eschew HRMs altogether or merely define different performance
>parameters?

The intent is to allow that decision to be delegated to organisations
creating platforms using IMSC as a basis for providing subtitles, based on
whatever constraints those platforms have.

The intent is also to allow other features to be introduced to a profile
in IMSC, including features that would currently be blocked by the
requirement to meet the HRM constraints.

I did include a Rationale section in the CP, including these concepts.

Kind regards,

Nigel



>
>Best,
>
>-- Pierre
>
>On Fri, Aug 8, 2014 at 3:04 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>wrote:
>> Iıve added a new Change Proposal to resolve issue-307, issue-315,
>>issue-319
>> and assist with issue-332:
>>
>> Change Proposal 28,
>> Priority 2 (for LC),
>> Product IMSC 1
>> Title ³Profile refactoring²
>> URL: https://www.w3.org/wiki/TTML/changeProposal028
>>
>> Summary: IMSC 1 currently defines two profiles, a Text and an Image
>>profile,
>> both of which include the requirement to meet the complexity constraints
>> expressed in the HRM. This proposal is to factor out the complexity
>> constraints from the content profiles, while providing a clearly
>> identifiable profile that continues to match what implementors of, say,
>> CFF-TT, have already built. A third profile not constrained in
>>complexity is
>> proposed.
>>
>> Nigel
>>
Received on Thursday, 14 August 2014 13:33:51 UTC

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