[NUT-devel] NUT?

[Michael Niedermayer]

Hi

On Sun, Nov 05, 2006 at 04:32:42PM -0500, Rich Felker wrote:
> On Sun, Nov 05, 2006 at 12:13:08PM -0800, Ralph Giles wrote:
> > On Sun, Nov 05, 2006 at 12:05:30PM -0500, Rich Felker wrote:
> > 
> > > Ogg's problem with streaming is that the only way it avoids massive
> > > overhead is by packing large numbers of frames into a single Ogg
> > > "page". The page cannot be transmitted until it's complete, adding an
> > > extra senseless stage of latency to the stream.
> > 
> > To be a bit more explicit, Ogg fragments and/or packs individual data 
> > packets (I guess those are "frames" in NUT terminology?) into data 
> > chunks called "pages". So Mr. Felker is correct that one must buffer at 
> > least one page (one page from each stream in the general multiplexed 
> > case).
> > 
> > Each Ogg page as a 27-byte header which includes a sync magic, 
> > timestamp, and crc. Additionally, the length of the packets (or 
> > fragments) in the page body are encoded in a series of bit counts, with 
> > counts less than 255 marking packet divisions. For a sequence of packets 
> > (frames) < 255 bytes each, where the length encoding requires one byte 
> > per packet (frame). The case mentioned above, where one puts one packet 
> > per page to minimize latency, that's an overhead of 28 bytes per packet.
> 
> Yes, which is quite large (28% overhead) if your bitrate is
> 32kbit/sec...

which honestly is maybe somewhat low bitrate, i would rather say 64kbit/sec 
would be more realistic and give a overhead around 14% or so but thats still
quite large ...


> 
> > NUT appears to use variable length coding (a la utf-8) and table lookup 
> > (and delta coding for timestamps?) for most headers and the docs claim a 
> > 2 byte-per-packet overhead for a single-stream audio case, and that one 
> 
> Average is about 1.3 bytes per packet for low-bitrate vorbis, IIRC.
> 
> > can send the packets one-at-a-time, but I'm not clear how this 
> > interacts with the CRC field. Maybe that's assuming you write 
> > it for a group of frames at the end?
> 
> NUT CRC is only for container-level data. There is no CRC for frame
> contents because it's useless.

btw, ralph if you disagree here, iam curious about the cases where you think
that a crc field on frames makes sense


[...]
> > Ogg has bounded overhead as packets get bigger as well, but I 
> > don't understand NUT well enough to compare that case (say 17k video 
> > frames, where Ogg is 28+17k/255 bytes or 0.5%). Could you do a sketch 
> > there?
> 
> As your frames get large, the overhead percentage will approach 0 with
> any remotely-sane container. At 17k video frames, NUT should give
> something like 20-25 bytes of overhead per frame on average, IIRC.
> (Can someone else do the math and check this?)

hmm ill try
assuming max_distance is the default 32k, a syncpoint would be needed
after every frame (nasty choice of frame size)

so we have 8 bytes for the syncpoint startcode
1 byte forward_ptr
2-3 byte global_key_pts (2 will be enough for 9min at 30fps, 3 will be 
needed after that until 19h)
2-3 byte back_ptr_div16 (2 for keyframe distance <16, 3 for <1900
4 byte crc
1 byte frame code (delta timestamp + 1 at 1/30 timebase, stream 0 (i
  assume we have just one stream), keyframe flag either set (assuming
  an intra only video, or not set and cases where it is set would then
  be rare and insignificant)
  we have 200 frame codes which have data_size_lsb from 0 to 199 and 
  data_size_mul at 200, this leave us about 50 frame codes for other
  uses like more streams, or ...
1 byte data_size_msb

thats ~ 20 bytes per frame overhead or ~ 0.11%
with 15k frames it would have been ~ 11 or ~ 0.07%
with 2mb frames you would end up with ~ 22 byte or ~ 0.001%

i hope ive not forgotten anything (which is surely possible ...)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is