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

1. 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)!
2. 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.
3. 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).
4. 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)
5. supports both (most) Pocket PC and MS Smartphone models (unfortunately, WM5+ only)
6. given that it’s the first version, pretty much promising

The bad

1. 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 ).)
2. bad MP3 playback, very sensitive to CPU usage peaks – the same problem as with NoteM and unlike ANY other MP3 player for Windows Mobile
3. no WMA support
4. very-very rudimentary interface (albeit the D-pad and the Smartphone dialpads work for control)
5. 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
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),

1. hope the developer develops it further and/or
2. 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
3. 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.

Microsoft MVP - Mobile Devices, 2006, 2007. See my PPC & SP blog HERE.

    

Doesnt sound like a tcpmp replacement, but if realplayer audio/video gets so it plays ok in it, im sure it will be popular, b/c the actual realplayer software sux.

Dell Axim X50
Windows Mobile 2003SE
Think Outside IR Keyboard
8GB CF Card (Apps, Movies)
2GB SD Card (Music)

Best Pocket PC Freeware Sites:
FreewarePPC
Pocket PC Freewares
PdaGold Freeware

"If it aint broke, don't fix it..."

 

I am listening ;-)

We would love to do nothing more then add support for the Real and Flash formats within the CorePlayer Platform, but note that it is NOT under our control.... Its all about the control that both Real and Adobe have on their respective formats.

Specifically... I would like to see both of them extend support for their format from outside applications but still within their players... (and yes it is possible). Simply put, this would still allow the control for which they desire, but also increase the proliferation of their formats/platforms/codecs/containers.

FYI... in regards to the MPlayer Mobile port... and take this with a grain of salt from my slanted point of view.... I would really like to commend their efforts.... But I feel overall that it is a fruitless effort (from a design perspective) to get more optimization. While it might be possible to squeak maybe low double digit improvements... don't expect anything major.

I don't think RealOne would - and, currently, the biggest problem is that of RealPlayer (this is why I think at least the MPlayer Real modules should be, in some way, integrated into CorePlayer); most importantly, the lack of VB video and HTTP streaming support.

The Real folks haven't touched their Pocket PC player for more than five years... That is, they have completely abandoned the platform (they've been a supporter of Symbian instead) and I don't think they would ever release anything for it.

Microsoft MVP - Mobile Devices, 2006, 2007. See my PPC & SP blog HERE.

    

Real is making more money with Gaming and Rhap then anything else... their OS efforts have all but stalled a long time ago because adopters finally realized the limitations of what they were 'really' adopting... a closed ecosystem.

@Betaboy from your comments i understand you state that corecodec has a competitive advantage (less cpu, better memory etc) I was wondering can someone embed corecodec decoding on their applications? meaning corecodec to handle the decoding and give to an application a pointer with the YUV data and a pointer with the PCM audio syncrhonized thus enabling a developer to use it as he likes.

@Menneisyys I was not able to find the source code of the WM porting? Can you please inform me were i can find the sources for WM (patches etc)?

Regards

Ask the original author four sources: Updated!! Mplayer port for Windows Mobile! - xda-developers

Microsoft MVP - Mobile Devices, 2006, 2007. See my PPC & SP blog HERE.