[NUT-devel] [nut]: r604 - docs/nutissues.txt

[Michael Niedermayer]

On Mon, Feb 11, 2008 at 10:41:51PM -0500, Rich Felker wrote:
> On Tue, Feb 12, 2008 at 12:33:22AM +0100, michael wrote:
> > Author: michael
> > Date: Tue Feb 12 00:33:21 2008
> > New Revision: 604
> > 
> > Log:
> > 3 more issues which have come up in the past but have IIRC never
> > been resolved.
> > 
> > 
> > Modified:
> >    docs/nutissues.txt
> > 
> > Modified: docs/nutissues.txt
> > ==============================================================================
> > --- docs/nutissues.txt	(original)
> > +++ docs/nutissues.txt	Tue Feb 12 00:33:21 2008
> > @@ -110,3 +110,42 @@ Solutions:
> >  A. Store such alternative playlists of scenes in info packets somehow.
> >  B. Design a separate layer for it.
> >  C. Do not support this.
> > +
> > +
> > +Issue header-compression
> > +------------------------
> > +Headers of codec frames often contain low entropy information or things
> > +we already know like the frame size.
> > +
> > +A. Store header bytes and length in the framecode table.
> > +B. Leave things as they are.
> 
> I think this one was resolved strongly as a leave-it-alone.

resolved by whom? :)


> I'm
> absolutely against any proposal that precludes implementations from
> performing zero-copy decoding from the stream buffer.

Well if you have a buffer in which the frame is, just write the header
before it. If not just write the header and then (f)read() the rest.


> 
> > +Issue small-frames
> > +------------------
> > +The original intent of nut frames was that 1 container frame == 1 codec
> > +frame. Though this does not seem to be explicitly written in nut.txt.
> 
> It is.

I thought so too but i searched, and didnt find it so where is it?


> 
> > +Also it is inefficient for very small frames, AMR-NB for example has 6-32
> > +bytes per frame.
> 
> I don't think anyone really cares that much about efficiency when
> storing 

I do, others likely care about 10% overhead as well.


> shit codecs

I think this applies more to audio codes, if it limited to coding shit
i wont bother and gladly leave it alone. ;)


> in NUT. Obviously any good codec will use large
> frame sizes 

no


> or compression will not be good.

also not true


> 
> > +Solutions:
> > +A. Enforce 1 container frame == 1 codec frame even if it causes 10% overhead.
> 
> Yes.

Vote noted. And my veto as well unless option D is selected which would
also include A.


> 
> > +B. Allow multiple frames as long as the whole packet is less than some
> > +   fixed minimum in bytes (like 256byte)
> 
> Very very bad. Demuxing requires a codec-specific framer.
> 
> > +C. Allow multiple frames as long as the whole packet is less than some
> > +   fixed minimum in bytes (like 256byte) and the codec uses a constant
> > +   framesize in samples.
> 
> This does not help.

help what?


> 
> > +D. Use header compression, that is allow to store the first (few) bytes
> > +   of a codec frame together with its size in the framecode table. This
> > +   would allow us to store the size of a frame without any redundancy.
> > +   Thus effectivly avoiding the overhead small frames cause.
> 
> At the cost of efficient decoding... If such a horrid proposal were

Id guess the overhead of working with 6 byte frames and decoding
a framecode before each takes more time than copying 60 bytes. Also depending
on the media this comes from 10% extra disk IO should beat 1 copy pass in
slowness.

And i dont give a damn about zero copy for a 400-1000 byte / sec codec!
also so much for bad compression ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080212/f5428264/attachment.pgp>