ChapterThumbnail

[hubblec4]

On most Blu-rays you don't have named chapters, but there is often a thumbnail for each chapter.

We could add a new element ChapterThumbnail within the ChapterAtom element.
The type is binary.

[robUx4]

That might make parsing chapters much slower by either reading the thumbnails or skipping them (slower on network and breaks the reading cache).

It may be handled as attachments with just the UID stored in the chapters. Some programs may not remux this properly.

Also pictures need more than a Binary storage, it needs also a MIME type. That logic is also found in attachments.

[hubblec4]

It may be handled as attachments with just the UID stored in the chapters. Some programs may not remux this properly.

This was my first thought, because attachments is a good choose to store binary files. (MIME Type is there and so on)
Then it would enough when the ChapterThumbnail element type is a boolean. If is set to true, a parser have to check the attachments.

[hubblec4]

An element of boolean in nonsense :-)
What is the best way?
The ChapterThumbnail element is a type of UInteger and holds an UID to an attachment.

The UID which is set in the ChapterThumbnail must be used by a file writer for the attachment.
I don't know if this is so easy possible?

[StefanBruens]

What about "timeline" or "index" thumbnails, i.e. thumbnails which are (more or less) evenly spaced in time?

For a proprietary approach, see e.g. https://support.plex.tv/articles/202197528-video-preview-thumbnails/

[hubblec4]

MPC-HC (from v.1.9.9) has now such a thumbnail video preview feature and I like it.

[robUx4]

Yes, the question is really where to store it. Either directly in the Chapters but that makes Chapters huge when most of the time all the player want is seek points. It's often read directly in memory for quick access. Here it requires special care to only keep the elements you want to read of not. You don't want to read a Binary element just to release it right after, you would want to skip right away.

A link to attachments would balance this by moving the big data in the Attachment part, which is meant for big binary data, and already handles all kinds of things like the MIME type. The downside of this approach is that if you remove the attachment part (to save space) the Chapters might be left pointing nowhere.

Another thing is that if you have multiple video tracks you need to know which track the thumbnail is generated from.

[hubblec4]

Since MPC-HC supports the thumbnail preview, there is actually no reason anymore for thumbnails in Matroska.
The thumbnail feature of MPC-HC works so great and is independent from any time stamp or other binary data.
All what you need is a fast PC with good CPU power.

The thumbnails for MultiAVCHD is only a time stamp, in the middle of a chapter. There is no other binary data.
A player reads this time stamp and preview the frame of this time stamp.
In this case a simple new element called ChapterThumbnailTime could be used.

But when we add the thumbnail feature it will be the best to store the binary data in the Attachment section, and a Chapter needs a new element to store the link to the Attachment.

ChapterThumbnailAttachmentUID or something like this.