So in preparation for heading of to Gran Canaria and GUADEC on Thursday I pushed a new Transmageddon release today. 0.11 is actually the first release I posted to sites such as Gnomefiles and Freshmeat so in some sense I guess I feel more confident about this version that earlier ones. A lot of new features included, like multipass encoding, videoflipping (so if your video is 90 degrees tilted you can correct that during transcoding) and better profiles. Still kinda rough at the edges though, and the very latest GStreamer releases are needed for everything to work. Still expecting quite a few bugs to be reported still.
In some sense development have stood still for a while as I have focused on testing various devices and GStreamer features. Remuxing is still on my todo list, but discovered that for instance an ac3parser is still needed in GStreamer to
do nice DVD conversions.
Was kinda nice to successfully use Transmageddon for a business related need at work, we had gotten a request at Collabora Multimedia which meant I needed to transcode a video into quicktime+h264+aac from a .vob file. Worked like a charm :) I mean while I have of course done hundred of transcodes as part of development, it was nice to do one for something ‘real’ :)
After updating to Fedora Core 11 I noticed a new feature, the automatic font download system. Essentially it works like the automatic codec download system we have in GStreamer, but for fonts.
So judging by how often the font download box pops up the spam I am getting these days seems to be mostly in 3 languages Coptic, Syriac and N’Go :) I have to assume the spams are using random character sets to confuse spam filters, as I doubt that for instance either the ancient egyptians or their Coptic descendants of today are a big enough demographic for the spammers of the world :)
Some time ago I put out a request for someone to pull the AMR code in Android out and turn it into GStreamer plugins. Well Iago Toral Quiroga did exactly that and thus we now got support for encoding and decoding AMR-NB in GStreamer, combined with support for decoding AMR-WB. This turned out to be an indirect team effort as the current code is a combination of the original Android code, combined with some API glue code developed by Andres Mejia and Martin Storsjö, combined with the old AMR plugins in GStreamer which was meant to be used with some non-distributable reference code. These 3 code bases Iago massaged together into something pliable. The current plan is to merge the patch once bad and ugly unfreeze and we finally got some decent AMR plugins for GStreamer. A big thanks to Iago and everyone else involved.
This effort also fit in well with a bug hunt I have been on for a while to figure out why Transmageddon was not able to create files my phone could play back. After having spent a lot of time expanding on the transcoding engine in transmageddon and testing every possible variation I could come up with, it was finally Mark Nauwelaerts here at Collabora Multimedia who came to my rescue with this patch. Also that getting merged after the freeze.
Also been testing the ASF muxer that Thiago Sousa Santos is working on as part of this years Summer of Code. It is coming along very nicely, with WMA2 and WMV2 muxing working. Hopefully when I do my new Transmageddon release before heading down to Gran Canaria I can include ASF support too. Already got a nice batch of features in git master with multipass encoding, a lot of bugfixing to the profile support, h263 and video flipping. So with the efforts mentioned above I should also be able to add AMR-NB and ASF/Windows Media support to the mix too. I also hope it is a long time until the next time I need to think about stuff like pixel aspect ratio versus display aspect ratio :)
I still need an icon for Transmageddon if someone is up for the task.
LWN got a really interesting article discussing how Google have included H264 and AAC support in their Chrome browser using ffmpeg and the legal discussion that has come from that. It seems Chris DiBona and the Google lawyers have decided they can work around the LGPL by licensing patents for the ‘application’ instead of for the library implementing the functionality in question. Of course most of us would think that if you ship a library as part of your application, it is a part of your application, but Chris DiBona seems to feel that he licensed the H264 codec for use with the bookmarks list of Chrome and not the media engine :)
More seriously though DiBona tries to weasel out of the situation by claiming that the language of the LGPL saying ‘For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. ‘ only applies if there is a specific language in the patent license hindering re-distribution of the code. He even manages to refer to the fact that the FSF made the language on this subject even clearer in the LGPLv3 as proof that his reading is correct. While at the same time claiming that what the FSF thinks about these issues is irrelevant.
Well I guess Chris is right about Google taking their responsibilities very seriously, at least as long as they say what he wants them to say :) Can’t help but feel that Google somewhere along the line went from ‘do no evil’ to ‘we are google, hence no evil can have been done’ which while sounding similar actually are very different.
Funniest part though is that another part of Google, Android, seems to think its not even legally fine to ship a LGPL media framework combined with Apache licensed codecs with their stack. But I guess the Android and Chrome departments have different lawyers, so if we are lucky maybe the Android department ends up suing the Chrome department ;) Or maybe Chris DiBona wakes up and realize he could resolve this issue quickly by combining the Apache licensed H264 implementation in Android with his ffmpeg stack and thus resolve this issue.