Time containment semantics for smpte time base.

[skynavga]

Indicate that parallel time container semantics always apply in smpte discontinuous mode, and, as such, sequential containment must not be specified, i.e., parallel containment always applies.

Editorial notes from 2015-01-14.

[nigelmegitt]

Additional to this, explain/clarify that parallel time containment in smpte discontinuous means that a child element can not be active unless its parent element is active, and is orthogonal to computation of element times; in the case of discontinuous marker mode syncbase arithmetic does not apply.

[skynavga]

@nigelmegitt regarding #377 (comment), what you say is always true, i.e., by SMIL, a timed descendant cannot be active unless all its ancestors are active, so we don't need to say it again.

[nigelmegitt]

@skynavga This is far from obvious even when looking at SMIL, I think it would be helpful at least to add an informative note. Also, bear in mind that the current text exists in the section on timeContainer, in the paragraph describing par semantics:

Furthermore, the specification of the time interval of each child element is considered to be relative to the temporal interval of the container element instance.

This is clearly untrue in smpte discontinuous mode, since the markers are not relative.

By the way, in this context there is an alternative interpretation of timeContainer="seq" in smpte discontinuous mode, which is that, when processing a seq's children, each sibling must be activated and deactivated in document order, i.e. the n th sibling cannot be activated until the n-1 th sibling has been deactivated, whereas in par any sibling may be activated independently of the other siblings, when its begin marker is observed.

This suggests that deprecating seq is not the right course of action, but describing the difference would be more useful.

[nigelmegitt]

My comments were not addressed by the pull request.

[nigelmegitt]

Given #377 (comment) I believe this issue is in fact incorrect and the change should not have been made in the way that it was. There is a defined meaning for seq time containment so it should not have been deprecated.

[skynavga]

@nigelmegitt is this a blocking comment for CR1, or can you open a new issue to address this in CR2?

[nigelmegitt]

It's this issue, and I think we should now attempt to address it in CR2.

[skynavga]

@nigelmegitt you seem to have missed the following text (in a note) under ttp:markerMode:

An additional side-effect of operating in discontinuous mode is that time expressions of children have no necessary relationship with time expressions of their temporal container; that is, temporal containers and children of these containers are temporally activated and inactivated independently based on the occurrence of a labeled synchronization (marker) event.

This means that seq does not have defined semantics (and should be deprecated) and that par does not work as it normally would, i.e., times of children of a par container are not offset from the interval of the container.

At this point, I don't know what further action I should take. You seem to be asking for an informative note above, but I don't know what you want it to say (in general). If you want an additional note, could you create a new issue to avoid doing two PRs against this issue?

[nigelmegitt]

I don't see that wording as contradicting the idea that smpte discontinuous can work in seq mode. Consider:

<tt timebase="smpte" markerMode="discontinuous">
...
<div begin="10:00:00:00" end="10:30:00:00" timeContainer="seq">
   <p end="10:00:05:00">Active 10:00:00:00 until 10:00:05:00</p>
   <p end="10:00:08:00">Active 10:00:05:00 until 10:00:08:00</p>
   <p end="10:00:11:00">Active 10:00:08:00 until 10:00:11:00</p>
</div>
...
</tt>

I see nothing in the current spec that prevents this from working as the text content describes, in other words each p begins when the previous p ends, aside from the first one which begins when its parent begins.

The only difference relative to a non-discontinuous marker mode is that those activations and deactivations are triggered by SMPTE timecode labels being matched rather than clock values.

Essentially as far as I can tell this issue was invalid when filed and we should roll back the deprecation, since no motivation for the deprecation was provided.

[skynavga]

In discontinuous mode, timing containment simply doesn't apply. That is, there is NO syncbase. There are labels in content and in TTML, and when those labels match, a begin or end event is generated.

Keep in mind that in discontinuous mode, there is no requirement that the time code labels be monotonic. For example, you might have:

Label 1 - 10:00:11:00
Label 2 - 10:00:05:00
Label 3 - 10:30:00:00
Label 4 - 10:00:08:00
Label 5 - 10:00:00:00

where the video frame associated with Label 1 appears prior to the video frame associated with Label 2.

For example, the video might be the output of an editing process that has reordered or reversed video segments (and time labels) arbitrarily.

[nigelmegitt]

@skynavga right, we're agreed on #377 (comment). However this does not mean that the seq activation behaviour cannot apply even though offset time calculations are not performed. In other words children of a seq container are activated in document sequence order with the first child being available for activation only when the parent has been activated, and subsequent siblings being available for activation only when their prior sibling has been deactivated.

And my example at #377 (comment) did assume that the timecode labels would appear in the specified order, so given a different order, the behaviour would be different.

Given the order you present, the processor should present nothing since the label that activates the div appears last, so none of the child ps is ever available for activation when their timecode label appears.

Nonetheless, the semantic and behaviour is well defined for this case of smpte discontinuous in a seq timecontainer.

[css-meeting-bot]

The Working Group just discussed Time containment semantics for smpte time base. ttml2#377, and agreed to the following:

• SUMMARY: Back out the deprecation of seq time containment in smpte discontinuous

The full IRC log of that discussion

<nigel> Topic: Time containment semantics for smpte time base. ttml2#377
<nigel> github: https://github.com//issues/377
<nigel> Glenn: Nigel, you're original complaint was that we prematurely deprecated the use of
<nigel> .. the sequential time containment in smpte discontinuous mode and you have argued that
<nigel> .. there is a potential interpretation of that. I argue that even if that is the case then it
<nigel> .. doesn't make any sense to use it and it shouldn't be used anyway.
<nigel> .. In my mind smpte discontinuous indicates that there is no time container at all.
<nigel> Nigel: I don't think there's no time containment.
<nigel> Glenn: For example if you have a span in a p and the span says begin=0s and the p says begin=10s
<nigel> .. for me the 0s on the begin relates to the document timeline not to the p.
<nigel> .. Any time you find a time in a smpte discontinuous document then it relates to the
<nigel> .. document context. This is from markerMode. The problem with what you're suggesting
<nigel> .. Nigel is that it backs out that. Under markerMode it says that time expressions must not
<nigel> .. be calculated etc. in discontinuous mode. All time expressions are interpreted as time
<nigel> .. events which cause a temporal interval to begin or end accordingly.
<nigel> Nigel: I don't disagree with that but my point is that time expression calculation is orthogonal
<nigel> .. to time containment, and that there is a logical processing model for sequential time
<nigel> .. containment with smpte discontinuous, treating the time expressions as events.
<nigel> .. I don't believe that there is any data presented to deprecate this potential usage.
<nigel> Glenn: If we take out the deprecation, I don't really want to tweak this language or add
<nigel> .. more language?
<nigel> Nigel: I don't think we need to do anything particular to the spec and I wouldn't prioritise
<nigel> .. this niche use case, just back out the deprecation.
<nigel> Glenn: Is this editorial?
<nigel> Nigel: Although we apparently did not have consensus for this when #647 was merged
<nigel> .. in February, this is a substantive change relative to CR1 unfortunately.
<nigel> Glenn: Okay I can accept backing out the deprecation, I may ask for early merge next week.
<nigel> SUMMARY: Back out the deprecation of seq time containment in smpte discontinuous

[skynavga]

Merged early per WG resolution.