Matroska Image Format

[shmuelie]

I would like to propose that an extension to the codecs be made to include image/graphic formats, allowing the main content to be images. The extendibility of Matroska container would be extremely helpful for images, not just video and audio.

[robUx4]

You mean to hold a single image or add more common image codecs ?

[shmuelie]

The main request would be for a single image. Technically you can put them in as attachments right now but that's not the "main" content like video and audio are.

[JeromeMartinez]

What would be he advantage compared to the source format? i.e. a JPEG file in a Matroska file is not useful compared to a JPEG file directly?
I see image formats in Matroska more as a possibility for a video stream, e.g. like what already has MP4 (it can embed e.g. 1 JPEG image per video frame) or MXF (it can embed e.g. 1 JPEG 2000 image per video frame).
If we want a single image, well, it may be a video frame with a duration of infinite :).

[shmuelie]

Tha advantage of an image file in Matroska over just the image file would be getting the advantages of the Matroska container: arbitrary metadata and attachments. And while yes, I could "hack it" using something like an infinite video frame or a file with only an attachment I would like something more "official" than that 😅

[JeromeMartinez]

I personally see no problem to make explicit that max of the Segment\Info\Duration and \Segment\Tracks\TrackEntry\DefaultDuration value if (uint)-1 means still image, it would be compatible with previous specs and definition of \Segment\Tracks\TrackEntry\CodecID would be common to still images and video.

[shmuelie]

Hmmm, but the CodecID would still need to be updated to include the image's codec, no?

[JeromeMartinez]

Hmmm, but the CodecID would still need to be updated to include the image's codec, no?

But in a generic manner (same codec spec for video or image).

[shmuelie]

But in a generic manner (same codec spec for video or image).

Not sure I follow?

[robUx4]

I personally see no problem to make explicit that max of the Segment\Info\Duration and \Segment\Tracks\TrackEntry\DefaultDuration value if (uint)-1 means still image, it would be compatible with previous specs and definition of \Segment\Tracks\TrackEntry\CodecID would be common to still images and video.

None are mandatory so it's probably better to not use them at all. Given Duration is a float a NaN value could be used.

Every video codec (I know) would start with a RAP (Random Access Picture) so can be decoded on its own. It should not be a problem to use any video codec we support. The problem with this approach is that image viewers or even web browsers won't be expected to support all codecs we support. Unlike regular image formats that only have a single codec to support.

There's nothing wrong/impossible in defining a Matroska based picture format. But I'm not sure it fits the use case of regular image formats. This is the same reason there is no .mks to hold subtitles of any kind. Even though it's more likely for players that support subtitles to support Matroska too.

[shmuelie]

I totally agree there's no real technical issue here, and it's purely a "business" decision. I think it's be nice as it would mean getting all the advantages of Matroska (attachments and easy to define "random" metadata but for images.