[Non-Touchscreen Windows Mobile Other] Menneisyys:
MPlayer is one of the most popular Linux/Unix media player. Now, thanks to XDA-Developers forum member amitv_17, the porting to Windows Mobile has started.

(the main screen on a VGA Pocket PC; as can be seen, the View menu doesn’t contain much; the Tools menu results in an immediate exit)

(176*220 screenshot; as can be seen, on the MS Smartphone platform, the left softkey’s Exit, as is expected)

Availability, compatibility, installation

It’s available HERE, in the official XDA-Devs thread (mirror HERE) and is, of course, a free download. It seems to be compatible with most WM5 and WM6 Pocket PC’s and Smartphones. It seems it’s incompatible with pre-WM5 operating systems (tested this on my WM2003 HP iPAQ 2210).

Unzip the contents of the file to anywhere on your Windows Mobile Pocket PC or Smartphone. Start it by executing mplayer.exe. Then, you can select local file or stream playback. Both are pretty straightforward; in the latter case, make sure you enter the direct RTSP URL as can be seen in HERE, not for example HTTP one. Let me know if you don’t know how you can get for example .RM RSTP URL’s from a HTTP .RAM file.

Supported formats

It’s, theoretically, compatible with several sound and video formats (see their list at the above Wikipedia page). In practice, playback is still hampered by the, in cases, VERY bad performance and compatibility.

In addition to my H.264 (video) playback tests, I’ve made pretty thorough CPU usage tests with the most important audio formats it supports. The following figures have all been measured on a Dell Axim x51v running at 624 MHz. As can clearly be seen (particularly if you take the MP3 playback CPU usage into account), the results aren’t particularly good – alternative (better) players all have lower CPU usage. See THIS for more information. Note that 11% at 624 MHz translates to 33% at 208 MHz – the forced CPU frequency in the tests used in the linked document.

Flac: 5%

M4A (AAC): 16%

Ogg: 30%

MP3: 11%

WMA: - (incompatible)

(I’ve used my standardized audio test files – they’re the same I’ll use in my forthcoming Multimedia Bible.)

Note that while the MP3 playback “only” requires about 11% CPU time at 624 MHz, it still has severe problems when running in the background: it stutters when there’s some additional CPU usage (for example, you open a menu or anything). That is, it’s basically useless when not run in the foreground, with nothing else running.

Video playback is much-much worse and practically useless, unless you try to watch really low-quality, low-resolution and low-bitspeed videos. TCPMP or, even better, CorePlayer (the latter is an undisputed king of video playback on all mobile platforms) are way better.

Finally, RealAudio steaming (one of the best features of even the current, initial MPlayer release) is a CPU hog too and is pretty useless on slower models (read: you must overclock your ~200 MHz TI OMAP CPU’s if you want to listen to RealAudio radio stations).

Let me present you a list of the strengths and weaknesses of the current version:

The good

a HUGE arsenal of codecs and communications protocols already available; in this respect, it’s even better than CorePlayer (which, as of now, doesn’t support RTSP, albeit it will really soon be added)!

supports even RealAudio / RealVideo, unlike CorePlayer / TCPMP / ANY other Windows Mobile player (other than RealOne’s own player, of course). Note that the CoreCodec folks have announced (before the port of MPlayer) that they would never add RealOne support to CorePlayer because it's a proprietary format.

alternative HTTP tunneling with RTSP; working just GREAT with RealAudio streams! In this respect, it’s even better than RealPlayer on Symbian S60v3 FP1 (for example, the one that comes with the Nokia N95), because not even the latter supports HTTP RealOne audio/video streaming, “only” for MPEG4 video streaming (unlike HTC’s own and, in this respect, really incapable Streaming Media on Windows Mobile – see THIS for more info).

supports real (UDP-based) RTSP, which means better bandwidth utilization than with HTTP tunneling. Of course, it also means you must have direct access or a capable Wi-Fi network. This will only later (hopefully still this year) be added to CorePlayer (see THIS recent announcement if interested)

supports both (most) Pocket PC and MS Smartphone models (unfortunately, WM5+ only)

given that it’s the first version, pretty much promising

The bad

HUGE CPU usage when playing back streamed audio! For example, on the 195 MHz HTC Wizard, the CPU used for about 100% while playing back streamed, while on the 520 MHz XScale HTC Universal, running at 520 Mhz, about 97%, as can also be seen in THIS screenshot. On the 624 MHz Dell Axim x51v, it was “only” 72%. This means it’ll chew through your battery VERY fast and you won’t be able to use additional goodies like A2DP encoding at the same time without introducing MAJOR skipping. Note that this CPU usage is independent of the networking protocol used: with both UDP/RTSP and HTTP, the CPU usage is equally high. (Tested by trying to play back THIS Finnish stream (direct RM link: rtsp://ra.yle.fi/live/radiopeili.rm ).)

bad MP3 playback, very sensitive to CPU usage peaks – the same problem as with NoteM and unlike ANY other MP3 player for Windows Mobile

no WMA support

very-very rudimentary interface (albeit the D-pad and the Smartphone dialpads work for control)

streaming MPEG4 videos doesn’t work (as opposed to RealAudio); screenshots (trying to play back the stream rtsp://rtsp.youtube.com/youtube/videos/_CUFEnZeeYw/video.3gp?warned=1 ): 1 2 3 4 5 6

local (as opposed to streamed) MPEG4 videos do work. They are, however, very choppily played back; on VGA devices, only part of the screen is used as can be seen in THIS screenshot. The CPU usage is pretty bad too: on the x51v, playing back a 640*480 30 fps 2.6 Mbps H.264 video (taken on the Nokia N95 in high quality TV mode) took 80% CPU time (and still produced between 1 and 5 fps video, the video absolutely lagging compared to audio). CorePlayer 1.1.1, on the same PPC, played back the video without any frame drop and excellent high-resolution VGA – using the CPU only at 60%.

Verdict

It’s certainly nice to welcome Mplayer on Windows Mobile. While it’s a far cry away from established media players, particularly video playback-wise (in which it’s (still?) orders of magnitude worse than both TCPMP and, particularly, CorePlayer),

hope the developer develops it further and/or

he joins the CoreCodec team or sells / gives them the RealOne decoders so that CorePlayer, finally, receives support for these, particularly in streaming, widely used formats (can you hear me, CoreCodec team?! Now, it’s time to add RealOne support to CorePlayer! We DO need HTTP-based access to streamed content, which the official RealOne player is incapable of!) and

currently (as long as you don’t use a hard-to-configure Virtual Private Network) it’s your only way to play back RealAudio-based radio stations (if you can live with the enormous CPU usage, that is)

Finally, please consider donating the developer (donation link in the original XDA-Devs thread) so that he will continue working on the port.