Hello, I was doing some reading and came across NUT. I was wondering if I could get more info about NUT. (I am familiar with Ogg and becoming familiar with Matroska, so perhaps I can ask a question in terms of those. So that I can understand NUT too.) I understand that the Ogg team and Matroska team had different design goals. (The Ogg team seems to hold "streaming" as their design goal. Where Matroska seems want to create a DVD-like format.) What are NUT's design goals? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
On Fri, Oct 27, 2006 at 01:05:58PM -0700, Charles Iliya Krempeaux wrote:
Hello,
I was doing some reading and came across NUT.
I was wondering if I could get more info about NUT.
(I am familiar with Ogg and becoming familiar with Matroska, so perhaps I can ask a question in terms of those. So that I can understand NUT too.)
I understand that the Ogg team and Matroska team had different design goals. (The Ogg team seems to hold "streaming" as their design goal. Where
The Ogg team's claim of streaming is purely proaganda. The Ogg format is not "streamable" in the sense that you have to buffer large chunks before you can write them, or else have HUGE overhead. Ogg also has countless other design flaws, which have been discussed in several past threads on the ffmpeg-devel and mplayer-dev-eng lists. It's generally considered by people who work with container formats to be the worst of the container formats.
Matroska seems want to create a DVD-like format.)
I wouldn't call it DVD-like except in the "user experience" it attempts to deliver with chapters, etc. NUT can do this too but does not try to control any sort of menu presentation; it just provides the information for the application to interpret as it sees fit. Where Matroska differs from NUT is being hierarchically block-oriented rather than stream-oriented, and also (partly as a result) much more complex. Presently I like getting mkv files because it's much better designed than all the other atrociously bad containers out there, but it was designed with a Windows/C++/object-oriented-serialization sort of philosophy rather than a byte-stream philosophy (like MPEG/DVD uses and like UNIX gurus prefer, for many good technical reasons). Thus the designers of NUT set out to create something with a solid, rigorous, efficient fundamental design. It took a long time and a lot of troubles came up along the way but I'm quite pleased with what we ended up with.
What are NUT's design goals?
See nut.txt in MPlayer svn (http://svn.mplayerhq.hu/mplayer/trunk/DOCS/tech/nut.txt) Basically, in summary: - low overhead - complete timestamping - ability to play nondamaged parts of damaged/incomplete files - perfect seeking (not just approximate) - fine-grained seeking at the frame level - guaranteed efficiency bounds (including fast accurate seeking on files with missing or damaged index) - extensibility - simplicity of muxer and demuxer impementation - disallowing idiotic file structure (like non-interleaved avi, etc.) BTW thanks for asking this question. Now that we're seeking to deploy NUT we should really address questions like yours better on the website and in the documentation. Rich
Hello Rich, On 10/27/06, Rich Felker <dalias@aerifal.cx> wrote:
On Fri, Oct 27, 2006 at 01:05:58PM -0700, Charles Iliya Krempeaux wrote:
Hello,
I was doing some reading and came across NUT.
I was wondering if I could get more info about NUT.
(I am familiar with Ogg and becoming familiar with Matroska, so perhaps I can ask a question in terms of those. So that I can understand NUT too.)
I understand that the Ogg team and Matroska team had different design goals. (The Ogg team seems to hold "streaming" as their design goal. Where
The Ogg team's claim of streaming is purely proaganda. The Ogg format is not "streamable" in the sense that you have to buffer large chunks before you can write them, or else have HUGE overhead.
This probably shows my ignorance in the area but... if you have the inclination to put up with what probably seem like a "basic" questions.... What are Ogg's problems with streaming? And how does NUT fix this problem? (I by no means consider myself an expert in this area. So I'd really appreciate any answer to this as it would help me educate myself on in this area.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
On Sun, Nov 05, 2006 at 12:46:10AM -0800, Charles Iliya Krempeaux wrote:
I understand that the Ogg team and Matroska team had different design goals. (The Ogg team seems to hold "streaming" as their design goal. Where
The Ogg team's claim of streaming is purely proaganda. The Ogg format is not "streamable" in the sense that you have to buffer large chunks before you can write them, or else have HUGE overhead.
This probably shows my ignorance in the area but... if you have the inclination to put up with what probably seem like a "basic" questions.... What are Ogg's problems with streaming? And how does NUT fix this problem?
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. In practice it's something like half a second with common low-quality-stream bitrates and settings, making it rather useless for something like videoconference or voip. Even if perfect on-time delivery isn't essential to your application, there are already enough things causing latency in live media streaming that adding another layer of latency is utterly stupid. NUT simply has no level of buffering beyond ensuring that frames are written in the correct order by time. There is no concept of "page" or other higher level of packetization; every frame is written as an individual unit in the file stream. Due to extremely efficient header coding designed mostly by Michael, we're able to achieve this without any overhead penalty at low bitrates (where it matters most) and extremely minimal overhead penalty at higher bitrates. Rich
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. 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 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? 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. 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? 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. Technically I think the more significant difference is that metadata and codec-independent muxing is embedded within the format rather than layered on top. IMO, -r
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
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
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
btw, ralph if you disagree here, iam curious about the cases where you think that a crc field on frames makes sense
The main thing, I think, is that most decoder implementations are not robust against garbage data (and in some cases cannot be, entirely) so a crc on the frame data helps catch corruption that could crash or mangle playback. It's not a security issue per se, since malicious code could of course set correct crcs, but it still improves robustness. As a counterexample, RTP packets don't have an internal CRC, but since they're supposed to fit within an unfragmented UDP packet, they can piggyback on the transport's checksum for a similar level of integrity. The other point is file verification. Since people collect and serve media files, it's convenient to have an embedded integrity check to detect corruption. An embedded hash or separate checksum can do the same thing, but it's not automatic, and doesn't work with streaming. They do help with truncation detection though. PNG images (and FLAC frames) have CRCs, JFIF jpeg and GIF do not, so perhaps you can make an argument that it's more important for lossless storage. But I've only heard the png developers talk in terms of integrity verification motivated as above. -r
On Sun, Nov 05, 2006 at 06:22:34PM -0800, Ralph Giles wrote:
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
btw, ralph if you disagree here, iam curious about the cases where you think that a crc field on frames makes sense
The main thing, I think, is that most decoder implementations are not robust against garbage data (and in some cases cannot be, entirely) so a crc on the frame data helps catch corruption that could crash or mangle playback. It's not a security issue per se, since malicious code could of course set correct crcs, but it still improves robustness.
If your decoder implementation is not robust against invalid data, then you MUST fix it. Not doing so is a remote exploit waiting to happen. Having the container 'protect' the decoder from corrupt data only makes it less likely for these bugs to be found at random, and more likely for evil crackers to be hoarding them and waiting to use them on you. :)
The other point is file verification. Since people collect and serve media files, it's convenient to have an embedded integrity check to detect corruption. An embedded hash or separate checksum can do the same thing, but it's not automatic, and doesn't work with streaming. They do help with truncation detection though.
A single hash of the whole file is easier to check when managing file integrity, and then you can use a single scheme for all your files rather than different integrity-checking for each file format.
PNG images (and FLAC frames) have CRCs, JFIF jpeg and GIF do not, so perhaps you can make an argument that it's more important for lossless storage. But I've only heard the png developers talk in terms of integrity verification motivated as above.
I think it's just a matter of people not understanding what they're doing and thinking "hey I could throw a CRC at it to protect it from corruption!" without even asking what concrete problems it would solve or fail to solve... Rich
Hi On Sun, Nov 05, 2006 at 06:22:34PM -0800, Ralph Giles wrote:
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
btw, ralph if you disagree here, iam curious about the cases where you think that a crc field on frames makes sense
The main thing, I think, is that most decoder implementations are not robust against garbage data (and in some cases cannot be, entirely) so a crc on the frame data helps catch corruption that could crash or mangle playback. It's not a security issue per se, since malicious code could of course set correct crcs, but it still improves robustness.
well, there are 3 things here first is harmless crashes due to out of array reads, null pointer dereference and such second are security issues like writes over the end of an array or various integer overflows causing writes to unallocated memory third are audible distortions caused by errors there are also 2 different types of codecs ones which code a frame as a single monolithic piece so that a single error causes the whole frame to become useless and ones which code a frame so that an error only affects part of the data, mp3, vorbis and i think many other audio codecs fall in the first category OTOH, mpeg1/2/4 h263/4 fall in the second, they do support spliting a frame in several independant slices (in case of mpeg2 1 slice per 16pixel row is mandatory at minimum), also mpeg4 and h264 further allow a slice to be split in 3 partitions which in case of mpeg4 can be encoded with reversible vlcs, so that decoding can be done from start to end and from end to start recovering alot of data surounding a single error (backward decoding though isnt supported by anyone AFAIK, but using undamaged slices and undamaged partitions of damaged slices is supported by libavcodec for example) some audio codecs designed for "noisy" environments, i think AMR is one of them also use various tricks to recover data from damaged frames all that makes a crcs less usefull, a demuxer cannot just drop damaged frames, what it could do is pass a is_damaged flag to the decoder but that then would require decoders to have support for such a thing, and decoders dont currently (we could ask everyone to change their decoders and corresponding APIs but i doubt anyone would, and sure it can still be used somehow with wrapers around decoders or a list of decoders and their error recovery capabilities, it just IMHO becomes somewhat messy for little gain ...) about crashes, a crc of course pretty much prevents them from occuring on random or damaged data, but it also prevents users from sending bugreports for such crashes (there are no crashes ...) which has 2 effects 1. the decoder will be full of bugs which make it crash on random data so it pretty much depends on either error free data or a container with checksums 2. some of the crashes can be security issues, which normally would have been found due to bugreports about the crashes ... another problem is rawvideo is large and highbitrate video too, and calculating crcs takes time, which leads us to yet another question, should these crcs be mandatory or optional if optional, then all the advantages pretty much disapear, but mandatory seems unflexible and also adds alot of overhead for small packets and having a checksum over several packets also means extra delay vs. ignoring the checksum, so in the end checksums on frames cause more problems then they solve IMHO optional ones dont help the decoders preventing random input, dont help the users checking files mandatory ones mean more overhead, slower muxing for rawvideo or high bitrate video which could be a problem for anything realtime also crashes security or not should be fixed IMHO not be hidden by crc checks also nut is sufficiently extendible so that we can always add crcs on frames later without breaking compatibility with old decoders [...] -- 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
Michael Niedermayer wrote:
also nut is sufficiently extendible so that we can always add crcs on frames later without breaking compatibility with old decoders
Paranoids could just add an application stream with error detection/recovery codes. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi On Mon, Nov 06, 2006 at 01:30:45PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote:
also nut is sufficiently extendible so that we can always add crcs on frames later without breaking compatibility with old decoders
Paranoids could just add an application stream with error detection/recovery codes.
yes though i think they would rather put the md5 in the filename and if theres a good reason for crcs on frames we should either add them into syncpoints or the framecodes (both can be done without breaking old demuxers), the user of course cannot do either with the current spec as messing with reserverd fields is forbidden, so he would be limited to a application stream as you say ... [...] -- 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
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
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%
Thanks, Michael. Could you do a similar sketch for vorbis audio? I tried nutmerge on a couple of files and it reported 1.2-1.5% overhead, and was curious if the claimed 2 bytes per frame is possible with vorbis. -r
On Sun, Nov 05, 2006 at 06:31:32PM -0800, Ralph Giles wrote:
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
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%
Thanks, Michael. Could you do a similar sketch for vorbis audio? I tried nutmerge on a couple of files and it reported 1.2-1.5% overhead, and was curious if the claimed 2 bytes per frame is possible with vorbis.
If you modify nutmerge.c, there's a table at the top, you need to change it to this: frame_table_input_t ft_default[] = { // There must be atleast this safety net: //{ 4128, 3, 0, 1, 0, 0, 0 }, //{ flag, fields, pts, mul, stream, size, count } { 8192, 0, 0, 1, 0, 0, 0 }, // invalid 0x00 { 56, 0, 0, 1, 0, 0, 0 }, // safety net non key frame { 56, 0, 0, 1, 0, 0, 0 }, // safety net key frame { 4128, 0, 0, 1, 0, 0, 0 }, // one more safety net { 27, 0, 0, 1, 0, 0, 0 }, // EOR frame { 1, 4, 16, 386, 0, 190, 0 }, { 1, 4, 2, 90, 0, 40, 0 }, { 32|1, 3, 9, 1, 0, 0, 0 }, { 32|1, 3, 23, 1, 0, 0, 0 }, { 32|1, 3, 2, 1, 0, 0, 0 }, { 8192, 2, 0, 1, 0, 0, 0 }, // invalid 0xFF { -1, 0, 0, 0, 0, 0, 0 }, // end }; With this, trying 2 samples I have, I got this overhead: Stream 0: frames: 13156 TOT: packet size: 2764411 packet overhead: 15660 (0.57%) AVG: packet size: 210.13 packet overhead: 1.19 Syncpoints: 86 size: 1536 TOTAL: 2764411 bytes data, 29609 bytes overhead, 1.07% overhead Stream 0: frames: 122493 TOT: packet size: 20807068 packet overhead: 148978 (0.72%) AVG: packet size: 169.86 packet overhead: 1.22 Syncpoints: 643 size: 11564 TOTAL: 20807068 bytes data, 175184 bytes overhead, 0.84% overhead BTW, note that in the former, ~30% of the overhead is the header repetition :) (3 header copies, each 4kb big because of vorbis) - ods15
Hi On Mon, Nov 06, 2006 at 07:53:10AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 06:31:32PM -0800, Ralph Giles wrote:
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
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%
Thanks, Michael. Could you do a similar sketch for vorbis audio? I tried nutmerge on a couple of files and it reported 1.2-1.5% overhead, and was curious if the claimed 2 bytes per frame is possible with vorbis.
If you modify nutmerge.c, there's a table at the top, you need to change it to this:
what about generating a more optimal table automatically? like the lavf muxer did? should all users of libnut hack the source depening on what they want to put in nut? [...] -- 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
On Mon, Nov 06, 2006 at 01:47:10PM +0100, Michael Niedermayer wrote:
Hi
On Mon, Nov 06, 2006 at 07:53:10AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 06:31:32PM -0800, Ralph Giles wrote:
On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
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%
Thanks, Michael. Could you do a similar sketch for vorbis audio? I tried nutmerge on a couple of files and it reported 1.2-1.5% overhead, and was curious if the claimed 2 bytes per frame is possible with vorbis.
If you modify nutmerge.c, there's a table at the top, you need to change it to this:
what about generating a more optimal table automatically? like the lavf muxer did? should all users of libnut hack the source depening on what they want to put in nut?
It's on the TODO list. :) - ods15
participants (6)
-
Charles Iliya Krempeaux -
Luca Barbato -
Michael Niedermayer -
Oded Shimon -
Ralph Giles -
Rich Felker