Add media zero timecode and start of programme timecode metadata #240

nigelmegitt · 2024-09-11T17:09:58Z

Closes #232.

Adds:

A metadata object called Media Zero Timecode
A metadata object called Start of Programme Timecode
An extension feature #mediaZeroTimecode, disposition Permitted
An example document fragment demonstrating the feature in use
An example algorithm for how to use the Media Zero Timecode and Start of Programme Timecode in practice to establish if the document is likely to be correctly synchronised with a related media object whose timings are timecode-based.

Would appreciate review comments from @ewanrsmith - I don't seem to be able to request a review from him.

Updated 2026-09-25 to remove the <legacy> object and add the Start of Programme Timecode object

Preview | Diff

mattsimpson3 · 2024-09-12T08:39:08Z

Makes sense to me.

mattsimpson3

Nothing to change from me...

mattsimpson3

Approved this time!

cconcolato · 2024-09-12T15:05:25Z

Why do we need a legacy element? Why don't we use an attribute like all the EBU-TT equivalent metadata?

css-meeting-bot · 2024-09-12T15:52:38Z

The Timed Text Working Group just discussed Add legacy metadata structure and media zero timecode metadata w3c/dapt#240, and agreed to the following:

SUMMARY: Review to continue

The full IRC log of that discussion

<nigel> Subtopic: Add legacy metadata structure and media zero timecode metadata #240
<nigel> github: https://github.com//pull/240
<nigel> Cyril: I added my comment already. Why add the legacy structure?
<nigel> .. Why make it an element not an attribute, e.g. on the tt element?
<nigel> Nigel: I wanted to provide a home for legacy conversion data, and to make it really clear that
<nigel> .. it isn't something that should carry any presentation semantics.
<nigel> .. We could do it the way you suggest, of course.
<nigel> .. I fear that people won't read the spec and putting the data here gives a really strong hint.
<nigel> Cyril: I think I raised the point in the past - it's not specific to DAPT, it could be a TTML thing.
<nigel> .. I understand that we need it in DAPT, but maybe we could define it in the TTML namespace, and transfer
<nigel> .. it into TTML2 later.
<atai> q+
<nigel> Nigel: I'm happy to consider other use cases, I actually don't know of any right now.
<nigel> ack at
<nigel> Andreas: I was present when we started the discussion but haven't followed the current solution of the issue.
<nigel> .. When we started I also had the feeling that it could have wider applicability than DAPT, and have other use cases,
<nigel> .. so would be better in another namespace, or aligned with the parent specification.
<nigel> .. Sorry for not fully reviewing what you have proposed here.
<nigel> .. What we have in EBU-TT, couldn't the same thing be expressed with what you propose here for DAPT?
<nigel> Nigel: I don't think so, happy to be shown otherwise.
<nigel> .. Need to close for time, please continue to review and discuss.
<nigel> .. Wonder how strong your feeling is about the data structure as proposed, Cyril?
<nigel> Cyril: I don't understand the point of the legacy metadata, why it's different from other conversion data.
<nigel> .. Also would like to see an informative reference to ESEF to explain it.
<nigel> SUMMARY: Review to continue

nigelmegitt · 2024-09-13T13:14:47Z

Why do we need a legacy element? Why don't we use an attribute like all the EBU-TT equivalent metadata?

@cconcolato The idea is to clearly mark out data that is not core to the content, and is definitely not expected to be required or processed for presentation, but is only needed to retain information that was part of the legacy source file, which may need to be resolved later. I'd happily add some descriptive text to try to explain this more. We could consider other names too.

Re EBU-TT metadata, which is in EBU-TT part M, Metadata Definitions, EBU Tech 3390, defines most of the entities as elements, not attributes: doing this means that if anyone needs to add some custom metadata they have the ability to add attributes to the element.

An alternative that you mentioned in yesterday's call is to define an attribute that would live on the root <tt> element. I think that would increase the likelihood that folk would get used to it being there, and consider it as somehow important for processing the document in all cases. It would certainly be possible to do it this way, but I have a strong preference for avoiding it.

cconcolato · 2024-09-14T01:02:32Z

The idea is to clearly mark out data that is not core to the content, and is definitely not expected to be required or processed for presentation,

That is already conveyed with the metadata signaling (qualified namespace on the attribute or when used on the element).

but is only needed to retain information that was part of the legacy source file, which may need to be resolved later. I'd happily add some descriptive text to try to explain this more. We could consider other names too.

This raises a lot of questions for me:

what is "legacy"? how do you define it? For example, would Netflix TTAL count as legacy format? Would you expect TTAL converted documents to be in the legacy element? The name does not matter much, it's the semantics that are required.
We have an example for adding vendor metadata in a metadata element, example 32. What's different here? We would need clear semantics as to what goes into legacy and what does not. I think it's calling for unnecessary complexity.
In which metadata element should this legacy go? I wouldn't want to have it in the same one as the ttm:agent elements that represent characters.

Re EBU-TT metadata, which is in EBU-TT part M, Metadata Definitions, EBU Tech 3390, defines most of the entities as elements, not attributes:

doing this means that if anyone needs to add some custom metadata they have the ability to add attributes to the element.

Understood, but ebuttm:documentStartOfProgramme which is similar is an attribute, not an element.

doing this means that if anyone needs to add some custom metadata they have the ability to add attributes to the element.

It could make sense for some structured vocabulary, but in this case where there is just one timecode value to carry, defining 2 elements is too complex.

An alternative that you mentioned in yesterday's call is to define an attribute that would live on the root <tt> element. I think that would increase the likelihood that folk would get used to it being there, and consider it as somehow important for processing the document in all cases. It would certainly be possible to do it this way, but I have a strong preference for avoiding it.

I don't understand why you think people would think it would be needed in all cases, if it is optional. It feels natural to me to have document-wide attributes be on the top-level element.

My strong preference is to have it as an attribute and not to introduce unnecessary elements. ebuttm:documentStartOfProgramme is on /tt/head/metadata, why not use it there? Alternatively, since it relates to the timeline of the document, we could have it on the body element.

cconcolato · 2024-09-14T01:09:48Z

Some additional comments:

the time of a Script Event whose Begin is zero seconds on the media timeline.

This gives the impression that there is always a Script Event at time 0. It should be rephrased to say things like 'hypothetical'.

One approach to resolving this conundrum

The word 'conundrum' seems too strong. It is a rather straightforward algorithm.

nigelmegitt · 2024-09-16T08:14:32Z

Some additional comments:

the time of a Script Event whose Begin is zero seconds on the media timeline.

This gives the impression that there is always a Script Event at time 0. It should be rephrased to say things like 'hypothetical'.

Good catch, thank you.

One approach to resolving this conundrum

The word 'conundrum' seems too strong. It is a rather straightforward algorithm.

It's a conundrum for the person converting the legacy (e.g. ESEF) files, who has no access to the data they apparently need.

nigelmegitt · 2024-09-16T09:09:26Z

Understood, but ebuttm:documentStartOfProgramme which is similar is an attribute, not an element.

That's not correct, it's an element.

doing this means that if anyone needs to add some custom metadata they have the ability to add attributes to the element.

It could make sense for some structured vocabulary, but in this case where there is just one timecode value to carry, defining 2 elements is too complex.

Right, one so far...

An alternative that you mentioned in yesterday's call is to define an attribute that would live on the root <tt> element. I think that would increase the likelihood that folk would get used to it being there, and consider it as somehow important for processing the document in all cases. It would certainly be possible to do it this way, but I have a strong preference for avoiding it.

I don't understand why you think people would think it would be needed in all cases, if it is optional. It feels natural to me to have document-wide attributes be on the top-level element.

Unfortunately I've seen plenty of misunderstandings and weird/unhelpful/not-as-intended documents from people who haven't taken the time to read the spec properly. I think the fear is reasonably well founded.

My strong preference is to have it as an attribute and not to introduce unnecessary elements. ebuttm:documentStartOfProgramme is on /tt/head/metadata, why not use it there? Alternatively, since it relates to the timeline of the document, we could have it on the body element.

Yes, we could put it there instead.

The idea is to clearly mark out data that is not core to the content, and is definitely not expected to be required or processed for presentation,

That is already conveyed with the metadata signaling (qualified namespace on the attribute or when used on the element).

Yes, to an extent, but again, my experience is that people look past namespaces.

but is only needed to retain information that was part of the legacy source file, which may need to be resolved later. I'd happily add some descriptive text to try to explain this more. We could consider other names too.

This raises a lot of questions for me:
* what is "legacy"? how do you define it? For example, would Netflix TTAL count as legacy format? Would you expect TTAL converted documents to be in the legacy element? The name does not matter much, it's the semantics that are required.

Since its metadata, this isn't so much about semantics as about guidance and real world usage. In my way of thinking, data should be put here if it is a) not otherwise needed/used/represented in DAPT, and b) still needed for some later purpose because of the workflow, or needed to support the transition to DAPT.

* We have an example for adding vendor metadata in a `metadata` element, example 32. What's different here? We would need clear semantics as to what goes into `legacy` and what does not. I think it's calling for unnecessary complexity.

Yes, we could omit this altogether and allow people to define and use their own custom data; the reason for trying to resolve this issue within the DAPT specification is because we expect it to be a widespread issue for people coming from ESEF in particular.

* In which `metadata` element should this legacy go? I wouldn't want to have it in the same one as the `ttm:agent` elements that represent characters.

OK, so you are in favour of organising the metadata in some way. Doesn't the addition of a legacy metadata child of <metadata> help with that? Why would you not want to use the same <metadata> element for multiple purposes? Most of the time I don't think TTML implementers even realise that it's possible to have more than one <metadata> child of the same parent element.

ewanrsmith · 2024-09-16T16:15:47Z

I think adding a legacy metadata element seems like a cleaner approach, given that it will function as a container for values that will only be meaningful in the context it represents:

mediaZeroTimecode would allow conversion from exchange formats timed using SMPTE timecodes into DAPT such that the synchronisation of the events is preserved relative to one another, but not to the start of the media. This assumes the absence of the ebutt:documentStartOfProgramme value (or equivalent) at the time of conversion, as otherwise the media time would have been set against it.
ebutt:documentStartOfProgramme would be added to a document that was converted based on mediaZeroTimecode and would provide an offset value based on the difference between the two fields. Its presence would also differentiate between documents for which the synchronisation has been validated and those for which it may be unclear.

Ordinarily my instinct would be to add them as attributes for the reasons Cyril suggests, but I think it makes sense to group them under an element that can dispensed with for natively originated documents. I think anyone dealing with legacy files in volume at the time of adoption would appreciate having these two values logically grouped together but separately.

cconcolato · 2024-09-19T16:24:40Z

Understood, but ebuttm:documentStartOfProgramme which is similar is an attribute, not an element.

That's not correct, it's an element.

I stand corrected. I guess it feels so unnatural to me to use elements for that that I persuaded myself it was an attribute ...

doing this means that if anyone needs to add some custom metadata they have the ability to add attributes to the element.

It could make sense for some structured vocabulary, but in this case where there is just one timecode value to carry, defining 2 elements is too complex.

Right, one so far...

I meant: one for legacy and one for mediaZeroTimecode vs. 0 for a 'mediaZeroTimecode' attribute.

This raises a lot of questions for me:
* what is "legacy"? how do you define it? For example, would Netflix TTAL count as legacy format? Would you expect TTAL converted documents to be in the legacy element? The name does not matter much, it's the semantics that are required.
Since its metadata, this isn't so much about semantics as about guidance and real world usage.

It does not feel sufficient to introduce an element and just provide guidance on how to use it without clear normative semantics.

In my way of thinking, data should be put here if it is a) not otherwise needed/used/represented in DAPT, and b) still needed for some later purpose because of the workflow, or needed to support the transition to DAPT.

I'd rather have a stricter set of rules, like do not put additional vocabulary anywhere except in the legacy element. Otherwise, an implementation will have to deal with both approaches ...

* We have an example for adding vendor metadata in a `metadata` element, example 32. What's different here? We would need clear semantics as to what goes into `legacy` and what does not. I think it's calling for unnecessary complexity.
Yes, we could omit this altogether and allow people to define and use their own custom data; the reason for trying to resolve this issue within the DAPT specification is because we expect it to be a widespread issue for people coming from ESEF in particular.

The use case of ESEF can be solved in many ways. If we provide a clear example, people will follow it. We could also go with strict semantics.

* In which `metadata` element should this legacy go? I wouldn't want to have it in the same one as the `ttm:agent` elements that represent characters.

OK, so you are in favour of organising the metadata in some way.

Yes, but I'd like implementations to be simple.

Doesn't the addition of a legacy metadata child of <metadata> help with that?

It would if a) it had clear, normative semantics to make it unambiguous for authors and simple to implement for parsers. and b) probably the name was changed, like external (meaning anything non-DAPT). But I'd still prefer tagging the metadata element to indicate the type of metadata.

Why would you not want to use the same <metadata> element for multiple purposes?

It seems easier to discard an entire metadata element than to check the type of every child element.

Most of the time I don't think TTML implementers even realise that it's possible to have more than one <metadata> child of the same parent element.

We already have a sentence that says:

For example, to refer to the first <metadata> element child of the <head> element child of the <tt> element, the following path would be used: /tt/head/metadata[0].

cconcolato · 2024-09-24T19:29:09Z

Should we mandate that there be at most 1 metadata in head and in script events?

nigelmegitt · 2024-09-24T23:42:08Z

I'm not sure I've ever seen a use case for multiple <metadata> element children of the same parent, I think it would be fine to restrict this.

nigelmegitt · 2024-09-25T06:47:41Z

Should we mandate that there be at most 1 metadata in head and in script events?

Raised as #242.

cconcolato · 2024-09-26T03:41:27Z

index.html

@@ -886,6 +886,152 @@ <h5>Timing Properties</h5>
            </p>
          </section>
        </section>
+
+        <section>
+          <h4>Deferred resolution of timecode-based synchronisation</h4>


Can we simply rename this section "timecode-related metadata"?

Also, I would prefer if this section, which is essentially about handling of metadata, would be grouped together with the existing section 5.2.3 (also about general metadata) in either a new top level section that deals with metadata generally, or even in an Annex.

I think it makes sense to move it to an appendix.

cconcolato · 2024-09-26T05:17:13Z

index.html

+          <p>In workflows that create <a>DAPT documents</a> by conversion from formats
+            that synchronise content using timecode to match time stamps
+            in the <a>related media object</a>,
+            a common issue occurs if the timecode of
+            the beginning of the media is not known at the time of conversion.
+          </p>
+          <p>The optional <a>Media Zero Timecode</a> and
+            <a>Start of Programme Timecode</a> properties can be used to
+            identify when there is a possible synchronisation error,
+            and to resynchronise the document when all
+            the required information is known.</p>
+          <p>These properties are provided as metadata only and
+            are not intended to be used to perform direct synchronisation offsets
+            during presentation.
+          </p>


I'm still trying to understand the feature here and how it differs from the existing EBU-TT feature.

Is the proposed text trying to say the following:

As defined in TTML2, each DAPT document has a timeline on which Script Events are positioned using their begin attributes. For synchronization purposes it is useful to map the DAPT document timeline with the related media object timeline.
In some cases, the mapping is simple, e.g. media time 0 in the related media object corresponds to the origin of the DAPT document timeline. In other cases, a timecode may be necessary. DAPT provides the ability to provide 2 different timecodes:

The "Start of the Programme Timecode" is the timecode of the time instant in the related media object corresponding to the origin of the DAPT document timeline. It is represented in a DAPT document by a documentStartOfProgramme element, defined in EBUT-TT, using the EBU-TT namespace, located in a metadata element in the head.

(and either one of the alternatives below)

The "Media Zero Timecode" is the timecode of the first media data in the related media object. It is represented in DAPT documents by the mediaZeroTimecode element, in the DAPT namespace, located in a metadata element in the head.

The "First Script Event Timecode" is the timecode of the time instant in the related media object corresponding to the first script event in the DAPT document. It is represented in DAPT documents by the XXX element, in the DAPT namespace, located in a metadata element in the head.

NOTE: Depending on the script and related media object workflows, there may not be a timecode in the related media object corresponding to the origin of the DAPT document timeline, for example if the related media object has been edited to remove some data at its start. In that case, either the "Start of the Programme Timecode" and all the Script Event begin times have to be edited, or alternatively the "Start of the Programme Timecode" cannot be used but the "First Script Event Timecode" or "Media Zero Timecode" can be used.

No, very much not that!

Start of programme timecode is the timecode in the related media corresponding to the beginning of the related media object's programme content.

Media Zero timecode is a timecode that media time zero in the DAPT document maps to.

If the DAPT document is not synchronised to the related media object's programme content, those two values will differ.

If the start of programme timecode is unknown, then you don't know if they're in sync or not.

If both are present and the same, then you have some reassurance that the DAPT document is synchronised with the media.

the timecode of the time instant in the related media object corresponding to the origin of the DAPT document timeline

The issue is that documents that are not synchronised to the related media object do not satisfy the "corresponding to the origin of the DAPT document timeline" part of this sentence.

nigelmegitt · 2024-09-26T22:05:43Z

In discussion with @cconcolato we realised that Media Zero Timecode was confusing, since it wasn't obvious which media was meant - it needs to mean "media timebase in the DAPT document" not "timecode at the beginning of the media". Changed to "DAPT Origin Timecode" in ed1f5de.

cconcolato · 2024-09-27T19:04:01Z

index.html

+    <p><a>DAPT Documents</a> express time as <em>media time</em>,
+      which assumes that there is a reference start time (zero) on a media
+      timeline, and a fixed playrate.
+      An alternative scheme that is used in some workflows is to


I think the wording is ambiguous. Some workflows that use DAPT? No, I think it is meant to say: "used for some other script formats than DAPT"

cconcolato · 2024-09-27T19:05:32Z

index.html

+      timeline, and a fixed playrate.
+      An alternative scheme that is used in some workflows is to
+      synchronise media components using timecode,
+      time stamps that are applied, for example to each frame of video.


Is "time stamps that are applied" intended? It feels like left over text. Suggest delete it.

Suggested change

time stamps that are applied, for example to each frame of video.

for example to each frame of video.

cconcolato · 2024-09-27T19:06:20Z

index.html

+      time stamps that are applied, for example to each frame of video.
+    </p>
+    <p>Workflows that create <a>DAPT documents</a> from
+      resources that use timecode need to map the timecode


"resources" can be confused with media resources (MPEG-2 TS, ProRes, ...) that can still use timecodes.

Suggested change

resources that use timecode need to map the timecode

script formats other than DAPT that use timecode need to map the timecode

cconcolato · 2024-09-27T19:09:30Z

index.html

+    <p>If this mapping is not correct, presentation of the
+      <a>DAPT Document</a> will not be synchronised with the <a>related media object</a>.
+      In order to achieve correct synchronisation in this scenario,
+      the timecode corresponding to the start of the programme needs to be known.</p>


the timecode corresponding to the start of the programme needs to be known.

This is too strong. Having one timecode is sufficient. It could be the first content timecode.

Suggested change

the timecode corresponding to the start of the programme needs to be known.

a timecode, such as the one corresponding to the start of the programme, needs to be known.

cconcolato · 2024-09-27T19:10:53Z

index.html

+    <p>If the start of programme timecode is not known,
+      but timecodes corresponding to <a>Script Events</a> are known,
+      it is still possible to construct a <a>DAPT Document</a>,
+      albeit one whose synchronisation with the related media is uncertain.</p>


What do you expect the person reading "uncertain" to understand?

cconcolato · 2024-09-27T19:13:59Z

index.html

+    <p>These properties are provided as metadata only and
+      are not intended to be used to perform direct synchronisation offsets
+      during presentation.</p>


We should add:
In particular, when the related media object uses timecode, the presence of the timecode properties does not mean that the player needs to relate these timecode values with any timecode value embedded in the related media resource.

cconcolato · 2024-09-27T19:21:27Z

index.html

+    <p>The optional <a>DAPT Origin Timecode</a> and
+      <a>Start of Programme Timecode</a> properties can be used to
+      identify when there is a possible synchronisation error,
+      and to resynchronise the document when all
+      the required information is known.</p>


If my understanding is correct I would suggest replacing with the following text

The properties can be used to provide timecodes from the related media object or from any other script format used to produce the DAPT document, and are informational. However, when they are both provided and differ, it is an indication that the DAPT document is not synchronized with the related media object and that processing of the script event begins is needed. To achieve synchronization, the following needs to be done:

The difference DAPT Origin Timecode minus the Start of Programme Timecode is computed as "delta". It may be positive or negative.

Each Script begin value X shall be changed to X + delta.

The DAPT Origin Timecode shall be removed or changed to the Start of Programme timecode value.

cconcolato · 2024-09-27T19:22:34Z

index.html

+    <section>
+      <h5>DAPT Origin Timecode</h5>
+      <p>The optional <dfn>DAPT Origin Timecode</dfn> allows a timecode value to be declared
+        that corresponds to the zero point on the media timeline,


Suggested change

that corresponds to the zero point on the media timeline,

that corresponds to the zero point of the DAPT document timeline,

cconcolato · 2024-09-27T19:22:59Z

index.html

+      <p>The optional <dfn>DAPT Origin Timecode</dfn> allows a timecode value to be declared
+        that corresponds to the zero point on the media timeline,
+        that is, the time of a hypothetical <a>Script Event</a> whose <a>Begin</a> is
+        zero seconds on the media timeline.</p>


Suggested change

zero seconds on the media timeline.

zero seconds.

cconcolato · 2024-09-27T19:25:29Z

index.html

+      <p class="note">See also <a href="#ttp-framerate"></a>.
+        No mechanism is defined here for declaring a different frame rate for the <a>DAPT Origin Timecode</a>
+        than is used for other frame-based time expressions.
+      </p>


Suggested change





If the related media object contains a timecode for the video frame synchronized to the origin of the DAPT document timeline, the DAPT origin timecode shall be equal that timecode.

cconcolato

Approving it technically, may need to do some editorial changes during CR phase.

* Rename the "Legacy Metadata" section to "Deferred resolution of timecode-based synchronisation" * Remove the Legacy Metadata object - the relevant metadata can be put directly into the `tt/head/metadata` element. * Add `ebuttm:documentStartOfProgramme` as "Start of Programme Timecode" * Explain how, by looking at both properties, it is possible to infer whether correct synchronisation has been achieved, and if not, how to resolve it. * Note that this incorrect frame rates or playback rates are not addressed by this method. * Add `ebuttm` namespace prefix.

It was confusing which "media" was meant by Media Zero Timecode.

nigelmegitt requested review from cconcolato, andreastai and mattsimpson3 September 11, 2024 17:09

nigelmegitt mentioned this pull request Sep 11, 2024

Required metadata field for earliest SMPTE time code to allow conversion between DAPT and ESEF #232

Closed

mattsimpson3 reviewed Sep 12, 2024

View reviewed changes

mattsimpson3 self-requested a review September 12, 2024 08:46

mattsimpson3 approved these changes Sep 12, 2024

View reviewed changes

nigelmegitt force-pushed the issue-0232-legacy-smpte-timecode-metadata branch from 9a39f10 to b61c349 Compare September 19, 2024 13:35

nigelmegitt mentioned this pull request Sep 25, 2024

Mandate that there be at most 1 metadata in head and in script events #242

Open

nigelmegitt changed the title ~~Add legacy metadata structure and media zero timecode metadata~~ Add media zero timecode and start of programme timecode metadata Sep 25, 2024

cconcolato reviewed Sep 26, 2024

View reviewed changes

cconcolato reviewed Sep 27, 2024

View reviewed changes

cconcolato approved these changes Sep 28, 2024

View reviewed changes

nigelmegitt added 3 commits September 27, 2024 17:15

Add Legacy Metadata and Media Zero Timecode

da2ec94

Add #mediaZeroTimecode permitted extension feature

1f8940b

Add a usage example for Media Zero Timecode

164c30b

nigelmegitt added 7 commits September 27, 2024 17:15

Adjust Media Zero Timecode after synchronising with media

942820c

Move timecode metadata section to appendix, and rename

ae59b5c

Rename Media Zero Timecode to DAPT Origin Timecode

af031bf

It was confusing which "media" was meant by Media Zero Timecode.

Address verbal review feedback

59065b6

Attempt to make the timecode wording easier to read.

9a608b5

Address further feedback

c1401ee

nigelmegitt force-pushed the issue-0232-legacy-smpte-timecode-metadata branch from 76243e2 to c1401ee Compare September 28, 2024 00:15

nigelmegitt merged commit 685f0e9 into main Sep 28, 2024
2 checks passed

nigelmegitt deleted the issue-0232-legacy-smpte-timecode-metadata branch September 28, 2024 00:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add media zero timecode and start of programme timecode metadata #240

Add media zero timecode and start of programme timecode metadata #240

nigelmegitt commented Sep 11, 2024 •

edited by pr-preview bot

Loading

mattsimpson3 commented Sep 12, 2024

mattsimpson3 left a comment

mattsimpson3 left a comment

cconcolato commented Sep 12, 2024

css-meeting-bot commented Sep 12, 2024

nigelmegitt commented Sep 13, 2024

cconcolato commented Sep 14, 2024 •

edited

Loading

cconcolato commented Sep 14, 2024

nigelmegitt commented Sep 16, 2024

nigelmegitt commented Sep 16, 2024

ewanrsmith commented Sep 16, 2024

cconcolato commented Sep 19, 2024

cconcolato commented Sep 24, 2024 •

edited

Loading

nigelmegitt commented Sep 24, 2024

nigelmegitt commented Sep 25, 2024

cconcolato Sep 26, 2024

cconcolato Sep 26, 2024

nigelmegitt Sep 26, 2024

cconcolato Sep 26, 2024

nigelmegitt Sep 26, 2024

nigelmegitt Sep 26, 2024

nigelmegitt commented Sep 26, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato Sep 27, 2024

cconcolato left a comment

	time stamps that are applied, for example to each frame of video.
	for example to each frame of video.

	resources that use timecode need to map the timecode
	script formats other than DAPT that use timecode need to map the timecode

	the timecode corresponding to the start of the programme needs to be known.</p>
	a timecode, such as the one corresponding to the start of the programme, needs to be known.</p>

	that corresponds to the zero point on the media timeline,
	that corresponds to the zero point of the DAPT document timeline,

-      </p>
+      </p>
+      <p>If the related media object contains a timecode for the video frame synchronized to the origin of the DAPT document timeline, the DAPT origin timecode shall be equal that timecode.
+      </p>

Add media zero timecode and start of programme timecode metadata #240

Add media zero timecode and start of programme timecode metadata #240

Conversation

nigelmegitt commented Sep 11, 2024 • edited by pr-preview bot Loading

mattsimpson3 commented Sep 12, 2024

mattsimpson3 left a comment

Choose a reason for hiding this comment

mattsimpson3 left a comment

Choose a reason for hiding this comment

cconcolato commented Sep 12, 2024

css-meeting-bot commented Sep 12, 2024

nigelmegitt commented Sep 13, 2024

cconcolato commented Sep 14, 2024 • edited Loading

cconcolato commented Sep 14, 2024

nigelmegitt commented Sep 16, 2024

nigelmegitt commented Sep 16, 2024

ewanrsmith commented Sep 16, 2024

cconcolato commented Sep 19, 2024

cconcolato commented Sep 24, 2024 • edited Loading

nigelmegitt commented Sep 24, 2024

nigelmegitt commented Sep 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nigelmegitt commented Sep 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cconcolato left a comment

Choose a reason for hiding this comment

nigelmegitt commented Sep 11, 2024 •

edited by pr-preview bot

Loading

cconcolato commented Sep 14, 2024 •

edited

Loading

cconcolato commented Sep 24, 2024 •

edited

Loading