Event duration

[LukasKalbertodt]

This has been passionately discussed before, see "previous discussions" at the bottom.

The core of the discussion is how an event should store its duration and how it should be restricted. A few things I think we all agree on:

• Each track and/or stream has a duration.
• That track/stream duration is exactly how long it takes to "watch" it; it's what your local video player app would show; it's not necessarily related to scheduled start and end times.
• An event/mediapackage can contain multiple tracks/streams with different lengths. For example, ingested and cut video have different lengths.

Opinions diverge on whether events should have a single semantic top-level duration. Note that this is about semantics and not about implementation detail. The question is basically: is there a clear and single answer to the question "How long does it take to watch event XYZ at 1x speed?" That duration might be stored as metadata field or might be derived from a track that is somehow marked as "main track", but again the implementation detail is secondary here.

Previous discussions:

• Discuss: remaining topics #3 (comment)
• Discuss: Event Assets #2 (comment)
• Discuss: Event Metadata #1 (comment)
• 2025-06-05

[LukasKalbertodt]

(To keep the top level comment neutral, I put my personal take in this comment)

I am strongly in favor of having a single semantic duration for each event. I want to have a single clear answer to "How long does it take to watch event XYZ?" as I think it's better for UX and makes code simpler. Yes, that event might have a number of other tracks that were later cut, but there is a single video track that is the main one for that video and that's the duration of the video.

Imagine Tobira or an LMS wanting to show an overview over videos of a series (take a conference recording). For a user it's very beneficial to already see the duration of each video, i.e. how long the user would spend watching it. I think we are all in agreement here?

If there wasn't a single duration for every video, what would a Tobira or LMS show in that case? It makes the UI more complex and confuses the user: "I thought this is one video, why does it have multiple durations?". An example was brought up in the discussion about having short clips of the video in the same mediapackage and those clips would also be "public" and could be watched by the user. I'd strongly argue that this should be multiple "events" then. Yes, we can make our mediapackage all-mighty, why not have multiple descriptions for each of those sub clips as well? But I don't think we should, as it adds lots of complexity for super rare extra cases and there are solutions in OC already (just have multiple videos, maybe in a playlist). Stick to the simple model users already know from YouTube: one "video/event", one ID, one watchable experience with one duration.

[mtneug]

I discussed this passionately the last time this came up again from a point of view to not overly restrict the data model and only introduce restrictions higher up the stack.

@LukasKalbertodt reading the top level comment and your opinion afterwards, I don't think I'm too far of. For me, some of the (implementation) details matter; allow me to touch on that a little bit.

---

What I strongly care about

No enforced requirement that all tracks of an event should have the same duration

Reading point three from the top level comment, this somehow now is something we agree upon. Last time, this was highly debated as the wording from the PRs, at least for me, implied that this would not be the case. Maybe with a distinction between "internal" and "non-internal" tracks, which I find hard to think about at the data model layer as I still want to be in control about what is considered published or not.

Duration for each track/stream is stored and can be retrieved

Basically the more detailed question "How long does it take to watch track ABC from event XYZ at 1x speed?", i.e. the duration is a property of a track/stream. I guess/hope this is not too controversial?

---

What I somewhat care about

The semantic duration of an event is application-specific (application = Tobira, LMS, etc.)

This touches on the implementation side of things. @LukasKalbertodt, you agreed that one implementation might be to derive the duration of an event from the main track duration. My point is that we should not enforce what constitutes the main track. Last time I tried to argue that the application, e.g. Tobira, makes a very deliberate decision what published track should be played back in the player, e.g. presenter/delivery when using the current default flavor names. Therefore, the application should use the duration of this particular track as event duration. Now with multi-track recordings this might be ambiguous, but the selected tracks usually have the same duration. Crucially, another application should be free to choose another track as main track and thus use this track's duration for the event. I therefore considered it wrong for the application to derive the duration of the event from any other place than from the selected tracks.

Again, this comes from a similar concern: keep the data model open and store durations at a granular level with each track/stream; leave restrictions to the frontend / application.

---

What I don't really care about

In addition to the durations for each track/stream there is a duration metadata field

This is the situation we have right now. In my view, the duration metadata field is only bibliographically. In particular, it is not the answer to the question "How long does it take to watch event XYZ at 1x speed?". This is maybe helpful for the lecture recording use case, i.e. basically the event duration as in calendar even duration. Personally, I don't really care for this metadata field. We can keep it around if UIs find this useful. The calendar even duration could also be derived from recording start and end times. Now, I understand this can be confusing to API users and agree that the future structure of the data model should make it very clear that this is the bibliographically duration.