Issue-270 and Issue-335

Glenn, Courtney, all,

The edit to TTML2 ascribed to issue-270 and issue-335 (https://dvcs.w3.org/hg/ttml/rev/3cbc109b90bd) is causing me some concern. I have added notes to both those issues, and additionally I have a number of queries to raise for discussion:

Concerns

1. it appears to define an addition/subtraction operation on SMPTE time values even if they're discontinuous. The processing of these seems to be undefined, so they should be disallowed, shouldn't they?

2. It blurs the layers of interpretation of time values from documents up into any external context. For example it opens up the ambiguity that, when a sequence of TTML documents is wrapped e.g. in ISOBMFF, there are media time offsets available both in TTML and in the wrapper, and authors may be unclear whether they are intended as independent (additive) offsets or as duplicate offsets in which one may be considered not for processing, i.e. metadata.

3. It is actually the opposite proposal to the one I made in Issue-335: I've added a note there and re-opened it.

4. If clock time is prohibited from using media offset because the discontinuityOffset can not be derived in the absence of a date, then I would certainly be happy to propose the addition of a date value. A use case for this is when a TTML document is created as an archive artefact by a processor that observes some real world timed events and converts them into TTML.

5. It does nothing to address the scenario where the media time corresponding to the beginning of the related media object is known at authoring time, and is non-zero. This media begin time is distinct from, and possibly earlier than, the beginning of the contents of the TTML document.

Proposals

I would propose a resolution to points 1, 2, 3 and 5 that is to remove mediaOffset and add a ttp:mediaBegin parameter, expressed in the same time base as the document's ttp:timeBase parameter. This also fits better with ttp:mediaDuration.

I would additionally propose allowing dates to be specified to use in relation to clock times to resolve point 4, perhaps with a ttp:date parameter, valid only when ttp:timeBase="clock". Note that this does not resolve any time comparison issues caused by documents whose times cross midnight and wrap back round to a smaller number of hours.


Are there other related use cases or requirements not met by these proposals?

Kind regards,

Nigel