Planet Xiph

Today, three of the worlds that I am really engaged in and that tend to not have much in-common with each other seemed to come to a sudden overlap.

The three worlds I am talking about are:

• Social video publishing (through my company Vquence)
• One Laptop Per Child (I am really keen to see more OLPC work in the Pacific)
• Open media software and technology (through Xiph and Annodex work, as well as FOMS)

I was positively surprised to read in this blog message that Dailymotion and the OLPC foundation have partnered to set up a video publishing channel for videos that can be viewed on the OLPC. The channel is available at olpc.dailymotion.com. You can view it on your computer if you have the appropriate codec libraries for Windows and the Mac installed. Your Linux computer should just support it.

To understand the full impact of this message, you have to understand that the XO (the OLPC laptop) does not support the playback of Flash video by default. OLPC cannot ship the official Adobe Flash plugin on the XOs because it is legally restricted and doesn’t meet the OLPC’s standards for open software. Thus, children that receive an XO are somewhat cut off from social video sites like YouTube, Dailymotion, Blip.tv, MySpace.tv, video.google.com and others, even though there are lots of education-relevant videos published there.

The XO however ships with video technology that IS open: namely the Ogg Theora/Vorbis video codec and software. This is incidentally also the codec that the next version of Firefox will be supporting out of the box without need of installation of a further plugin.

Unfortunately, most video content nowadays available on the Internet is not available in the Ogg Theora/Vorbis format. Therefore, Dailymotion and the OLPC Foundation launching this channel that is automatically republishing all the videos uploaded to the Dailymotion OLPC group is a really big thing: It’s a major social video site republishing video in an open format to enable it to be viewed on open systems.

The IETF has just ratified RFC 5334 “Ogg Media Types”, which I have co-authored.

The new Ogg MIME types are as follows:

• audio/ogg for all Ogg files that contain predominantly audio, such as Ogg Vorbis files (.ogg or .oga), Ogg Speex files (.spx) or Ogg FLAC files. The file extension recommended to be used is .oga, but .ogg will continue to be used for Ogg Vorbis I files for backwards compatibility.
• video/ogg for all Ogg files that contain predominantly video, such as Ogg Theora or Ogg Dirac files. The file extension recommended to be used is .ogv. Please stop using .ogg for Ogg Theora files, since that causes havoc for any application trying to determine which application to use for opening such a file.
• application/ogg used to be the MIME type recommended for any Ogg encapsulated file. This is obsoleted by the new RFC. Instead, application/ogg is a generic MIME type that can be used for Ogg files containing custom content tracks. This may e.g. be a Ogg file with 5 vorbis, 2 speex, 2 theora, 5 CMML, 2 Kate, and a custom image tracks. Such files have to use the Skeleton extension to Ogg to be able to describe the content of the file. The file extension recommended to be used is .ogx.

The RFC also specifies the possibility of using codec parameters to the MIME types to specify directly within the MIME type what codecs are contained inside the files. This may for example be “video/ogg; codecs=’dirac,speex,CMML’”.

More details on these decisions and on further considered MIME types are in the Xiph wiki.

Disclaimer: I had no influence on the funny number game that happened between the obsoleted rfc3534 and the new rfc5334.

Happy MIME-typing!!

(libSpiff 1.0.0rc1 was some kind of “internal release” so
let me properly introduce libSpiff 1.0.0rc2 as the union
of the changes in both.)

This release fixes the broken XML Base implementation
introduced in libSpiff 0.8.4. Besides general cleanup
it also introduces the base for a new error-handling model.
libSpiff now is at a point of feature completion so I
decided to start heading for 1.0.0.

Please note that this release is neither source- nor binary
compatible to libSpiff 0.8.4 (but both to libSpiff 1.0.0rc1).

• Download
• Changelog

Have you ever been haunted by an old open source package that you wrote once, published, and then forgot about?

The BSD community has just reminded me of the MPEG audio analysis toolkit Maaate that I wrote at CSIRO when I first came to Australia and that was then published through the CSIRO Mathematical and Information Sciences division.

The BSD guys were going to remove it from their repositories, because since I left CSIRO more than 2 years ago, CSIRO has taken down the project pages and the code, so there were no active project pages available any longer. I’m glad they contacted me before they did so.

Since it is an open source project, I have now resurrected the old pages at Sourceforge. They are available from http://maaate.sourceforge.net/. I have re-instated the relevant weg pages and documentation and updated all the links. I discovered that we did some cool things then and that it may indeed be worth preservation for the future. I expect Sourceforge is up to the task.

Thanks very much, BSD community and welcome back, MPEG Maaate!

Take the cab file format. It's present on every windows from Windows 95. If you use the LZW compression algorithm you get small archives.

986.875 oggcodecs.7z
1.150.890 oggcodecs.cab
1.618.917 oggcodecs.zip

It's better than zip and a bit worse as 7-zip.

The problem with cab file format it's that it's hard to use it in command line.

For example here is what you need to code to compress one directory into a cab file:

for %%i in (oggcodecs\*.*) do echo "%cd%\%%i" >> files.ddf
makecab /L . /D CompresionMemory=21 /D CompressionType=LZX /D DestinationDir=oggcodecs /F files.ddf
del files.ddf
move disk1\1.cab oggcodecs.cab
rmdir disk1
del setup.inf
del setup.rpt

Pretty hard core. One might say that this is not a tool to be used from a command line as rar or other popular archiving programs. This is done only once by me in a script file, so I can live with it.

The problem is with the extraction method. I have created a folder inside that cab file, which I can see with Total Commander, 7-zip File Manager etc, but with Windows Explorer I see directly the files, without the directory. There is one command line program which handles cab archives - expand.exe. Expand.exe doesn't know about directories in cab files, there is no switch to instruct him to preserve the directory structure from the cab file.

Why Microsoft? Why?

The solution is simple, create the destination folder first, d'oh!

As many of you know there's a Java applet ("Cortado") for playback of Ogg audio and video which originally was developed at Fluendo. Wikimedia is perhaps the best known "customer" of this applet and they since have forked it ( http://svn.wikimedia.org/viewvc/mediawiki/trunk/cortado/ ) as apparently Fluendo isn't really doing active development on Cortado anymore.

The Java Theora decoder used in Cortado is called "jheora". It is a ported version of an old C reference decoder, meaning it doesn't support the whole Theora 1.0 specification. This means that it won't decode Theora-streams created by "advanced" encoders like Monty's "Thusnelda" encoder.

Thusnelda is most likely going to become the new reference encoder, so we have a problem here.

I had a look into many options to somehow get an updated Java Theora decoder (e.g. port the new C reference decoder, which supports the complete Theora specification), but in the end I decided that just tacking missing Theora features onto the old jheora decoder may actually be the quickest way to get a robust decoder.

I'm positive that this may be the way to go and I was able to write a (biggish) patch to enable jheora to correctly decode Thusnelda streams: https://bugzilla.wikimedia.org/show_bug.cgi?id=15119

This patch is basically a complete rewrite of how quantization matrices are computed (interpolation, scaling etc. etc.) and implements proper handling of 4MV for partially coded macroblocks.

Still missing from jheora, but currently not used by any relevant encoder:

• support for subsampling other than 4:2:0 (personally I think that this isn't relevant for web-video, but it may be a nice-to-have).


• support for per-block quantizers. The patch already doing some decoding related to that (decode what quantizers are used within a frame) and it "just" needs finishing (decode what block is using what quantizer). Should be pretty straightforward to implement and debug once I have a fittingly encoded file.

To put it into a nutshell: jheora isn't completely unmaintained anymore ;-)

With an updated Cortado applet it should be pretty easy to bring HTML5 video (and audio) support to browsers not supporting Ogg codecs (e.g. Apple is shipping Java by default on OS X, so we can enable Ogg Theora/Vorbis playback with a tiny bit of JavaScript embedding the Cortado-applet instead).

I've released my first release of oggcodecs:

Current UNSTABLE Version (0.80.15039) - 14.06.2008
Changes this version

* Support for Microsoft Windows Vista
* Updated compiler to Visual Studio 2008 Express, which drops support for Windows 9x, NT 4.
* Updated libspeex to version 1.2 beta 1
* Updated libvorbis to version 1.2.1 (20080501)
* Updated libogg to version 1.1.3
* Updated libtheora to version 1.0beta3 (20080416)
* Updated libFLAC to version 1.2.1
* Fixed crash at the end of incomplete Theora files.

By using code signing with a certificate provided by Certum I was able to change how the oggcodecs installer looks on Windows Vista from this:



to this:



The name of the installer looks different, but my name is displayed under :)

I probably should have blogged sooner, but here it is: I'm the current maintainer for Directshow Filters for Ogg Vorbis, Speex, Theora and FLAC.

If you want a hardware Ogg Player you should consider buying a Trekstor product :)

The Foundations of Open Media Software workshop has just extended its deadline for submission of registrations requests with travel sponsorship.

FOMS addresses hot topics - such as the new <video> and <audio> tags in HTML5, the uptake and development of open video codecs like Ogg Theora, BBC’s Dirac and SUN’s OMS codec and their native support in Firefox, open audio & media frameworks and players such as gstreamer, ffmpeg, vlc or xine, or the standardisation of audio APIs across platforms. Further topics are listed in the CFP.

In previous years, FOMS has stimulated heated technical discussions and amazing new developments in open media software, such as the creation of libsydneyaudio, the uptake of liboggplay, the creation of Xiph ROE, or the creation of the new Ogg CELT codec.

Video proceedings of last years’ workshops are here. There are also community goals that were set in 2008 and 2007 and provide ongoing challenges.

You should definitely attend, if you are an open media software hacker. This is a chance to get to know others in the community personally and clear up those long-standing issues that need a face-to-face to get solved. Also, it’s a great social event not to be missed. As a bonus, you can spend the week after FOMS at LCA, the world-famous Australian Linux hackers conference, and deepen your relationships in the community. Come and join in the fun in January 2009, Summer in Hobart, Tasmania.