-
Notifications
You must be signed in to change notification settings - Fork 16
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
Appendix N assumption that root temporal extent corresponds with the beginning of a related media object #76
Comments
(admin point: at the current time, Appendix N in TTML1 maps to Appendix H in TTML2) Having looked at this more, and after discussions, a couple of points need to be added - some but not all of this is restating other discussions elsewhere, for completeness here: Firstly, the definition of Root Temporal Extent affects the treatment of the statement. If it is taken that the default for
A use case for 1 above is when the document is one of a sequence of "live" TTML documents, where the sender cannot provide a reliable time coordinate that can be successfully compared to a clock at the receiver, and where the author wants to signal "display this as soon as you can, but not for longer than 5s after beginning". To support this use case (which for reference is present in EBU Tech3370) the active begin time needs to be resolved downstream, where the resolution for that begin provides a syncbase value. An example document with no timing on regions might have: <body dur="5s"> Then the effective begin value for the simple duration that everyone can agree has a 5 second duration is the document resolved begin time. Secondly, the document processing context might provide a syncbase and also a playback entry time. For example, a segmentation algorithm might result in a document like: <tt ttp:timeBase="media" ...>
<body>
<div>
<p begin="12345:00:00" ...>
... where the processing context defines that the segment begin time is actually the equivalent of |
On Mon, Aug 15, 2016 at 10:24 AM, Nigel Megitt notifications@github.com
Since one can't explicitly specify begin on tt, then it must always be
|
Thanks for picking me up on this - I need to be so careful with language. There seems to be scope in SMIL for making
I'm beginning to agree, to my frustration! I still think it is unclear that the We should probably be careful about the processing context providing syncbase vs epoch for clock times by the way, since they may not be coincident.
I think the problem I set out is orthogonal to any media offset, which can only move the content on the timeline. Effectively In practice other processing systems already include the semantics that define presentation begin and end. Attempting to duplicate that within the TTML documents makes those document instances less reusable and also may lead to a scenario where the two 'layers' disagree with each other, to nobody's benefit. We should not (IMO) introduce this possibility. |
On Wed, Aug 17, 2016 at 9:47 AM, Nigel Megitt notifications@github.com
I'm guessing you probably mean active duration here as well? Also, I It might be useful for you to review the code in TTX [1], to see a full Here, a TimingState (TS) object is created (and cached) for each timed
Derived timing state is available from the above as follows:
This sounds like either an event or interactive based timing model using
Here, the implicit duration of is 15s, not 10s, and this implicit N.B. Timing is resolved on the original tt source tree,and not the We should probably be careful about the processing context providing
|
@nigelmegitt what do we need to do here, given the removal of |
I've also raised #549 for removal of |
The Working Group just discussed
The full IRC log of that discussion<nigel> Topic: Appendix N assumption that root temporal extent corresponds with the beginning of a related media object ttml2#76<nigel> github: https://github.com//issues/76 <nigel> Glenn: We already decided not to include mediaOffset. <nigel> Nigel: Yes, also mediaDuration. <nigel> Glenn: pull #536 does that. <nigel> Nigel: I recall from TPAC that we agreed to remove mediaDuration alongside mediaOffset <nigel> .. as a pair. <nigel> Glenn: I don't recall that and would like to consider it in a separate issue. <nigel> .. Media Duration is needed to resolve indefinite end times. <nigel> Nigel: At TPAC we agreed that the clipEnd semantics could be used for that place instead. <nigel> Cyril: The pull request doesn't mention the issue. <nigel> Glenn: I restored the TTML1 text saying that an offset may be needed if the assumption <nigel> .. does not hold that the origin of media time corresponds to the begin time of a related media offset. <nigel> Nigel: This text has a problem in that it is only a subset of the full set of assumptions. <nigel> .. In fact the assumption more broadly is that the origin of the media time coordinates is <nigel> .. the same as the origin coordinates of the document instance. <nigel> .. I think I need to file an issue for this point. <nigel> Pierre: If we have disagreement over the informative text then the pragmatic approach is <nigel> .. to remove the text. <nigel> Glenn: We don't use the word origin or formally define epoch. <nigel> Nigel: I've raised #549 for removing mediaDuration. <nigel> .. And #550 about the media offset note. <nigel> SUMMARY: Resolve pull #486 and remove mediaOffset and mediaDuration. |
Remove ttp:mediaDuration (#549). Since we have a WG resolution to proceed on this, and since nobody is proposing to keep ttp:mediaDuration, I am merging this early to facilitate closing #76. If someone wishes to object to the WG resolution https://github.com/w3c/ttml2/issues/549#issuecomment-356695431, feel free to reopen #549 with specific comments.
Since #486 has been closed (deferred for future consideration), and since |
From Appendix N.2:
"The above formalisms assumes that the Root Temporal Extent corresponds with the beginning of a related media object. If this assumption doesn't hold, then an additional offset that accounts for the difference may be introduced when computing media time M."
In a streaming environment it is very likely, especially for live-created subtitles, that a set of TTML samples will be produced each with a different Root Temporal Extent that starts at a different point relative to a single Related Media Object (which may itself be packaged up into an independent set of samples). However I would not in general account for this with an offset and assume (or hope) that every sample's begin and end times are zero-based; rather I'd expect the begin of the TT to be coincident with the point within the Related Media Object at which that sample begins. As a side-effect this should reduce the complexity of the transformations needed to accumulate the [short] samples together to create a longer one.
For this reason I propose that we reverse this assumption.
(raised by Nigel Megitt on 2013-08-12)
From tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/270
The text was updated successfully, but these errors were encountered: