Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify temporal activity and timing semantics #311

Open
palemieux opened this issue Dec 28, 2017 · 7 comments
Open

Clarify temporal activity and timing semantics #311

palemieux opened this issue Dec 28, 2017 · 7 comments
Assignees

Comments

@palemieux
Copy link
Contributor

palemieux commented Dec 28, 2017

In light of #310, #193, #303, #308 and #309, I suggest that the temporal activity and timing semantics of TTML1 be clarified through the explicit algorithm below.

The proposed algorithm is intended to be consistent with SMIL and TTML prose, and added to an informative annex.

It is implemented at sandflow/imscJS#73 , and results in no changes to IMSC1 tests other than those resulting from #310, #308 and #309,

Determining temporal activity

An element is temporally active during the left-wise closed interval:

  • starting with its desired begin; and
  • ending with:
    • its desired end if the element is a region element or the body element
    • the smallest of (a) the desired end of its parent and (b) its desired end

An element is never temporally active if either:

  • its desired begin and desired end are equal; or
  • its desired begin is larger than or equal to the desired end of its parent, if the element is neither a region element nor a body element

To determine the desired begin and end of each element, the [compute desired begin and end of an element] algorithm below is applied separately to all region elements, and the body element.

[compute desired begin and end of an element]

- let E be the element
- let S be the previous sibling of E, unless E is the first child of P
- let P be the parent of E, unless E is a <region> element or the <body> element

/* compute implicit begin of E */

- if E has no parent, then the implicit begin of E is 0
- if E has a parent, then the implicit begin of E is equal to:
    - the desired end of S, if S exists and P has _seq_ semantics
    - the desired begin of P, otherwise.
    
/* compute desired begin of E */

- the desired begin of E is equal to:
    - the implicit begin of E plus the explicit begin of E, if an explicit begin of E exists;
    - the implicit begin of E, otherwise.
    
/* compute implicit end of E */

- if E is a <region>, <br>, <set> or anonymous span, the implicit end of E is equal to:
    - the desired begin of E, if P exists and has _seq_ semantics
    - indefinite, otherwise
    
- otherwise, the [compute desired begin and end of an element] is applied to the children of E that are Content or Animation elements, and the implicit end of E is equal to:
    - its desired begin, if E has no children; or
    - the largest desired end of any of its children, if E has _par_ semantics
    - the desired end of its last child, if E has _seq_ semantics
        
/* compute desired end of E */

- if both an explicit duration and an explicit end of E exist, the desired end of E is equal to the smallest of: (a) the desired begin of E plus the explicit duration of E, and (b) the implicit begin of E plus the explicit end of E; or

- if the explicit duration of E exists but a explicit end of E does not exist, the desired end of E is equal to the desired begin of E plus the explicit duration of E; or

- if the explicit end of E exists but a explicit duration of E does not exist, the desired end of E is equal to the implicit begin of E plus the explicit end of E; or

- otherwise, the desired end of E is equal to the implicit end of E.

[Edited to replace "specified" by "explicit" to match SMIL terminology]

@palemieux palemieux self-assigned this Dec 28, 2017
@palemieux palemieux added this to the 3rd Ed milestone Dec 28, 2017
@skynavga
Copy link
Contributor

The only way I would be willing to accept this proposal is if someone were to prove without a doubt that it does not break any existing implementation, content, or the original intent of TTML to employ SMIL timing semantics.

@skynavga
Copy link
Contributor

I should add that this proposal clearly does not capture the original intent of TTML inasmuch as it elides critical semantics contained in SMIL3 Timing and Synchronization [1], Section 5.4.5, including (in part) the following sub-headings:

  • Resolving times
  • Defining the simple duration
  • Computing the active duration
  • Active duration algorithm
  • Time container duration
  • Time container constraints on child durations

[1] https://www.w3.org/TR/SMIL3/smil-timing.html

Any attempt to reformulate these semantics in a new algorithmic formalism would require adequate proof of equivalent behavior, which is not presented here if we are to seriously consider this as a plug-in replacement for SMIL.

@skynavga
Copy link
Contributor

If you want to publish this in an informative appendix as the documentation of a single implementation for further review and discussion for consideration in a future edition of TTML, then I would not oppose doing this (provided adequate cautions were added that this formalism may be wrong and remains unproven, etc.).

@palemieux
Copy link
Contributor Author

If you want to publish this in an informative appendix as the documentation of a single implementation
for further review and discussion for consideration in a future edition of TTML

Yes, that is exactly what I had in mind.

FYI. TTML1 references SMIL 2.1, not SMIL3.

@skynavga
Copy link
Contributor

ok, then maybe we can progress this proposal; also, we may want to update the SMIL reference to the same we use for TTML2, viz.,. SMIL3.0; especially, since SMIL3.0 was published in 2008 before TTML1 1st Edition became a REC in 2010;

@palemieux
Copy link
Contributor Author

@skynavga SMIL1 is vastly easier to read (see Section 4.2.4), and seems to cover all of TTML1's needs. Why was SMIL2 referenced instead?

@nigelmegitt
Copy link
Contributor

In discontinuous marker mode the begin and end events are derived using a completely different algorithm. That needs to be factored into this explanation somehow.

@palemieux palemieux modified the milestone: 3rd Ed CR Feb 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants