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

[Rich Felker]

On Tue, Feb 12, 2008 at 05:51:44AM +0100, Michael Niedermayer wrote:
> > 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.

I'm envisioning a model where the demuxer directly exports frames from
their original location in the stream buffer. It's likely that this
buffer needs to be treated as read-only. It might be mmapped from a
file (in which case writing would invoke COW) or the previous frame
might not yet be released by the caller (in which case, writing the
header would clobber the contents of the previous frame) -- imagine
for instance that we need to decode the next audio frame to buffer it,
but aren't ready to decode the previous video frame yet.

The reason I'm against this whole header compression thing is that it
puts lots of nasty restraints on the demuxer implementation that
preclude efficient design. The nasty cases can be special-cased to
minimize their cost, but the tradeoff is implementation size and
complexity. The only options I'm willing to consider (and which I
still dislike) are:

A. Only allow header elision (a more correct name than compression)
for frames below a very small size limit (e.g. small enough that the
compression makes at least a 1% difference to space requirements).

B. Require that the elided header fit in the same number of bytes (or
fewer) than the minimal NUT frame header size for the corresponding
framecode. This would allow overwrite-in-place without clobbering
other frames, but still the COW issue remains which I don't like...

> > > +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?

It's at least in nut-english.txt :)

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

Care about it for what applications? For storing a master file in some
odd barely-compressed audio form, I wouldn't care. For streaming radio
or movie rips, of course it would matter, but I think someone would
choose an appropriate codec for such applications..

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

Is there any audio codec of real interest with such small frame sizes?

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

It's frustrating how you intend to "veto" decisions that were made 4
years ago now when we're trying to finally get NUT to see the light.

> > > +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?

I meant that I don't see how it's any less offensive than option B.
The fundamental problem is still there: inability to demux and seek to
individual frames without codec incest. It's sad that we've gotten to
the point where 1 byte of overhead per frame is too much.. Even OGG
and MKV have at least that much!

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

I'm not worried about zero copy for such a low bitrate stream. My
concern is that idiots could use this nasty header compression for
20mbit/sec h264 for no good reason, just because it "sounds good".

Rich