Discuss: Event Assets#2
Discuss: Event Assets#2LukasKalbertodt wants to merge 1 commit intodiscussions/event-assets/basefrom
Conversation
|
|
||
| Every asset has this metadata attached to it: | ||
| - `id: ID`: unique identifier among all assets of all events. Assigned by Opencast and unchangable. | ||
| - `flavor: NonBlankAsciiString` <sup>(1?)</sup> |
There was a problem hiding this comment.
This should be its own datatype. flavor has a specific syntax. I guess [0-9a-Z+-]/[0-9a-Z+-] is fine, but maybe some additional characters are used.
| Every asset has this metadata attached to it: | ||
| - `id: ID`: unique identifier among all assets of all events. Assigned by Opencast and unchangable. | ||
| - `flavor: NonBlankAsciiString` <sup>(1?)</sup> | ||
| - `tags: string[]` <sup>(1?)</sup> |
There was a problem hiding this comment.
But are there good reasons for non-UTF8 strings? Because for anything that's not binary data, I would really like to enforce UTF-8, see https://utf8everywhere.org/
There was a problem hiding this comment.
I meant that tags can be even further restricted to ASCII or so.
| - `id: ID`: unique identifier among all assets of all events. Assigned by Opencast and unchangable. | ||
| - `flavor: NonBlankAsciiString` <sup>(1?)</sup> | ||
| - `tags: string[]` <sup>(1?)</sup> | ||
| - `properties: Map<Label, string>`: a `Label` to string map for custom properties. Values can be arbitrary strings.<sup>(7?)</sup> |
There was a problem hiding this comment.
For simplicity, IMO string is enough. Applications can always convert.
| - `flavor: NonBlankAsciiString` <sup>(1?)</sup> | ||
| - `tags: string[]` <sup>(1?)</sup> | ||
| - `properties: Map<Label, string>`: a `Label` to string map for custom properties. Values can be arbitrary strings.<sup>(7?)</sup> | ||
| - `mimeType: NonBlankAsciiString`: a *lowercase* `NonBlankAsciiString` representing the MIME-type of the asset. |
| - `properties: Map<Label, string>`: a `Label` to string map for custom properties. Values can be arbitrary strings.<sup>(7?)</sup> | ||
| - `mimeType: NonBlankAsciiString`: a *lowercase* `NonBlankAsciiString` representing the MIME-type of the asset. | ||
| - `size: uint64`: size of the file in bytes. This is always the actual file size and cannot be changed manually. | ||
| - `checksum`: Checksum/hash of the file. Consists of `type` (e.g. `md5`, `sha256`) and the hex encoded value. In the API (and maybe in the database?) this should be serialized as `<type>:<value>`, e.g. `sha256:e3b0c44298f...`. |
There was a problem hiding this comment.
Do we want to allow multiple checksums? So an array?
| - `"caption"`: closed captions (*does* contain speaker names, sounds, or the like) | ||
| - `"chapters"`: chapter markers with title per chapter | ||
| - `"in-video-text"`<sup>(4?)</sup>: representing text in the video (e.g. slide text) | ||
| - `origin: "manual" | "generated" | null`: describes how this track was created, `manual` meaning it was human crafted, while `generated` means it was automatically generated. |
There was a problem hiding this comment.
Currently, this is called generator-type. Why rename?
| - `"audio"` | ||
| - `codec: "AAC" | "MP3" | "Opus" | ...`<sup>?</sup> | ||
| - `"text"`: | ||
| - `kind: string`: the kind of data this text track represents. |
There was a problem hiding this comment.
Currently, this is called type. Probably as generic as kind. So if we rename, find something better? disposition as called by FFmpeg?
|
|
||
| - `oc/thumbnail`: Thumbnail for the event, e.g. a preview image. | ||
| - `mimeType` must be `image/*` | ||
| - `properties` must include `w` and `h`, both holding numbers describing the width and height of the image. |
There was a problem hiding this comment.
I don't like the shorthand form. Why not width and hight?
| - (2?) Do we really need the `updated` field? | ||
| - (3?) What permissions should be required to read internal assets? Is `write` access to the event enough? And/or should a special role be required? | ||
| - (4?) Better name for this? `on-screen-text`? `text`? `video-text`? | ||
| - (5?) Is `isLive` per track really the correct model? Should this be attached to the event instead? Like, how would a Tobira or LMS decide whether to display an event as live or not? |
There was a problem hiding this comment.
In general, video systems backed by Opencast should use flavors / tags to select elements to play.
| - (6?) For timeline and segment previews, it is a bit unclear how to deal with dual stream videos. Right now, Opencast only generates these previews for one video (presentation) by default, I think? Is it useful to have previews for both? Then apps/the player need to support that. | ||
| - If we want to potentially show both, then the current `presenter/*` can stay. | ||
| - If we just want to have one preview per video, then it should be `oc/*`, as otherwise external apps have to arbitrarily chose one. |
There was a problem hiding this comment.
Again I tend to let people do what they want. IMO one preview image is enough, but maybe not for everyone.
| - (2?) Do we really need the `updated` field? | ||
| - (3?) What permissions should be required to read internal assets? Is `write` access to the event enough? And/or should a special role be required? | ||
| - (4?) Better name for this? `on-screen-text`? `text`? `video-text`? | ||
| - (5?) Is `isLive` per track really the correct model? Should this be attached to the event instead? Like, how would a Tobira or LMS decide whether to display an event as live or not? |
There was a problem hiding this comment.
@KatrinIhler wrote:
definitely don't mark each track as live, but event as a whole
3 participants
This discussion PR is for event assets.
To add new comments, go into the "files changed" tab and comment on individual lines or sections of lines. Or you can comment on existing discussion threads here. If you feel like you want to start a discussion about a broader topic (than something mainly referencing a few lines), consider open a new discussion here.