Since I really had nothing better to do, I decided to try writing Bink-b encoder. Again. The previous version was a simple program to compress image sequence into a somewhat working video file, the new version supports all possible features: motion compensation, all block types including DCT-based ones, quality- and bitrate-oriented compression modes and even audio.
I worked on the encoders not because I have any real need but rather in order to both understand better how Bink codecs work and what tricks can be employed in the decoder. Bink video supports different block coding modes, from rather ordinary DCT to RLE using a custom scan order and special mode for coding motion residues. Bink audio is a simple perceptual codec that should still give me some possibilities for experimentation (of course I remember how I failed to write AAC encoder, but maybe with such simple format the outcome will be not too horrible?).
In the following posts I’ll try to describe how some things in Bink format work, what difficulties I had to overcome and what the results are.
Eventually I want to test my implementation against the original decoder (by creating a custom heroes3.vid or video.vid for HoMM3). Also it is rather easy to enhance my work to produce latter-version Bink videos but I’m not sure if it’s worth doing that as there’s a good free encoder for it already (probably a much better one than I can ever create) and Bink format is not a good candidate for normal videos as it was created for game cutscenes with the only options to keep or end playing, no option for rewinding back at random place to repeat scene you missed (or skip some boring part).
In either case, it’s still a nice experience. After all, NihAV is about experimenting and learning how stuff works and Bink offered a lot of new things to try.
What is it about Bink codecs that are so alluring: simple (no silly features or bloat) and effective.
Well, it has too many bitstream revisions but it’s not as bad as Monkey’s Audio. Compared to many other formats it’s almost perfect indeed.
Everything is better than Monkey’s Audio.
Nah, there are many things that are worse in some aspects than APE. At least the format has clearly defined frames (unlike FLAC), its reference source code provided and the author not minding parallel implementations (unlike the certain codec you know), it does not try to have too many features (like WavPack or MPEG-4 ALS, the latter also suffers from bitstream incompatibilities for floating-point audio).
And there’s Ogg(Squish).
“too many features” — float and multi-channel WIP state in MAC comes to mind.
I don’t mind multi-channel audio support in codecs (especially if it’s done in a reasonable way), floating-point mode is excessive indeed. APE still needs to support DSD and lossy encoding (with optional lossless reconstruction data) to match WavPack though.