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