If anybody read my previous posts, he might’ve picked a notion about me complaining that there’s nothing left to do for NihAV and it is really a problem I have.
Since the (re)start of the project in 2017 it grew from a small package that could only read bits and bytes to a collection of crates supporting various multimedia formats and a set of tools to use them. I had two principal goals: to experiments with the framework design and learn how various multimedia concepts are implemented and also (ideally) make an independent converter and player so I don’t have to rely on the external projects for most of my multimedia needs.
And what do you know, I’ve achieved both. With multimedia concepts I covered basic things like overall say e.g. transcoder or player design, various algorithms for compression (like vector quantisation or motion estimation) and used that new knowledge to write complex encoders, as well as other things (palettisation, scaling/resampling and such). For the tools I have a decoder which I use extensively to test decoding, an audio player that supports most of the formats I care about (and which I’m using regularly now), a transcoder that can encode some exotic formats into something other players would understand, and finally a video player that is good enough for my needs and that I’m using now about 90% of time.
Now the question is what to do next and there are no good answers as the only options I see are uninteresting, tedious or sometimes just one of those things. In other projects users may drive development with their requests, in this case I’m the only user.
Here’s the list of ideas I considered and discarded:
- play more with lossless compression methods (Huffman or arithmetic coding, LZ-family methods, BWT and such)—I’ve done enough of this last century;
- play more with ADPCM-based codecs—I’ve implemented decoders for several of those and even an encoder for one or two of those;
- implement more lossless audio codecs—I can but what’s the point? The ones I care about are already covered (and I’ve written not completely sucky FLAC encoder too);
- implement more lossless video codecs—those are dime a dozen and usually contain nothing remarkable about them either. Back in the day I even wrote a post listing about three dozens of various lossless codecs and probably during the time it took me to briefly look at those and write a post a couple more has appeared (let alone in all those years passed since then);
- implement decoders for some codecs in general—I don’t want to implement them just because and I see no interesting formats worth implementing;
- what about game formats? The same problem, it’s hard to find a game with a unique and interesting format (a game with unique formats are more common though);
- what about writing some encoders for a change? I write encoders mostly to test various concepts and I see no new concept to be employed in an encoder);
- speech codecs—I don’t like those in general (I’ve written a rant about it as well) so I’ll avoid them as much as possible;
- what about some specific codec families? Let’s see: Xiph codecs are usually as bad as speech codecs (in some cases they are speech codecs) in terms of documentation and the reference code and I don’t have much content encoded with Vorbis let alone any other format of theirs (FLAC is an exception); Windows Media codecs—not that interesting or useful to me; something enterprise—both unappealing and tedious;
- implement something common on the web like VP9+Opus+WebMKV—not a fan. As long as there is an alternative in form of H.264+AAC+MP4 I’ll pick it instead;
- implement MOV or MP4 muxer? I have considered doing that but it is rather hairy and I don’t have an immediate use for it (mostly because I also see no reason to implement any QuickTime encoder for the reasons stated above; and for interoperability I can still encode Cinepak in AVI);
- support more image formats? I see no reasons for that now. Maybe when image viewers will suck even more than they do now (I can rely on GNOME for that) and I can’t find a good replacement then I should write something. I’m still not sure if it should be a part of
NihAVthough; - add some shiny features to the player or make hardware accelerated video work there faster? Too hairy to my tastes for a benefit I don’t really need;
- more shiny features for the transcoder? I don’t think I need anything there either;
- extend some existing decoders or improve some already existing encoders—what for? It is another example of work that gives no benefit to me;
- introduce filters? Definite no on principle. I mentioned in the very beginning of the project that I believe filters belong elsewhere as they form their own ecosystem essentially. Plus I still have no interest in them.
So now you know why there should be no foreseeable progress in NihAV development. Not that there was much before yet it somehow got to this state. Let’s watch rust-av progress instead.
Of course I hope there will still be something interesting to make me work on the project again. But for now I should remain content with the feeling that my piece of software is good enough that it needs no further development.
Covered 0% of subtitle formats.
And proud of that.
What’s your thoughts on tracker files?
It’s probably too tedious and won’t scratch an itch for you. It’s also maybe not directly applicable to the work on NihAV. But maybe exploring the current streaming landscape (HLS/DASH), with all the updates/changes/complexity that continues to pile on in these *standards* can be of interest.
All the HLS extension tags (AWS a primary offender).
How HLS is verging away from the simple serviceable protocol it once was by continuing to copy crap from DASH.
How ISO DASH is so shit, that DASH-IF (industry forum) had to exist and produce a *guidelines* document to make sense of it all.
All the protocol-native ways added to support displaying ads.
All the encryption methods known (and maybe less known) used for segments/samples.
And so on, and so forth.
It is all maybe too tedious as I already mentioned. But the mess is maybe worth at least talking about. It is after all how most multimedia consumption is being done nowadays, and it is the moving part in that consumption, since there is not much movement in the codecs side for example (no new audio codecs, low VVC adoption and no relevant hardware support coming soon)!
Tracker files is a wonderful thing (I even tried my hoof at composing one, not merely listening to them) but considering how they are organised they rightfully belong to their own ecosystem as well (with special libraries like
modplugor evenadplugto render those various formats). As for the general integration, you might rememberlibavsynthand what happened to it.There’s probably a reason why I tried to stay as far as possible from the streaming things (beside my involvement with RTMP), but it might be just an instinct.
The things you mentioned are rather an outcome of a battle of business interests that has little to do with the technologies themselves. I might write a rant about it even if it’s rather pointless.
Support for formats like trackers in libraries like FFmpeg pains me on a deep level that I have difficulty articulating… I guess it’s because it flattens the audio. I loved tracker programs and files when I was a young computer dork, and I loved watching the music– so many cool visualizations as you could watch exactly how the music was being synthesized. I guess I’m distraught when that gets lost as the generic multimedia player treats it as just another generic linear audio stream, but such is life.
And perhaps I *just* figured out why some multimedia purists I know HATE it when interlaced source video gets deinterlaced and archived/compressed that way, even if the deinterlacing was performed with the most sophisticated algorithms.
With the trackers I suppose the difference is somewhat like playing a game and watching a playthrough. I also remember trying different MOD players (and even composers), fiddling with the channels during playback and so on.
As for the deinterlacing, I suspect it is rather the same as with all those AI-enhanced 4K colourised videos from XIX century. The problem is that what you get may look better but it not what was originally there. You might remember the infamous ‘Ecce Homo’ fresco from 2012, it kinda represents the modern times.
Hello Kostya!
I have recently stumbled upon your NihAV project, and i hope to ask some questions about it if you wish.
1. Does it support Bink2 (.BK2 extension, header KB2) decoding to any more common codec like H.264 or H.265?
2. If it does, how can i build the latest commit myself as i am new to rust projects.
3. Can it be used in cli form to automate via python, bash or batch.
I have been diving into games for some time, and have some curiosity with ripping, converting and merging audio from audio middlewares (FMOD and WWise) into these videos for preservation and replay-ability purposes.
This obviously involves converting proprietary formats to common ones, and the official Bink Tools do provide some of these features, but provide no good way to automate conversions of large quantity of videos, and come with some limitations such as being unable to create .AVI files larger than 2GB.
This is because in recent versions of Bink/RAD Video Tools, they have removed the option to select a compression codec for output, thus it extracts uncompressed frames, which means any .bk2 file larger than 10MB cannot be extracted no matter what you try, we can extract individual images, but then we have to convert them to a video which is an additional step no one wants to go through.
I did find older versions of the RAD Video Tools, but the output codecs are old, have bad compression, and very slow due to their software decoding nature.
If you could help me do this, i may be able to find a good use for your project, because no other video codec project is willing to support bink2, including ffmpeg, who have refused to add decoding support for 8 years.
I have had a look at the source of NihAV, and have found some references to Bink2, but have no idea about the capabilities of the project.
I hope you can help, if you wish to continue this conversation, please contact me at the email submitted in the comment.
Thanks In Advance, I hope more people appreciate small projects like this one.
Unfortunately my project is more of a toy nature so I can’t help you much. It can decode Bink2 video but far from perfect (I lost interest in the codec before I figured out some reconstruction details right) and while there’s a tool called
nihav-encoderthat may transcode them, it only can encode into the formats I have written support for (i.e. the same up-to-2GB AVI files using Cinepak or VP6, no hardware-accelerated H.264 encoding to MP4 and such).So you’re out of luck here, sorry.
Such a bold claim to write that FFmpeg refused to add Bink2 for you for 8 years. I hope FFmpeg never adds Bink2 specially for users that wish everything served free.