[Matroska-devel] Linking attachments to tracks

Moritz Bunkus moritz at bunkus.org
Tue Aug 30 13:26:50 CEST 2005


Hey,

a couple of days ago Steve and I had a heated discussion on IRC (ok, I
was heated, sorry for that). The situation: When putting files into
Matroska that contain embedded files, how should those embedded files be
treated?

Examples are SSA/ASS or USF subtitle files with embedded fonts and/or
pictures.

There are two possibilities:

1. Leave the embedded files as they are and put them into CodecPrivate,
2. Convert those embdedded files to Matroska attachments.

I think we all agree that 2. is the way to go as embedded files can be
huge, especially if they're Base 64 encoded in order to fit into a text
file.

But how can the demuxer know that attachment X belongs to track Y? At
the moment Matroska cannot store this link.

Now Steve and I have different approaches for this problem. I'll
describe mine and hope that Steve will describe his in a reply. I'd like
to introduce exactly one new element beneath the track headers. So let's
consider this track information and an attachment, let's call it
Verdana.ttf. At the moment they're stored like this:

Segment
+- Track
   +- Number: 1
   +- UID: 9182049865
   +- CodecID: S_TEXT/SSA
...
+- Attachments
   +- Attachment
      +- File UID: 761823125
      +- File name: Verdana.ttf
      +- MIME type: application/x-truetype-font

My proposal is to introduce an element called "AttachmentLink" beneath
"Track" that contains a "File UID" of an "Attachment". This would change
the previous example to this:

Segment
+- Track
   +- Number: 1
   +- UID: 9182049865
   +- CodecID: S_TEXT/SSA
   +- AttachmentLink: 761823125
...
+- Attachments
   +- Attachment
      +- File UID: 761823125
      +- File name: Verdana.ttf
      +- MIME type: application/x-truetype-font

That way the splitter would know that the attachment belongs to this
track and could re-encode it in Base64 and deliver it along with
CodecPrivate or however else the API/Codec needs it.

If there are more attachments belonging to this track then there will be
more than one AttachmentLink element.

The advantage is that this is simple and very, very easy to implement.
Of course you should not change the attachment file name because it
might be referred to from the subtitle contents. I think this is Steve's
biggest complaint with my idea. However, a user shouldn't change the
name of the attachment inside the SSA script either (and inside SSA the
embedded files are referenced via their (file) names). So if the user
already knows that he shouldn't change something like that, why bother?
It's the same for Matroska files.

Now Steve's proposal, please :)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20050830/50f517bf/attachment.pgp>


More information about the Matroska-devel mailing list