NihAV is an experimental multimedia framework aiming at several goals:
As you can see, NihAV is a research framework and its goals do not include either being the fastest, covering all possible formats, or world domination.
Additionally that means that NihAV code is written with emphasis on being clear and more self-containing i.e. avoiding tricks like SWAR where possible, duplicating code if it helps clarity, and not bundling similar functions into one module if they are not very related and used by different codecs from different families (e.g. vector functions from speech codecs). On the other hand if it makes to factor out some common code (e.g. for all H.263-based decoders) it is done in the most codec-agnostic way with clear interface between decoders and common decoding framework and no codec-specific hacks inside that framework.
It should be obvious from the goals that NihAV has different priorities from other frameworks and built on different principles.
Unfortunately there are no frameworks I could use as a base as they are either too simple and limited (like libquicktime) or too complex and convoluted that cutting it down and de-mangling is more tedious than writing a new framework from scratch (no points for guessing which one I'm talking about). The same is true to some extent for tcvp (it even used its own build system) and it's hard to locate nowadays. (Side note: rust-av had not existed at that time either).
Back in 2015 I stared to work on future NihAV design and even wrote some code (which was discarded later) but that attempt did not last for long since I lost interest in doing anything.
In 2017 I decided to try Rust to see what this language has to offer and the best way to do that is to write a complex project so I restarted NihAV and three years later it has main features implemented along with the support for a significant amount of codecs, some of them were reverse engineered specially for NihAV.
As a framework NihAV consists of the following crates:
nihav-core — a core crate containing common interfaces (frame data, codecs, de/muxers and such) plus common utility code like audio and image format conversion or decompression methods support;nihav-codec-support — a crate with auxiliary code useful for developing codecs (testing functionality, DSP, common code for H.263-based decoders and such) and not much else;nihav-commonfmt — a crate with decoders and demuxers for various common formats;nihav-registry — an auxiliary crate with code to detect common container formats, lists of fourccs and codec descriptions;nihav-duck, nihav-game, nihav-indeo, nihav-ms, nihav-qt, nihav-rad and nihav-realmedia — crates with decoders (and demuxers if needed) for a family of formats;nihav-allstuff — a crate that allows registering en/decoders and (de)muxers from the crates mentioned above in single place.The proper architecture overview will be done in another page later.
Additionally there are some tools written mostly to test or demonstrate functionality of the framework. There's nihav-tool for decoding audio and video streams and dumping decoded results into wave file and sequence of images correspondingly. There's nihav-encoder for transcoding media into different format (currently there's just two audio and two video encoders and single AVI muxer, so it serves more like a test bed for those encoders and a working prototype). And there's nihav-player, a buggy and very limited player that is useful only for watching samples to see if they are decoded properly. I plan to write a proper player that has at least basic features like pausing or seeking (or proper sync) but I cannot tell when this will happen.
As you know there are four software freedoms for a program user as formulated by Richard Stallman:
If you think there's an off-by-one error you may be right. RMS has not mentioned the last freedom in the list but nowadays it seems to be the most important one. In theory developers and project are paid in exposure (unless it's a large corporation not willing to admit using your software in public) but since I do not care about that and it's my side project for which I can't dedicate too much time to deal with feature requests or bug reports.
In result NihAV is licensed under GNU AGPL in order to be not so popular and provided as is without any warranty or promise of user support. Nevertheless, if you find some part of it useful I'll be happy to re-license it for you under any other free license (LGPLv2+, MIT, WTFPL, whatever—as long as it does not make new obligations for me) and other people can use it afterwards from your repository while NihAV still remains under AGPL. Manual re-licensing is done just to prevent abusing the system (like “can't you give all of the code under N-clause BSD?”—you're not rust-av as it is the only project to which I can allow that; or in the unlikely case when some project first takes my code and then badmouths it—why should I help it after that?).
For similar reasons the code is hosted at some obscure place instead of GitHub.
Meanwhile the main purpose of NihAV for other people should be providing bits of code of varying usefulness and demonstrating that any idiot can write a complex feature-rich multimedia framework with possible application in real world. I did it after all.
I do not like to make plans since they tend to go wrong. Also since NihAV has achieved all of its original goals (both in format support and playback/encoding functionality), there are no things left to plan. Though here are two potential directions for the further project development.
First of all, NihAV is a project to try new ideas and play with some old concepts. That is why I am going to continue implementing various things in order to find out how they work. For example, most of my encoders exist as test-beds for various encoding concepts like vector quantisation or motion estimation.
Second, I still have interest in researching how various codecs work so NihAV may gain support of some old forgotten format as a side effect of such research.
There are many different roads and usually one thing leads to another so I cannot predict how NihAV will be developed but I expect it to stay as useless as it is now.