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. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
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 2 add n special info packets before the actual one containing the font each pointing to another subtitle stream and a "ContentInNextPacket" entry 3 like above but put these packets after the one with the content 1 is inconvenient for some types of attachments (like cd covers ...) also it doesnt solve the O(n*m) issue. Of cours solving the O(n) issue does mean less redundancy, but then loosing the cd cover or even the fonts is better than loosing the main headers ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
Michael Niedermayer wrote: [attachments] I'd use application streams and info packets referencing them. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Wed, Jan 16, 2008 at 03:03:42PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote: [attachments]
I'd use application streams and info packets referencing them.
if you use streams then with the current spec you have a minimum of 3 copies of the fonts [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
Michael Niedermayer wrote:
On Wed, Jan 16, 2008 at 03:03:42PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote: [attachments]
I'd use application streams and info packets referencing them.
if you use streams then with the current spec you have a minimum of 3 copies of the fonts
why? I don't have 3x the frames in the video stream O_o? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi On Wed, Jan 16, 2008 at 03:58:32PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote:
On Wed, Jan 16, 2008 at 03:03:42PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote: [attachments]
I'd use application streams and info packets referencing them.
if you use streams then with the current spec you have a minimum of 3 copies of the fonts
why? I don't have 3x the frames in the video stream O_o?
as rich already said the header repeation rule ... the extradata is in the stream header ... If you would use normal packets instead of extradata it might disapear if the file is split. Also Normal packets would need to be muxed before the streams using them. And even if thats done they might not be available during decoder init (which might happen before demuxing any packets) The spliting problem could be dealt with by making the single frame have a duration equal to the whole movie. Now no matter if extradata or normal packet, this will cause problems with seeking. As this is not a normal stream with frames one can seek to. Either we would need to consider the duration of frames (thats a thing we apparently ignored entirely) or ignore such attachment streams for seeking and back ptr calculation. So its probably possible to put it in streams, but its not clear if this is the best solution. If extradata is used we need * a special case for seeking/backptrs * a change to the header repeating rule If a normal packet is used we need * a special case for seeking/backptrs OR ensure frame duration is handled * add a requirement that on file split, split keyframes end on both sides of teh split [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters.
On Wed, Jan 16, 2008 at 07:44:29PM +0100, Michael Niedermayer wrote: [...]
So its probably possible to put it in streams, but its not clear if this is the best solution. If extradata is used we need * a special case for seeking/backptrs * a change to the header repeating rule
If a normal packet is used we need * a special case for seeking/backptrs OR ensure frame duration is handled
After rethinking, "handling" the duration cant be done, back ptrs just will still point far too far back. Also the seeking with the index needs the attchment in "disabled" state or it will always seek back to frame 0. But normal "disabled" state contradicts the fact that the streams are needed so a little bit of special handling is needed for either extradata as well as normal packet case
* add a requirement that on file split, split keyframes end on both sides of teh split
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is not what we do, but why we do it that matters.
_______________________________________________ NUT-devel mailing list NUT-devel@mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
On Wed, Jan 16, 2008 at 07:44:29PM +0100, Michael Niedermayer wrote:
Now no matter if extradata or normal packet, this will cause problems with seeking. As this is not a normal stream with frames one can seek to. Either we would need to consider the duration of frames (thats a thing we apparently ignored entirely) or ignore such attachment streams for seeking and back ptr calculation.
Again, EOR saves the day. These streams are permanent EOR. (A stream is EOR before its first frame occurs, anyway.) Thus it has no bearing on back_ptr or the index. Rich
On Wed, Jan 16, 2008 at 03:20:25PM +0100, Michael Niedermayer wrote:
On Wed, Jan 16, 2008 at 03:03:42PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote: [attachments]
I'd use application streams and info packets referencing them.
if you use streams then with the current spec you have a minimum of 3 copies of the fonts
Because of header repetition rule. Rich
Michael Niedermayer <michaelni@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. I see little rationale for other suggested applications either, e.g. cover art. Cover art normally belongs to an album, not individual songs, and personally I'd much rather have a directory of files, one per album track, and a few JPEGs for cover art, rather than embedding the covers in each track. Not only would that waste space, but normal image viewing applications would have trouble reading them too. As always, keeping things simple is probably the best solution. -- Måns Rullgård mans@mansr.com
On Wed, Jan 16, 2008 at 10:54:08PM +0000, Måns Rullgård wrote:
Michael Niedermayer <michaelni@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.
I see little rationale for other suggested applications either, e.g. cover art. Cover art normally belongs to an album, not individual songs, and personally I'd much rather have a directory of files, one per album track, and a few JPEGs for cover art, rather than embedding the covers in each track. Not only would that waste space, but normal image viewing applications would have trouble reading them too.
What about things like the individual images embedded in MOV files that QuickTime displays as a still until you start playback of the movie? Diego
Måns Rullgård wrote:
Michael Niedermayer <michaelni@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
On Wed, Jan 16, 2008 at 02:17:22PM +0100, Michael Niedermayer wrote:
they can only apply to a single stream. Neither of these limitations was in the original design.
Are you sure? It was always my intent that both kinds of info packets be possible, stream-specific ones and global ones. Isn't this still in the spec, albeit perhaps with some strange encoding of the non-stream-specific status? Certainly most metadata like authorship, title, copyright, etc. is not stream-specific but global to the work as a whole. *sigh* It's been way too long since I read the spec and the related discussions I guess.. Rich
On Wed, Jan 16, 2008 at 11:07:37AM -0500, Rich Felker wrote:
On Wed, Jan 16, 2008 at 02:17:22PM +0100, Michael Niedermayer wrote:
they can only apply to a single stream. Neither of these limitations was in the original design.
Are you sure? It was always my intent that both kinds of info packets be possible, stream-specific ones and global ones. Isn't this still in
global info as well as info specific to a single stream is in there but info packets applying to several streams have been removed, now with megabyte sized fonts this means you can add them as global ones but then no automatic remuxing of a subset of streams can be done cleanly. That is if i drop the japanese subtitles (which i cant read anyway) the huge kanji fonts wont disappear automatically. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
On Wed, Jan 16, 2008 at 07:49:32PM +0100, Michael Niedermayer wrote:
On Wed, Jan 16, 2008 at 11:07:37AM -0500, Rich Felker wrote:
On Wed, Jan 16, 2008 at 02:17:22PM +0100, Michael Niedermayer wrote:
they can only apply to a single stream. Neither of these limitations was in the original design.
Are you sure? It was always my intent that both kinds of info packets be possible, stream-specific ones and global ones. Isn't this still in
global info as well as info specific to a single stream is in there but info packets applying to several streams have been removed, now with megabyte sized fonts this means you can add them as global ones but then no automatic remuxing of a subset of streams can be done cleanly. That is if i drop the japanese subtitles (which i cant read anyway) the huge kanji fonts wont disappear automatically.
Hmm, I don't see this as a huge issue, but if you have a nice idea for addressing it I'm happy to listen. Rich
participants (6)
-
Aurelien Jacobs -
Diego Biurrun -
Luca Barbato -
Michael Niedermayer -
Måns Rullgård -
Rich Felker