"m.caption": { // optional - goes above/below video
"width": 1280,
"m.markup": [{"body": "Look at this cool animated Matrix logo"}]
"height": 720,
"duration": 90000 // milliseconds
}
}
}
}
}
}
```
```
All details shown above except `m.video` in the content are inherited from [MSC3551](https://github.com/matrix-org/matrix-doc/pull/3551) and [MSC3552](https://github.com/matrix-org/matrix-doc/pull/3552).
The newly introduced blocks are:
`m.video` is simply a container for the video-specific metadata that is not already covered by other MSCs.
Note that the event does not have an `m.image` - clients should use the first image-like thumbnail as a poster
for the video. It is reasonable for a client to include a lower quality copy (eg: 480p) as a thumbnail in the
event.
Note that videos can be encrypted using the same approach as `m.file`.
* `m.video_details` - Similar to `m.image_details` from MSC3552, optional information about the video.
`width` and `height` are required, while `duration` (length in seconds of the video) is optional.
## Potential issues
Together with content blocks from other proposals, an `m.video` is described as:
The schema duplicates some of the information into the text fallback, though this is unavoidable.
* **Required** - An `m.markup` block to act as a fallback for clients which can't process videos.
* **Required** - An `m.file` block to contain the video itself. Clients use this to show the video.
* **Optional** - An `m.video_details` block to describe any video-specific metadata, such as dimensions.
Like with existing `m.room.message` events today, clients should keep videos within a set of
reasonable bounds, regardless of sender-supplied values. For example, keeping videos at a minimum
size and within a maximum size.
* **Optional** - An `m.thumbnail` block (array) to describe "poster images" for the video.
* **Optional** - An `m.caption` block to represent any text that should be shown above or below the
video. Currently this MSC does not describe a way to pick whether the text goes above or below,
leaving this as an implementation detail. A future MSC may investigate ways of representing this,
if needed.
## Alternatives
The above describes the minimum requirements for sending an `m.video` event. Senders can add additional
blocks, however as per the extensible events system, receivers which understand video events should not
honour them. Such examples might include an `m.audio` block for "audio-only" mode (podcasts, etc) or
an `m.image` to represent the video as a GIF (or similar).
No significant alternatives known.
Note that `m.file` supports encryption and therefore it's possible to encrypt thumbnails and videos
too.
## Security considerations
If a client does not support rendering videos inline, the client would instead typically represent
the event as a plain file upload, then fall further back to a plain text message. An image fallback
is not neccessarily possible, despite all the required blocks being possible. This is due to the file
having a video mimetype, hopefully indicating to the client that an `<img />` (or similar) is not
appropriate for this event.
The same considerations which currently apply to files, videos, and extensible events also apply here.
## Potential issues
## Transition
The schema duplicates some of the information into the text fallback, though this is unavoidable
and intentional for fallback considerations.
The same transition introduced by extensible events is also applied here:
Travis Ralston
3 years ago