Foreword or Why?!?!
There are two curses in program design (among many others) — legacy and monolithic design.
Legacy means two things: first, there is such thing ask backward compatibility that you (sometimes have to maintain) or the users will complain about broken APIs and ABIs; second, there’s code legacy, i.e. decisions taken in the past that are kept for some reason (e.g. noone understands how it works). Like AVI demuxer in libavformat containing special cases for handling specific files that noone has ever seen.
Monolithic design is yet another problem that creeps into many projects with time. I don’t know why but quite often code gathers itself into intangible chunks and with time those chunks grow and get uglier. Anyone worked with FFmpeg might take a pleasure looking at mpegvideo in libavcodec, libswscale and libpostproc (especially if you look at the versions from about 2010).
So there are two ways how to deal with it — evolution (slowly change interfaces in hope to be better one day, deprecate stuff etc.) and revolution (simply forget it and write a new stuff from scratch).
In this and following posts I’ll describe a new framework (or whatever buzzword applies here) NihAV (Not-Invented-Here Audio-Video). Maybe I’ll even implement it for my own needs and the name should hint how much I care about existing design decisions.
my solution, just include other implementations.
why not put virtualdub’s avi demuxer in lavf ?
or vlc demuxer, or xine or all of them.
would look like this: ffmpeg -demuxer vdub -i file.avi
not only would lavf then support the most number of files, it would also probably be the least amount of work. why fix the wheel if you can just hammer on 20 more wheels? 🙂
i think kmplayer (not the kde frontend) dot com one does this. it has “engines” and “cores” and all of that.
Reminds me of http://rogerburrowsimages.com/wp-content/uploads/2012/06/BC11.jpg
And I can have whatever solution I like — try to blame the project with such name to be reinventing the bicycle. On the other hoof the less external dependencies the better.
FFmpeg supports that with DCADec, and libx264 to name a few, but the problem; from what I’ve seen in my limited experience, is that the problems have just compounded, bad design has just bred an endless supply of bad design.
Also, it’s not like people writing codecs wouldn’t look over the FFmpeg source and white paper for the codec they’re working on.