The projects (FFmpeg / Libav) just got a WMA lossless decoder. For those keeping score, this means that there are open source methods for decoding every single one of Microsoft’s proprietary audio codecs (Windows Media Audio, or WMA): WMA v1, WMA v2, WMA9/Pro, WMA Voice, and now WMA lossless. Currently, it’s only advertised to decode 16-bit audio (no 24-bit). Also, when I first tried it a few days ago, it didn’t decode the very end of the single sample file I concocted many years ago (luckynight.wma). But that might be cleared up by now.
Some other recent developments in the projects that I wanted to call out: An encoder for the Apple ProRes encoder from Kostya; XWD (X window dump) image decoding and encoding from Paul B. Mahol; a Sun rasterfile encoder from Aneesh Dogra.
And then there’s the new playback system for CDXL files, also courtesy of Paul B. Mahol. I wasn’t familiar with this format until I wrote this post, which is surprising, given the format’s vintage. This was a CD-ROM FMV format favored for Amiga computers. Here it is in all its 160x120x10fps glory:
That’s the amigaball.cdxl sample available in the repository. The sample is 3835910 bytes large and plays for about 24 seconds. This yields a data rate of about 159 kbytes/second. So, yeah, single-speed CD-ROM FMV.
I think I have to confirm your observation. But it is not clear if that data is in the actual bitstream.
i was surprised just how many people used prores. hopefully we can collect some more video production/raw/broadcast codec support and replace a lot more proprietary crap software! mwahahaha.
@Benjamin: I created all of those luckynight.* samples so I would expect the full WMA file to be complete. When I compare the output against the original (also on the archive), the WMA comes up short. Up until the file length discrepancy, the data is identical, though.
It’s possible that the encoder screwed up when creating the file, though I don’t have any way to demonstrate that immediately.
I got the impression that FFmpeg already had a ProRes encoder. (maybe since 4 months ago?) Thus Kostya’s encoder, kind of repeats the saga with the decoder. Of course the new encoder have few improvements… but that’s not really the point.
It is amazing how much time and effort LibAV masters waste to avoid merging code from FFmpeg.
@iive: According to the git logs, the first iteration of the ProRes encoder landed on February 2 of this year.
I’m with you, though, regarding the cross-merging. It’s exhausting just to observe. I can’t imagine being responsible for keeping it all straight.
February 2 is when the file have been renamed to a new name in order to avoid merge mess with the upcoming Kostya’s encoder. You know git doesn’t track name change, but it could detect it by tracking the content.
The original file is from 29 October 2011 (70bab5847e12e50…). You can see the ProRes encoder in the release log of FFmpeg 0.9, dated 11 December 2011.
@iive: I get it. So we really should be venting our frustrations towards git, and not the FFmpeg/Libav split. :-)