Before people reading this blog (all 0 of them) start asking about it — yes, I’ve started implementing NihAV, it will take a lot of time so don’t expect it to be finished or even usable this decade at least (too little free time, even less interest and too much work needed to be done to have it at least somewhat usable for anything).
Here’s the intended structure:
libnaarch— arch-specific stuff here, like little/big endian handling, specific speedup tricks etc. Do not confuse withlibnaosstuff— I’m not interested in non-POSIX systems.libnacodec— codecs will belong here.libnacompr— decompression and compression routines belong here.libnacrypto— cryptographic stuff (hashes, cyphers, ROT-13) belongs here.libnadata— data structures implementations.libnaformat— muxers and demuxers.libnamath— mathematics-related stuff (fixedpoint calculations, fractional math etc).libnaregistry— codecs registry. Codec information is stored here — both overall codec infomation (name to description mapping) and codec name search by tag. That means that e.g. FOURCC to codec name mapping from AVI or MOV are a part of this library instead of remaining demuxer-specific.libnautil— utility stuff not belonging to any other library.
Remark to myself: maybe it’s worth splitting out libnadsp so it won’t clutter libnacodec.
Probably I’ll start with a simple stuff — implement dictionary support (for options), AVI demuxer and some simple decoder.
Is the plan here to supersede FFmpeg/Libav?
My library split has pixel, samples and metadata as separate libs, beside that we have quite the same ideas =)
@thardin
Nah, I don’t care about world domination or superseding any other project. Or even completing this one really.
@lu_zero
I’m not to the stage where any of those matters yet. But I guess it’ll end the same way — nothing being done.
You keep indicating that you do not believe people read what you write here, so I felt obligated to point out that I do, and have for some time, and plan to continue doing so for the foreseeable future. The things that you write are not relevant to any of my interests specifically, and yet I find them interesting enough that I continue reading them, and always am glad that I have done so. So thank you.
why are you proposing a single monolithic libnacodec? i employ you to consider separate libs for each codec type~
libnaacodec
libnavcodec
libnascodec
libnadcodec
…
Is traditional library splitting meaningful today?
runtime code generation and small kernel compiling are needed for offloading to GPGPU, Xeon Phi or FPGAs.
@Peter
Mostly because decoding (or encoding) interface for the codecs should be the same. But it will be fine-grained inside as I’ve already written in some previous posts.
Library split is done per functionality after all.
@n
Too niche IMO.
if you are starting from scratch, have you thought about coding it in rust (http://www.rust-lang.org/) instead of C?
rust solves many of the problems of C (memory safety, concurrency, …) with the same performance. and it can even interface with C code with zero overhead, so you don’t have to rewrite the whole world at once.
rust went 1.0 today with a guarantee of a stable API. Here is a great introduction: http://hacks.mozilla.org/2015/05/diving-into-rust-for-the-first-time/
My point here is only to say, no matter what you do, someone else will come along and say you’re not going far enough 🙂
And my answer is “yes, so what?”