[Matroska-devel] Linking attachments to tracks

Steve Lhomme steve.lhomme at free.fr
Tue Aug 30 15:24:35 CEST 2005


Moritz Bunkus a écrit :
> 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.

Well, it's also because originally they are external files needed for 
the use of the codec.

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

As said during the discussion, it's harder than what it seems. For 
example usually when referencing a font you don't use the file name but 
the font name.

> 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.

OK. Now I get the use of such a system. When remuxing a file and keeping 
only certain files, you know what attachments to keep. Previously I 
thought this information alone would serve no purpose.

> 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 :)

Me ?

My idea is that we *should* have the information that track X needs 
attachment Y. And that's what you propose. But As mentioned above for 
font, the filename won't really matter in the end anyway. In the case of 
the font it would be nicer to know the font name rather than the UID or 
filename. So my idea is that we need a second element, this time in the 
Attachment part :

+- Attachments
    +- Attachment
       +- File UID: 761823125
       +- File name: Verdana.ttf
       +- MIME type: application/x-truetype-font
       +- File Referer: "Verdana" (binary)

So that in the script you can use "Verdana" and know what attachement it 
corresponds to. In the case of an image, it can just be the original 
filename. Even if you change the actual name, the original remain.

Of course mkvmerge will probably not be able to retrieve the font name 
from a .ttf (would be nice ;) so this is just an hypothetical solution. 
It would also require support for the playback framework to make 
available the attachment to the codec on request of this Referer. So we 
don't have to do that now, but keep it in my for later...

Mosu's solution is sufficient for the current need. And mine is OK to be 
added later without breaking what we have now...

Steve




More information about the Matroska-devel mailing list