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
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|