For one of my friends – Lost Eden finally running on Amiga.
(screen grabber output only HAM8 CDXL thus screenshot quality is not the best, click it for fullsize version).
Though someone should write HNM4 decoder one day…
Once I’ve stumbled upon High Priority Free Software Projects at FSF. The idea appealed to me so here I present similar thing for Libav. It also has one or two sane proposals (hopefully) and offers the same level of support (i.e. none). But maybe in some cases we or I can help with it.
avserver
;libswscale
replacement. The one that doesn’t sap sanity when you look at its code. Maybe with a nicer API too. And better pixel format support.Too bad I cannot even find a decoder for On2 AVC nowadays. We have some samples though.
This company has at least four screen codecs that we don’t support (MSA1, MSS2, MTS2 and CGDI).
There’s one codec I’d like to have reverse-engineered and implemented as an opensource decoder (well, lots of other codecs as well but this one particularly). Its name is VoxWare MetaSound, that’s an old codec which was used as an alternative to MP3 in old days of DiVX 3 😉 and its clones.
It’s definitely based on TwinVQ and is probably closer to the variant that got into MPEG-4 Audio standard (I suspect that mostly to make that standard even more bloated than before). That figures from having such modes like 8kHz/6kbps which is not present in VQF but present in ISO 14496-3 draft.
This codec probably has more data tables than TwinVQ (in binary decoder the section with codebooks is more than 256kB large, in TwinVQ it’s about 200kB) and should set a new record if we ever get a decoder for it.
Decoding looks very simple in theory: decoder initialises codebooks for given samplerate and bitrate (it’s actually signaled in extradata: VOXq for 44.1kHz/32kbps, VOXk for 16kHz/16kbps, VOXz for 44.1kHz/48kbps), for every frame it reads window type and an array of some values and performs reconstruction.
So far I was able to identify only some codebook information. Bark tables seems to be identical, but shape and whatever codebooks seem to be different.
I’ve spent a couple of evenings finding out that information and I dare someone (especially you, Vitor!) to write a decoder for it. I don’t know a thing about TwinVQ except one fact and it’s stated in the title.
I’ve spent two weekends and finally REd and wrote decoder for Re* Audio Lossless Format. With news like these I can deliberately call it Intel Audio Lossless Format.
So, what codecs we’re lacking so far?
Feel free to send any useful information about them, preferably working decoders of course.
After that we can claim full support of Real and Intel codec family.
Sometimes when I have an acute nostalgy I try to cook something from my homeland.
First time I made
Köttbullar (med potatis och lingonsylt självfallet). Too bad I could not do it SWEDISH STYLE! :-(. This time I tried to make Janssons frestelse. Jag hade inget burk ansjovis men bohusmatjessill i stället blev lagom bra.
With the addition of VBLE decoder I thought once again about codecs and how they are written.
There are two approaches:
Lots of people try it, find that their codec is faster/compresses better than HuffYUV and release results. Usually those codecs don’t live long and the only bad thing about it is they being released to public in the first place.
The codecs are usually more complex, so there are less of them. But there are more ways to create one.
The main problem with these codecs is achieving good compression parameters without much hassle. For example, libavcodec MPEG-4 encoder may be the best around here but (like Soviet machinery) one has to work real hard to find out which parameters he/she needs to set to which values to get good compression. That’s the reason why people often choose Xvid instead.
There is one approach to those: add lots of crazy filtering (usually several chained filters) and equally crazy coding of residues. There you got it. Simple filters = faster compression, complex filters = slightly better compression with significantly longer compression times.
Last abstract from lossless video codecs applies to audio as well.
Those appear not too often because it’s very hard to satisfy everybody’s ears. Thus (IMO) it’s mostly limited to speech codec development. And there’s Xiph of course.
Time from time there are mails from FFmpeg developers to different distributions saying “Oh, we are better, have more features and more secure, pick us and not libav”. In case somebody wonders here are two examples: Ubuntu and Debian.
So let’s walk through and see the claims. Comparison was made from git snapshots made 2011-10-15 11:00 CEST.
More codecs
FFmpeg claims to have more codecs. In numbers that’s true. Let’s see what are those codecs though:
In conclusion, those additional codecs supported by FFmpeg are either hardware acceleration (VDPAU, CrystalHD, stagefright), trivial or some old patches previously rejected but now picked up to maintain impression of superiority.
More muxers and demuxers
Now to muxers and demuxers.
Most of (de)muxers are either for formats we don’t support or trivial. But I admit there are maybe two demuxers and one muxer that can be included into libav after some cleanup.
Filters
I’m not fully familiar with filter subsystem but it still has too many problems and having an ugly wrapper for MPlayer filters (which are also not of the highest code quality) was one of the points that drove FFmpeg-libav split.
Features, security and overall
When FFmpeg claims to have more features than libav it’s true — they merge everything from libav nowadays. And FFmpeg gets more side features for two reasons: the name is more known and it’s easy to get a feature in because nobody seems to bother with proper reviews nowadays. As for security, it’s the same. For example, when there was a report for some minor security flaw in Chinese AVS decoder, original patch from security investigators (applied in FFmpeg) just made decoder more secure but it still crashed on that file, in libav we created our own patch that dealt with both of these problems. FFmpeg often reminds me of a saying “Socialistic system successfully overcomes the problems it creates itself”.
In conclusion, my opinion is that FFmpeg is trying to compete with libav by lowering standards on accepted stuff. Hence the name of this post.
And I’m glad we can’t have commits like this. For those who have not so good C understanding: it compares addresses of two different strings and it’s an undefined operation that works mostly by luck. So my advise is simple: if you want quality then choose libav, if you want some special features — look for suitable fork at github.
There are some codecs that I’d like to RE (mostly for completeness sake) but I don’t have time for that.
Intel Audio Codec
This one seems to be a lot like its predecessor IMC (Intel Music Codec), it even codes coefficients the same way but with different codebooks. I’ve tried to hack IMC decoder to make it use proper tables but it still decodes garbage.
Along with Indeo4 decoder it would make our Intel codec family complete, but unfortunately we have decoder for neither.
ClearVideo
The codec that was present in AVI, QT and RealMedia. My investigations showed that it was not-so-fractal codec, it still codes blocks with DCT and even does that in simpler fashion than H.263. Though a patent assigned to Iterated System describes what can be the base of this codec: DCT-based codec that uses fractal search to determine the best code for the current block or something like this. Maybe that’s the reason why there are no Huffman tables in decoder while it obviously uses some.
RALF
That’s rather special lossless codec that stands aside from other RealMedia codecs: the file format was altered for that codec (so far I’ve seen only standalone RALF files, not, say, RV40+RALF).
It looks like the codec is rather simple and employs context-dependent codes instead of generic ones. I remember finding about eight hundred static Huffman tables in decoder for that purpose.
Also codec developers were very grateful to their source of inspiration, that’s why codec IS is “LSD:”.
WMA Lossless
Nothing much to say about it. As I remember, it uses infinite impulse response filters for compression and least squares method for finding (and maybe updating) filter coefficients. Should be not so hard to RE but nobody bothered so far.
M$ Screen 1 and 2 (aka WM Screen)
I’ve dabbled in REing MSS1, not MSS2 (which was later relabeled as WM Screen) but they should be related.
MSS1 was rather simple screen codec based on classic arithmetic coding (with adaptive models too IIRC) and binary partitioning. So decoding process was simple: get point for subframe division (horizontal and vertical) and modes for decoding those partitions (fill, skip, subdivide).
VoxWare MetaSound
This codec is obviously based on TwinVQ, it even has similar huge tables for different samplerates and bitrates and I found almost the same header reading code.
In conclusion I want to say that if somebody wants to RE those codecs he’ll be more than welcome (especially for Apple ProRes but I don’t care about it much).
I’m rather picky person, so I don’t drink alcohol, try to avoid drinking Coca-Cola or Pepsi and hate still water (especially Danish one). So here’s my review of what I could drink in different countries.
Ukraine
There are many different soft drinks, mostly of mediocre quality, but some are quite good. There are some good mineral waters too (the best one is hard to find outside the region where I lived, sometimes it’s hard to find there as well).
And usually drinks are sold in all varieties of bottles — from 0.5l to 2l
Germany
Mostly you get here is very good selection of mineral water, Apfelschorle and variations of Spezi (aka tyska oriktiga Trocadero). There are also some strange flavours like cherry+ginseng or bitter lemon (tastes mostly like lemon skin). Oh, and 0.5l bottles for those drinks made by Coca Cola company (seems Germans prefer local inventions to their main product) look like designed by Norwegian, the bottle is made from too thick plastic and maybe it was designed in 3D CAD without Bezier curves support.
Switzerland
Mostly the same as in Germany but with more pathos and higher prices (while in Austria Apfelschorle is called something like “sprudel Apfelsaft”, in Switzerland I’ve seen “Shorley”). That goes for most Swiss products anyway.
Denmark
Those people seem to hate carbonated mineral water (usually Danish mineral water with gas has only two bubbles to distinguish it from still water) and the only time I tasted their drink it was too sugary.
Belgium
Looks like it’s better to buy orange juice there instead.
Finland
Very good selection of drinks.
Norway
Limited but rather decent selection of drinks. The bottles look like they were made from single piece of plastic mostly with axe.
Sweden
One of the reasons I love Sweden. Excellent selection of drinks, including special seasonal ones (Julmust and PÃ¥skmust). Here’s an example of PÃ¥skmust:
And of course, there’s the ultimate drink (IMO):
There are about eight different breweries producing it, I have tried it all except for two breweries.
And I have tried all but one soft drinks from Vasa Bryggeri. Probably I should go to Norrland again.
As for mineral water, they have Ramlösa, good water from Bergslagen region and even from the tap in many regions (it’s drinkable everywhere in Sweden, but tastes especially good in some places).
This is my look on what happened but I’ll try to remain objective.
A bit about me (in the very unlikely case you don’t know already and care). I’ve learned about FFmpeg in 2004 or so, just saw it along with other packages in Mandrake release. For several months I downloaded source snapshots at cybercafe (even dial-up was impossible then). I had long interest in general data compression methods and some interest in codecs sparkled by XAnim and desire to play M$ ADPCM files on Linux and FFmpeg got new decoders every week or so (mostly for packed YUV formats but nevertheless quite useful).
One day I tried to reverse-engineer some codec (just for fun), looked at sample produced by TechSmith Camtasia and realized that it’s packed with zlib and after some time guessed correctly they use M$ RLE. In order to test it I wrote a decoder and hacked it into FFmpeg. Eventually it worked and I send my decoder to Mike Melanson. On the 14th of August 2004 it was committed to FFmpeg codebase and it made me proud for my work for a week (those were the times!). After another decoder or two I’ve learned and started to read ffmpeg-devel mailing list (it was on SourceForget then). I think I started submitting my patches there with Indeo2 decoder or so.
After a while I was offered CVS commit access which I refused because of technical limitations. Finally in March 2006 I got display for my MacMini and I was ready for more active development. Google Summers of Code gave me opportunity to dedicate a bit more time for FFmpeg since I could say “hey, I’m payed for it!”. I still try to contribute even if I’m no longer student, have job and too little free time.
And now to the business.
As you may know, most active group of developers had disagreements on how FFmpeg was managed. First that resulted into an attempt to move old-style development elsewhere and reinstating new development under old name. Since Fabrice was in favour of old group and controls ffmpeg.org DNS entry, new model development group was forced out and now is known under a name of Libav.
But what is the root of disagreements? The “legendary” leader, Michael Niedermayer. Legendary in the sence that it’s a legend and not a reality.
At least since 2004 (when I joined the project) FFmpeg was rather a self-organizing community of developers, each with his own goals. Somebody wanted to play movie trailers encoded with QuickTime (hi there, Mike!), somebody wanted to play obscure game formats, somebody just wanted to support anything that he could reverse engineer (that’s me and probably Mike and other people as well). Diego Biurrun tried to bring project in shape by introducing formatting conventions (in early days nobody cared about style much), he and later MÃ¥ns RullgÃ¥rd made FFmpeg build system almost perfect, also MÃ¥ns and Baptiste Coudurier (and many other people) worked on improving or introducing support for common formats.
Later when FFmpeg started participating in GSoCs, at first it was handled by Mike and now by Ronald Bultje. Our test system — FATE started as Mike’s experiment for automated testing regressions for many parts. Later it was completely redesigned and rewritten by MÃ¥ns who also used a lot of his own hardware to provide test results so FFmpeg was tested on variety of platforms and compilers (most non-x86 things at our FATE are because of his work).
Bug tracking system was set up by Luca and he also found a hosting for it. A lot of services for FFmpeg were run on hardware of Attila Kinali (and even bandwidth and hosting for main server was his achievement). And recent Subversion -> Git transition with merging history from SwScaler is mostly done by Janne Grunau.
So, what’s the role of leader in FFmpeg? None! Almost every significant action was done by somebody else. Were they following some roadmap devised by him? There is no such thing either. Maybe it’s his social skills that kept community together? Wrong again, he caused some people to leave project (and not only the last year, Baptiste would serve good example) and different service maintainers too — by forcing his idiosyncrasies on project (like long-standing DTS guessing issue) or ordering service maintainers around.
And his role as lead developer has been diminishing probably since 2004. I can’t deny he did outstanding work on optimising H.263-based encoders and decoders and writing H.264 decoder, writing and developing some other stuff and providing reviews for patches. But what does he do in recent time? I can’t name anything significant. And from technical point he can’t serve as example: he never cared much about architectures beside x86 nor about his code being easily understandable.
Thus, some developers had had enough and forked. It’s still self-organized community with people contributing to what they seem important and nobody to order around (and not that much stalling on patch reviewing like in times of designated maintainers either).
This fork seems to moved murky waters and some trolls (mostly from MPlayer project that have no relation to FFmpeg at all) reappeared after long time; I cannot directly blame Michael on it but it seems suspicious for me. And the messages I’ve read on ffmpeg-devel between forking and creating Libav made me mostly disgusted, so I’ve unsubscribed from FFmpeg mailing lists and don’t participate in FFmpeg anymore. What goes there is not my concern anymore and I’m happy with Libav.
P.S. Also since most of new things in FFmpeg were introduced despite of him (like Git transition and releases), I can’t forget one historical analogy. In German “the leader” is “der Führer”, but that word is rarely used nowadays because there was another Austrian who completely spoiled its meaning.