attachments

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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.

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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.

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Michael Niedermayer <michaelnigmx.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
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel