[NUT-devel] NUT?

[Rich Felker]

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

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

> In practice we've never cared about the latency. For interactive 
> applications Ogg is not appropriate, and RTP over UDP is the already
> existing solution for low-latency work. For unicast delivery (what we 
> mean when we say ogg was designed for streaming) the latency is not 
> significant.
> 
> For the more typical case (4k pages, 10 packets/page) the Ogg overhead 
> works out to 4.8 bytes per packet (frame) or 1.2% vs 0.5% for NUT. So 
> NUT is better by about a factor of two there, but both are very low.

Keep in mind Ogg has high latency and has thrown away 90% of the frame
timestamps in the case you're looking at. The only way to recover the
missing timestamps is to parse the frames at the codec level. So NUT
has half the overhead, no latency, and 10 times more container-level
information.

If you want to compare on equal ground you'll have to mux the Ogg in a
way that it keeps the same information NUT keeps, and see that the
overhead is not just twice but almost 30 times as much..

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

BTW, note that with Ogg, overhead percentage does NOT go to 0 as frame
size increases, because the field that stores the size is O(n) rather
than O(log n)... In practice it's of little consequence, but it still
reflects bad design. :)

> So NUT seems to be intended for TCP streaming and file storage, much 
> like Ogg. It uses a more complicated framing scheme to save a fraction 
> of a percent of bitrate.

IMO it's less complicated than the 2-tier page/packet mess (especially
the fragments issue, which makes it impossible to demux in place
without memcpy'ing around buffers, seriously hurting performance at
high bitrates), and it's actually correct and complete unlike Ogg. The
purpose is not to save bitrate but to be sane in all reasonable cases
rather than just a few.

> Technically I think the more significant 
> difference is that metadata and codec-independent muxing is embedded 
> within the format rather than layered on top.

Yes, these are certainly the most important advantages of NUT. Sadly
they're also the most obvious. Even AVI got them (almost) right more
than a decade ago, while almost every other container since then has
gotten them horribly wrong.

Rich