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

[Rich Felker]

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. I'm
absolutely against any proposal that precludes implementations from
performing zero-copy decoding from the stream buffer.

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

> +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 shit codecs in NUT. Obviously any good codec will use large
frame sizes or compression will not be good.

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

Yes.

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

> +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
accepted, it would have to be restricted to frames smaller than ~256
bytes. Otherwise the buffer requirements for reconstructing the
complete frame would be troublesome and for very large frames it would
make a huge performance difference.

> +Issue pcm-frames
> +----------------
> +No word is said about how many or few PCM samples should be in a frame.
> +
> +Solutions:
> +A. Define an maximum number of samples (like 512)
> +B. Define an maximum timespam (like 0.1 sec)
> +C. Define an maximum number of bytes (like 1024)

PCM is already a much bigger question due to sample format and
interleaving issues. Should there be a new fourcc for each combination
of PCM properties, or a single fourcc with extradata? If the latter,
the number of samples per frame would probably be coded in the
extradata or something. I'm open to ideas.

Rich