Author: diego
Date: Mon Mar 3 17:58:44 2008
New Revision: 651
Log:
misc spelling fixes
Modified:
docs/nutissues.txt
Modified: docs/nutissues.txt
============================================================
==================
--- docs/nutissues.txt (original)
+++ docs/nutissues.txt Mon Mar 3 17:58:44 2008
 -16,7
+16,7 C. buffer fullness in seconds
D. buffer fullness in bytes
E. transmit time stamps
-Values in bytes are sensitiv to packet loss, which can
delay initial startup.
+Values in bytes are sensitive to packet loss, which can
delay initial startup.
These can be stored in one of the following
-122,34
+122,34 Implemented
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.
+The original intent of NUT frames was that 1 container
frame == 1 codec
+frame, albeit this does not seem to be explicitly written
in nut.txt.
Also it is inefficient for very small frames, AMR-NB for
example has 6-32
bytes per frame.
Solutions:
A. Enforce 1 container frame == 1 codec frame even if it
causes 10% overhead.
B. Allow multiple frames as long as the whole packet is
less than some
- fixed minimum in bytes (like 256byte)
+ fixed minimum in bytes (like 256byte).
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.
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.
+ Thus effectively avoiding the overhead small frames
cause.
It seems the consensus is: A+D With the specified bounds
Issue pcm-frames
----------------
-No word is said about how many or few PCM samples should be
in a frame.
+No word is said about how many or how 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)
+A. Define a maximum number of samples (like 512).
+B. Define a maximum timespam (like 0.1 sec).
+C. Define a maximum number of bytes (like 1024).
Implemented: A
-175,7
+175,7 C. New field in the stream header
D. Only allow 1 standard interleaving
What about the interleaving of non raw codecs, do all
specify the
-interleaving, or does any leave it to the container? If so,
our options
+interleaving, or do any leave it to the container? If so,
our options
would be down to only C.
Also a field specific to just raw does not belong in the
stream headers.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
