Add ttm:mediaTimestamp (or equivalent) attribute

[plehegar]

Define ttm:mediaTimestamp attribute (or equivalent) to allow author to explicitly associate a related 'begin' time in the document's time space with a specific timestamp in a related media object's time space. For precedent, see [1] for definition of X-TIMESTAMP-MAP.

[1] https://tools.ietf.org/html/draft-pantos-http-live-streaming-14

(raised by Glenn Adams on 2015-01-01) From tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/361

[skynavga]

Already addressed by prior addition of ttp:mediaOffset.

[nigelmegitt]

Reopening: we have not added ttp:mediaOffset and when discussing it on multiple occasions I have raised an objection in advance to adding it on the grounds that it will create confusion where TTML documents are used or referenced in wrapper formats that already provide this functionality, such as ISOBMFF, and add a further unwelcome degree of complexity when processing time expressions in TTML. I also do not believe that a media offset would be an equivalent.

To reiterate previous discussions, I would instead like to see something that defines the playback entry point in the document's time space; it is a trivial extension to specify a cross-map between any time in the playback media timeline and any time in the document's time space. This is semantically much more useful than something that can potentially send some document times into negative values.

[skynavga]

ttp:mediaOffset is already present in the spec, and has been for at least 6 months or more

[skynavga]

Closing this again. You can file a new issue to remove ttp:mediaOffset if needed. BTW, I completely disagree with your claim about causing confusion if wrapper formats support this information. There are literally dozens of features in TTML you could make this claim against, and it is and has never been sufficient reason to not support internal specification of information.

[nigelmegitt]

I am puzzled as to why on one particular browser instance I was not seeing ttp:mediaOffset - on another I can now see that it is present. I will raise a separate issue.

[palemieux]

@skynavga Multiple members have consistently objected to ttp:mediaOffset (as recently as December 2016), so the editor's apparent unilateral decision to add it 6 months ago is not a particularly meaningful data point. At the very least, this should be added as a feature that can be prohibited by profiles.

[skynavga]

Sure, we can add a feature that facilitates profiling. Also, it appears that ttp:mediaOffset has been in the spec since before 10/29/2015, when we switched to github. So this was not a recent change.

[css-meeting-bot]

The Working Group just discussed Add ttm:mediaTimestamp (or equivalent) attribute #125, and agreed to the following resolutions:

• RESOLUTION: Remove ttp:mediaOffset as it stands and open a new issue to explain how to resolve media time
• RESOLUTION: Remove ttp:mediaDuration

The full IRC log of that discussion

<nigel> Topic: Add ttm:mediaTimestamp (or equivalent) attribute #125
<nigel> github: https://github.com/w3c/ttml2/issues/125
<nigel> nigel: We had two objections to the presence of ttp:mediaOffset but it remains in the
<nigel> .. specification. We need to resolve this before moving to CR.
<nigel> glenn: It wasn't a recent unilateral decision. I'm not sure when.
<nigel> archaeologist: tracker issue 335 and 361, raised by Courtney Kennedy and Glenn Adams respectively
<nigel> pal: My objection still stands.
<nigel> .. This arose from a mistake. People try to reproduce a timecode based workflow.
<nigel> .. That timecode may be 01:00:00 for the beginning, or 10:00:00, not realising that you
<nigel> .. don't have to do that in TTML and that it's wrong. What goes in TTML is a time offset.
<nigel> .. It is not 1 hour from the start of the video.
<nigel> .. So the idea of negative time offsets, to offset all the TTML files by -1 hour rather than
<nigel> .. rewriting the timestamps arises.
<nigel> glenn: You're right that being able to specify mediaOffset was intended to normalise
<nigel> .. documents that use that convention, for example documents that begin at 10 hours
<nigel> .. and you think that's the media time, then putting that offset in would reset it to zero.
<nigel> pal: My point is that's bad and we shouldn't encourage it.
<nigel> nigel: Mine is that it is actively dangerous.
<nigel> pal: Right, they should use media timebase.
<nigel> nigel: I also object because it has no practical effect - in the case of smpte discontinuous
<nigel> .. then it does not even apply.
<nigel> glenn: Even if we don't define this I want to do a better job of defining the relationship
<nigel> .. between the root temporal extent and the media time.
<nigel> atai: It could be metadata to say when the beginning timecode of the related programme is.
<nigel> nigel: The document interchange context like an MP4 wrapper already defines this.
<nigel> flick: Take 2 documents to wrap in an MP4 document. It should not matter if each is zero based.
<nigel> cyril: No the time begins at the beginning of the first sample.
<nigel> pal: In Part 30 for TTML the media timeline begins at the beginning of the track.
<nigel> .. In IMF it is the other way around.
<nigel> .. Each thing is independent and starts at zero in that case.
<nigel> atai: So the zero sync point is different in the related media.
<nigel> glenn: So you partly want to encourage authoring content that is zero based and can
<nigel> .. potentially be shifted around dependent on some external relationship.
<nigel> pal: When you author, you get some video content and you position your events relative to
<nigel> .. zero being the first frame of the related video content.
<nigel> smpte: In SMPTE continuous then 00:00:00:00 is the first frame, right.
<nigel> s/smpte/glenn
<nigel> .. For documents beginnins at 10:00:00 now you could support that externally in the processing
<nigel> .. context if it has different information.
<nigel> pal: Yes, for files I've seen they were wrong not only because they begin at 10:00:00:00 but
<nigel> .. also they have the wrong frame rate.
<nigel> glenn: I think we need to support taking advantage of external media and if they want
<nigel> .. relative times for presentation that is not 10:00:00:00 that is not handled externally.
<nigel> glenn: We don't dictate authorial behaviour in profiles.
<nigel> atai: It is not just a question of behaviour but also of workflows.
<nigel> .. Pierre, this relation between time based media and the related media time base. Do you
<nigel> .. think that the relationship between the time in the document and the time in the media
<nigel> .. is completely defined by the interchange context or there's no rule?
<nigel> pal: Absolutely, I've seen lots of different examples.
<nigel> nigel: One of my other objections is that DASH already has PresentationTimeOffset, and
<nigel> .. I think this mediaOffset value will be extracted and copied into that field and then
<nigel> .. wrongly applied twice, which is really dangerous.
<nigel> cyril: +1
<nigel> glenn: So in an interchange context that does not specify this do we need to define this?
<nigel> cyril: No
<nigel> nigel: No
<nigel> glenn: This came from TTML1 N.2: " If this assumption doesn't hold, then an additional offset that accounts for the difference may be introduced when computing media time M."
<nigel> .. When we wrote this into TTML1 we didn't go into this in a great deal of detail at the time.
<nigel> .. It implies the existence of some offset and I viewed that as a potential ambiguity in the spec
<nigel> .. that needs to be resolved in TTML2, which is why I defined it. If we don't define it then
<nigel> .. we need to figure out what to do with that text in TTML1 and put something in TTML2
<nigel> .. that talks about the document processing context as needing to resolve this issue.
<nigel> atai: Can we resolve to remove ttp:mediaOffset as it stands and as a separate issue add some guiding text?
<nigel> glenn: Okay I can do that, as long as we try to resolve the ambiguity. It will probably
<nigel> .. need a change in TTML1 Third Edition too.
<nigel> RESOLUTION: Remove ttp:mediaOffset as it stands and open a new issue to explain how to resolve media time
<nigel> flick: Do mediaOffset and mediaDuration travel as a pair?
<nigel> glenn: That was my intention
<nigel> flick: Then we should remove that too.
<nigel> glenn: I suppose clipEnd could fulfil the same purpose.
<nigel> .. I need to convince myself that the names clipBegin and clipEnd are appropriate.
<nigel> .. So our basic assumption is that time zero is the beginning of the document timeline?
<nigel> pal: Yes, there is always an ISD that goes from zero to ...
<nigel> nigel: I think the concept of an empty ISD should exist but I think empty ISDs would get pruned by the current algorithms.
<nigel> RESOLUTION: Remove ttp:mediaDuration
<nigel> glenn: This has to be tied together with clipBegin and clipEnd because we need a way to determine the end of the document.
<nigel> .. If you have a test process whose goal is to produce a set of ISDs then unless you have a fixed
<nigel> .. duration that you can resolve that to you might end up with different results in the case
<nigel> .. of showBackground="always" because there would be some ISD from the last time to
<nigel> .. infinity that needs to be covered.