The K-Zone: QMPlayer project status

This page describes my experiences and progress in porting MPlayer, the popular Linux media player, to the Archos PMA430. Please note that this software is, as yet, unsuitable for general use -- there are still far, far more non-working features than working features. It is not clear at this stage whether a complete port is even remotely practicable and, if it is, whether there will be any of the original MPlayer code left at the end.

Why MPlayer on the PMA430?

Doesn't the PMA already have decent media capabilities? Well, it does; but the built-in media player has a number of significant limitations, which are not present in MPlayer.

The Archos media player is file-based, not stream-based. There is no prospect of it ever being able to play network streams in its current form. This is true even where the stream is encoded in a form which it understands (e.g., MP3 or WMA). MPlayer is stream-based; its codecs and demultiplexers do not care where the data comes from -- it's just data
The Archos player is not easily extensible. Although Archos has published an API for media player plug-ins, there is no general framework for managing audio codecs, video codecs, demultiplexers, or stream handlers separately. If, for example, you wanted to support a different video codec type within the AVI file format, you would have to re-implement all the AVI stream handling and demultiplexing logic, as well as (potentially) a full set of audio codecs. You would also have to handle all the AV synchronization issues that arise. MPlayer has separate APIs for stream handling, demultiplexing, audio decoding, and video decoding, and AV-sync is dealt with generically, not dependent on the codec. So, if you wished, you could provide a new video codec without touching too much of the other code
MPlayer already supports a huge range of file formats and codecs

Why not MPlayer on the PMA430?

Making MPlayer run properly on the PMA430 is an extremely daunting task, and may, in fact, be impossible. Why?

The PMA has no floating-point math support in hardware. All floating point operations have to be done using CPU emulation. Combined with the PMA's rather slow CPU, this means that there is no realistic prospect of any codec that relies on floating-point operations ever working on the PMA. MPlayer's WMA decoder, for example, which relies heavily on floating point sin(), cos(), and sqrt() operations, is five times too slow to run on the PMA, even at 100% CPU usage. My experience is that this decoder doesn't work fast enough on 400 MHz ARM-type CPUs either, so the PMA doesn't stand a chance.
In practice, the only MPlayer codecs that use only integer arithmetic are the MPEG I and II, and Ogg/Vorbis codecs. All the other common formats require floating point support. It may, perhaps, be possible to create an automated scheme to convert all the MPlayer codecs to use only integer (or fixed-point) arithmetic but, if not, it will be necessary to convert manually all except the MPEG codecs.
The PMA CPU is too slow to decode most video streams, even with integer-only arithmetic. Even technically-trivial tasks such as colourspace conversion place an inordinate load on the CPU. These jobs will have to be done using the built-in DSP unit, not the CPU. At present, Archos has not released any details of how the DSP is integrated into Linux, if at all. Without substantial reverse engineering, there is no realistic prospect of playing anything except very small, low bit-rate MPEG video streams
MPlayer has no graphical user interface that would lend itself to be converted into a Qtopia application. Converting MPlayer into a Qtopia GUI application is not merely desirable for this effort -- it is essential. The reason for this is that the Archos framebuffer API only works within the context of a Qtopia application. You could not use a console-mode MPlayer to write data to the framebuffer under the control of another, GUI application (which is how ZPlayer and Kino2 work). The user interface must be fully integrated and, as there is no code of this type in open source, will have to be done from scratch

How things stand at present

Here is what I have done so far.

grafted a rudimetary Qtopia user interface into the basic MPlayer code. This UI has basic playlist support, and elementary transport management (stop, start, seek);
written an MPlayer driver for the PMA's video framebuffer and image scaler. This driver does hardware scaling of images to the PMA's screen size, and this is quite fast. It also does inaccurate (but fast) conversion of the YV12 colourspace that most MPlayer codecs output, to the YUV422 colourspace that the PMA requires. Any codec that does not output YV12 or YUV422 stands no chance of working at present -- colourspace conversions will have to be added for all the other formats;
modified MPlayer's audio output to work properly with the PMA's buggy audio driver;
fixed a number of bugs in MPlayer related to byte-ordering.

So what works properly?

MP3 and Ogg/Vorbis audio streams play quite well, either from disk or network sources. They can be streamed as Icecast or Shoutcast, or in plain MP3/Ogg format.
Most of the stream handlers and demultiplexers seem to work, to the extent that they deliver the correct data to the codecs. This includes RTSP, MMS, and ASF streams (but they don't necessarily play -- see below)
The user interface is basically usable, although not exactly feature-rich. Improving the UI is the least difficult task ahead

What sort-of works?

Audio and video streams based on MPEG I, II, or 4 (e.g, divx), carried within MPG or AVI files, will generally play, after a fashion. However, only very small, very-low bitrate video streams will play well enough to watch, and even then it's marginal
WMA audio streams do decode properly, but too slowly to listen to

What doesn't work at all?

The MJPEG codec, even though it is integer-only and ought to be relatively fast. Getting this to work is a high priority for me, because this is the format that my digital cameras use
RealAudio of any type

The future

Getting MPlayer to work properly on the PMA is a daunting task, and not one to be undertaken by a single person. Whether it is worth continuing depends on Archos's plans for the future of the PMA. For all we know, Archos may be planning an upgrade to the media player which includes streaming support and additional codecs. If they are, then there's little point continuing with this effort. What we really need are another half-dozen developers on the project -- please contact me if you are interested :)

Screenshots

Here are some screenshots of QMPlayer in action. Sorry about the picture quality -- these are real snapshots, taken with a camera :)

	Playing an MPEG movie
	Same movie, fullscreen mode
	Playing an Icecast radio stream