Re: Issue-270 and Issue-335

On Mon, Sep 22, 2014 at 8:38 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

>  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?
>

I had intended to add material to deal with the discontinuous smpte mode,
but it didn't get into the edit. Will add.


>
>  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.
>

Since TTML doesn't know anything about external wrapper metadata, it isn't
the right place to deal with such possible ambiguity (e.g., in different
offset values internal and external). The correct place to deal with this
is in the external spec.


>
>  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.
>

My reason for excluding clock mode is because it doesn't have a related
media object.


>
>  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.
>

I don't understand this statement, since this is precisely what
ttp:mediaOffset does: allow the beginning of the root temporal extent to be
offset either before or after the beginning of the related media object.

There are two distinct one-dimensional temporal coordinate spaces here that
are potentially related:

   - document's temporal coordinate space, call this TIME(document)
      - origin is at ORIGIN(document), which is always ZERO (0)
      - has begin time BEGIN(document)
      - has explicit or implied duration of DUR(document)
      - so root temporal extent is always the open interval:
         - [ 0, DUR(document) )
      - related media object's temporal coordinate space, call this
   TIME(media)
      - origin is at ORIGIN(media)
      - has begin time BEGIN(media)
      - has explicit or implied duration of DUR(media)
      - so media temporal extent is always the open interval:
         - [ BEGIN(media), BEGIN(media) + DUR(media) )

The intent of ttp:mediaOffset is to express the delta between
BEGIN(document) and BEGIN(media):

   - if ttp:mediaOffset > 0, then BEGIN(document) temporally follows
   BEGIN(media)
   - if ttp:mediaOffset < 0, then BEGIN(document) temporally precedes
   BEGIN(media)

Note that this definition is arbitrary: we could invert the meaning if we
wish. In any case, the current language decodes as follows:

Given ttp:mediaOffset = +10s, then <body begin="5s"/> means that body
starts at 15s after BEGIN(media).

Or, given ttp:mediaOffset = -5s, then <body begin="5s"/> means that body
starts at BEGIN(media).

Given this formalism, we don't really care about BEGIN(media) -
ORIGIN(media).

Now, if you are suggesting an alternative use case where ORIGIN(document)
!= 0 in the TIME(document) coordinate space, then that is something I
haven't considered, and certainly did not intend to address. Indeed, doing
so would be problematic since SMIL timing semantics assumes that
unspecified begin defaults to 0s, and further, that 0s corresponds to
ORIGIN(document).

My response to such a proposed use case would probably be: we don't support
it, you don't need to do it anyway, so don't do it.

Note that the above considerations assume that time base is media, or that
time base is smpte continuous mode, or that time base is smpte
discontinuous mode and that all smpte time events have been converted to
equivalent smpte continuous mode values, e.g., by playing back a media
object in 1X normal play mode and recording the PTS time that corresponds
with each frame associated with a smpte time label.


>
>  *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.
>

Hmmm. I'm not inclined to make this change, because mentally I see
mediaOffset as expressing a difference/delta/offset between two points in
two different one-dimensional coordinate spaces both representing linear
time (at 1X play rate). Calling it mediaBegin implies in my mind
BEGIN(media), i.e., the delta between BEGIN(media) and ORIGIN(media), and
not the delta between BEGIN(document) and BEGIN(media).


>
>  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.
>

Again, I'm wondering what is the related media object? To my recollection,
ttp:timeBase="clock" was added to TTML to handle timed text cases that
don't have a related media object.


>
>
>  Are there other related use cases or requirements not met by these
> proposals?
>
>  Kind regards,
>
>  Nigel
>
>

Received on Monday, 22 September 2014 20:15:10 UTC