[NUT-devel] attachments

[Aurelien Jacobs]

Måns Rullgård wrote:

> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Wed, Jan 16, 2008 at 02:17:22PM +0100, Michael Niedermayer wrote:
> >> Hi
> >> 
> >> How are attachments (cd cover image, fonts for subtitles, ...) 
> >> supposed to be stored in nut?
> >> As i originally designed things, info packets should have been
> >> used. But after changes upon which some fanatically insisted info
> >> packets no longer are flexible enough. They are required to be
> >> repeated after every header and they can only apply to a single
> >> stream. Neither of these limitations was in the original design.
> >> 
> >> So for 10 subtitle streams, we would need a minimum of 30 copies of
> >> all fonts.
> >> 
> >> My original design could have stored a version of the font and
> >> still kept proper references so that it was known to the demuxer
> >> which streams the attachment applied to.
> >
> > </rant>
> >
> > i see many possible solutions.
> >
> > 1 just insist on seperate files
> 
> For fonts this makes the most sense, IMHO.  That is how they are
> normally installed on a system.  If fonts are to be embedded, they
> should be properly subsetted as in Postscript/PDF, not just pasted in
> lock, stock and barrel.

No one prevents you to subset fonts you embed in mkv/nut...
Problem with subsetting fonts arise when user try to fix a typo in
the subtitle stream, and suddenly, the new character he added can't
be displayed.

> I see little rationale for other suggested applications either,
> e.g. cover art.  Cover art normally belongs to an album, not
> individual songs,

Sure.

> and personally I'd much rather have a directory of
> files, one per album track, and a few JPEGs for cover art,

That's your choice. It seems some people prefer having a single
file per album, containing all the tracks (properly separated
as chapters) and cover arts.

> rather than embedding the covers in each track.  Not only would that
> waste space,

Here you ignore the fact that all the tracks can be in a single file.

> but normal image viewing applications would have trouble reading
> them too.

True. On the other hand, with separate files, an audio player
would have trouble finding the jpeg which are related to
the album (need to read the id3tags to guess whether tracks are
part of the same album, and try to find a jpeg which has a similar
name).

> As always, keeping things simple is probably the best solution.

I'm undecided on this issue. I'm sure separate files are perfect
in many situations, but I suppose attachments are better in some
situations.
What's nice with attachments is that you are not forced to use
them. You can still use separate files if you want.

Looking at this issue on a very different point of view:
Matroska supports attachments, and this feature is really used
and easy to find in the wild.
If nut ever gets in the light of the projectors, it will obviously
be compared to Matroska. And if nut don't support attachments
it will be considered inferior, at least in this respect.
I think the goal of nut was to make a generic container which
is better than any other generic container. Without attachments,
it won't ever reach this goal (at least in the eyes of many people).
So unless you want nut to stay a confidential container, I think
attachments is a must have.

Aurel