Related
Have you ever wanted to listen to radio stations on the Net? With
the advent of the pre-3G technology EDGE, which, with most network operators, is sufficient for listening to most (if not all) radio stations on the Net (let alone 3G, of course),
the proliferation of unlimited data contracts
and, last but in no way least, the really revolutionary, bandwidth-saving, "high-quality stereo even over slow GPRS connections" AAC+ (also known as HE-AAC, aacPlus etc.) streams becoming common,
they have become accessible to almost everyone with a connected mobile device (for example, a mobile phone) on both the Windows Mobile and the Symbian platform. (Note that the final version of the article / chart will also have extensive info on the seriously enhanced Pocket Tunes 4.0 on the Palm OS – that is, it’ll cover no less than THREE mobile operating systems!)
In my forthcoming article, I discuss for example the following questions:
What radio stations there are?
How you can access them?
What should you pay attention to, depending on whether you’re on an unlimited contact, and/or super-slow GPRS connections?
Which radio client to choose, depending on your needs?
Note that I still haven’t decided whether I should publish the Multimedia Streaming Bible as a separate entity, or, part of my (even larger) Multimedia Bible. There are both pros and cons in both approaches:
Pros:
I can publish it in the next one or two days – you don’t need to wait some 1-2 additional weeks for the Bible to be, finally, published
Separating these pretty disjunctive subjects greatly help in reducing the size of the Multimedia Bible. This would be pretty much welcome as it’s going to be BIG. Very big.
Cons:
It’ll miss a lot of information I’ll only give you in the “big” Multimedia Bible like equalizer support, hardware button support, alarm / sleep shutdown functionality, screen dimming etc. That is, the Streaming Bible will only contain information strictly related to audio streaming and will not contain other info, which may make it easier to choose from the given apps. (This missing info, however, WILL be present in the final Multimedia Bible – sometimes later.)
And yes, before I forget about it: HERE’S THE CHART. Do check it out, do comment it, do send me flames and/or greetings. And, do enjoy the information not readily available anywhere else - for example, many people have been hunting for an AAC+-capable player for ages (see for example THIS). Yes, noone has actually published a tutorial on what players are able to play these streams.
It contains both protocol compliance reports, battery life-related remarks (with Windows Mobile, in CPU usage percentage; with Symbian, in Watts) and some other goodies like whether they’re able to record the radio stream.
Again and again, as has already been pointed out above, the chart mostly contains strictly (audio) streaming-related info. That is, I haven’t for example elaborated on stuff that I’ll discuss in the final Multimedia Bible. Subjects like these are equalizers, button handling, AVRCP compliance etc. I’ve mentioned SOME of these in the Pros / Cons rows at the bottom but, except for the links, the price and the MOST important compatibility information (for example, Mundu Radio’s not really supporting (W)VGA Pocket PC’s). These questions will ALL be covered in the chart targeted at the wider audience (not only those that want a radio client).
Also note that I don’t discuss Orb and the like in here; they’ll only be elaborated on in the final Multimedia Bible. The same stands for video streaming, LAN access and UPnP. With this Bible, my “only” aim is to give you a complete picture of listening to the already existing, remote radio stations on the Net.
Added the just-released Kinoma Play 1.0 and Spb Online 1.0 to the chart. See my Spb Online review for more info.
Have you ever wanted to listen to radio stations on the Net? With
the advent of the pre-3G technology EDGE, which, with most network operators, is sufficient for listening to most (if not all) radio stations on the Net (let alone 3G, of course),
the proliferation of unlimited data contracts
and, last but in no way least, the really revolutionary, bandwidth-saving, "high-quality stereo even over slow GPRS connections" AAC+ (also known as HE-AAC, aacPlus etc.) streams becoming common,
they have become accessible to almost everyone with a connected mobile device (for example, a mobile phone) on both the Windows Mobile and the Symbian platform. (Note that the final version of the article / chart will also have extensive info on the seriously enhanced Pocket Tunes 4.0 on the Palm OS – that is, it’ll cover no less than THREE mobile operating systems!)
In my forthcoming article, I discuss for example the following questions:
What radio stations there are?
How you can access them?
What should you pay attention to, depending on whether you’re on an unlimited contact, and/or super-slow GPRS connections?
Which radio client to choose, depending on your needs?
Note that I still haven’t decided whether I should publish the Multimedia Streaming Bible as a separate entity, or, part of my (even larger) Multimedia Bible. There are both pros and cons in both approaches:
Pros:
I can publish it in the next one or two days – you don’t need to wait some 1-2 additional weeks for the Bible to be, finally, published
Separating these pretty disjunctive subjects greatly help in reducing the size of the Multimedia Bible. This would be pretty much welcome as it’s going to be BIG. Very big.
Cons:
It’ll miss a lot of information I’ll only give you in the “big” Multimedia Bible like equalizer support, hardware button support, alarm / sleep shutdown functionality, screen dimming etc. That is, the Streaming Bible will only contain information strictly related to audio streaming and will not contain other info, which may make it easier to choose from the given apps. (This missing info, however, WILL be present in the final Multimedia Bible – sometimes later.)
And yes, before I forget about it: HERE’S THE CHART. Do check it out, do comment it, do send me flames and/or greetings. And, do enjoy the information not readily available anywhere else - for example, many people have been hunting for an AAC+-capable player for ages (see for example THIS). Yes, noone has actually published a tutorial on what players are able to play these streams.
It contains both protocol compliance reports, battery life-related remarks (with Windows Mobile, in CPU usage percentage; with Symbian, in Watts) and some other goodies like whether they’re able to record the radio stream.
Again and again, as has already been pointed out above, the chart mostly contains strictly (audio) streaming-related info. That is, I haven’t for example elaborated on stuff that I’ll discuss in the final Multimedia Bible. Subjects like these are equalizers, button handling, AVRCP compliance etc. I’ve mentioned SOME of these in the Pros / Cons rows at the bottom but, except for the links, the price and the MOST important compatibility information (for example, Mundu Radio’s not really supporting (W)VGA Pocket PC’s). These questions will ALL be covered in the chart targeted at the wider audience (not only those that want a radio client).
Also note that I don’t discuss Orb and the like in here; they’ll only be elaborated on in the final Multimedia Bible. The same stands for video streaming, LAN access and UPnP. With this Bible, my “only” aim is to give you a complete picture of listening to the already existing, remote radio stations on the Net.
Introduction
What is Universal Plug and Play (UPnP) and why you might want to make use of it? To get a nice overview what it’s all about, spend some time on reading the Digital Living Network Alliance (DLNA) tutorial’s first three pages HERE, HERE and, finally, HERE. These pages are also interlinked so you can just safely follow the “Learn how DLNA works” link at the bottom of the first page. I especially recommend the interactive “What can you do with DLNA products?” section at the bottom of the third page. Try selecting all the possible pairs to see what a particular device pair can be used for - this demo is really instructive. An example screenshot showing what for example the NAS & networked TV pairing can be used for:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Pretty instructive, isn't it? Again, I really recommend playing with the different pairings so that you get a clear picture of what UPnP can really be used for. In addition, please PLEASE do read the above DLNA intro (the three pages) so that you understand what UPnP is about and the terms used in this UPnP Bible. I’ve refrained from reproducing (almost) the same info in here so that I could concentrate on the more important and never-before-published subject: how this all works on the two most widely used mobile platforms: Windows Mobile and Symbian.
You might also want to take a look at the Wiki page (most importantly, the “UPnP AV (Audio and Video) standards” section) but it’s highly technical and, for a non-pro, in no way as comprehensible as the DLNA tutorial. Note that the DLNA tutorial doesn’t explain what “Controllers” are. It’s, as has also been explained in the Wiki (officially referred to by “MediaServer ControlPoint”), is like a remote controller between the source (the “MediaServer”), that is, typically a file store, and the target (the “MediaRenderer”); that is, typically, a TV set, a monitor or a home Hi-Fi.
On both Windows Mobile and Symbian (more precisely, the latest-generation, N-series Nokia handsets) all these three functionalities are supported:
a phone can act as the source (“MediaServer”) of multimedia content (for example, the pictures you’ve taken with the built-in camera; the MP3’s you have on your storage card etc.)
it can also act as the mediator (“MediaServer ControlPoint”) between the server and the renderer. That is, it can select the files on the server you’d like to, say, see on your TV / listen to on your home Hi-Fi etc. It also allows for basic playback control functionality like pausing/ resuming, previous / next etc.
finally, it can also function as the target of the stream: the device that actually plays back the video / audio / images on its own screen / audio unit. That is, it’s also a “MediaRenderer”.
As far as the two operating systems are concerned, all these functionalities are implemented. First, a birds-eye view on what’s available and supported.
For Windows Mobile (WM), currently, there are three apps with UPnP capabilities: Nero Mobile Pro, Conduits’ Pocket Player and Rudeo Play & Control (at the time of writing - December, 2007 - no preview of CorePlayer 1.2 was available. It will also have UPnP support.)
For the newer Nokia N-series Symbian devices (N95 (8 GB ), N81, N82), the OS already has built-in, pretty impressive (no third-party, commercial apps are needed) UPnP support.
[*]: with the N95, only starting with firmware version v20, not with previous OS’es; also see THIS. Note that the manual printed with the original N95 still reflects this (old) state.
[**]: limited presentation capabilities (while it has no problems with the much more important streaming): no library, not even file system folder-separated view
Now, let’s take a look at what functionalities the MediaRenderer-capable applications offer.
I'll later explain what the difference between pre-fetching and streaming is.
Incidentally, the second column ("Accessible for external controllers") is also clearly visible in the following Windows Vista screenshot:
It shows the following UPnP servers / renderers in order: Nero MediaHome (server), N95 (server), (the notebook itself, where the screenshot has been taken), the built-in UPnP server of the Vista on the notebook, the Conduits Pocket Player (PP) renderer (!) on the “wr-x51v” PDA; the same PP on the same PDA as a server; PP as a server on the “wr-univ” and, finally, PP as a renderer on the same “wr-univ”.
1.1 Differences between traditional Remote Media Controllers (RMC’s) and full UPnP applications
Back in February, I’ve already published an extensive Bible on all non-UPnP applications. Now, let’s see what the real difference between a fully-fledged UPnP app and the, back then, reviewed remote controllers is!
First, as you may already have guessed (without even reading my previous Bible), RMC’s can only remotely control media player applications – they don’t offer built-in, local rendering (MediaRenderer) or file serving (server) capabilities. The best, UPnP-capable titles in this respect (currently, as of late December, 2007, Pocket Player 3.51 on Windows Mobile and the built-in UPnP client on the latest Nokia N-series models) offer both of these.
Second, their configuration can be much more complicated than those of UPnP clients, particularly when you need to manually (!) enter the local network address of the server (also containing the media player) you’d like to remotely control. This is true with almost all RMC’s not capable of discovery protocols to automatically discover controllable servers in the LAN. UPnP’s automatic discovery also greatly helps in this respect: you don’t need to do any manual work; just let the controller discover the servers / renderers and you’re all set.
Third, you can only remote control a Windows PC (in cases, other desktop OS’es are also supported) with those “old-fashioned” RMC’s because all the tested applications need server&renderer-side custom software to be installed. This also means it’s impossible to remote control for example Network Attached Storage (NAS) devices (file servers) or plain renderers like a flat TV. With UPnP, all these can be remote controlled.
1.2 Available UPnP-capable software
Now, let’s take a look at what’s available on mobile platforms. Note that as far as Palm OS is concerned, not even Pocket Tunes, by far the best music player support UPnP (and CorePlayer won’t support it either) – you need to go the manual route explained in my RMC Bible for being able to stream stuff from your local UPnP network. There’s a nice thread on this all HERE.
Please, Windows Mobile users, don’t be disgruntled because of including Symbian. Some of the, especially, multimedia / entertainment-centric smartphones like the Nokia N95, N81 and N82 have excellent capabilities well worth incorporating into Windows Mobile handhelds. For example, these devices support UPnP “out of the box”, which is only available (if at all – see for example the complete lack of, say, UPnP printer support in current WinMo apps) with (expensive) third-party applications on WinMo. A direct inter-OS (operating system) comparison like this will certainly help both Microsoft decide to, finally, include UPnP in Windows Mobile (not only on non-WM WinCE 6 devices) and also shows WinMo hardware manufacturers what they should concentrate their forces on – for example, at really (!!!) lowering Wi-Fi power usage when not actively used.
The same also states for Symbian users. I know you’d rather not see Windows Mobile contents in here, but, again, such a comparison is instructive for you too because, then, you’ll know what Nokia should be told in order to improve the facilities of its client. And, as I seriously doubt anyone (except me) would write a thorough feature comparison / buglist of these two operating systems, Symbian developers can make great use of this report.
1.2.1 Windows Mobile
1.2.1.1 Conduits Pocket Player 3.51
Currently (before the release of CorePlayer 1.2 and its UPnP support) this is definitely the best and most versatile UPnP client for Windows Mobile. It has definite advantages over the alternatives: first, as opposed to the two other WM solutions, it can act as a server. Second, as opposed to Nero’s app, it can act as a pure controller (without locally rendering anything), in which it can be pretty handy at just controlling the data flow between your home entertainment devices. After all, if you do have a UPnP-enabled flat TV (with an excellent H.264 decoder), why would you want to watch the same video on the small screen of your smart phone? On the other hand, your phone is one of the best tools to actually remote control the data flow in the network - you, for example, won't need to purchase additional, UPnP-only remote controllers if you already have a UPnP remote control-capable phone in your pocket.
The UPnP interface, accessible under Browse / Network, is pretty easy to master. In addition, moving between the pages (with the left/right D-pad arrows) is very easy too – not so with, say, the much more awkward (and VERY slow!) Nero Mobile Pro, where it's very easy not to be able to click the "Back" arrow at the top of every list.
It’s only at remote controlling that I’ve found it a bit lacking: the pure remote control user interface (UI) it uses isn’t as intuitive as that of Nokia or Rudeo: you need to use a separate, list-based UI. That is, not the native, well-known and familiar playback interface, but a completely different one depicted here:
In this regard, Nokia’s and the Rudeo apps are definitely better. Again, on these, you can use the well-known controls to control the multimedia stream flow between the media server and the renderer as if you played back a local stream as can be seen in the following screenshot:
As can also be seen, Nokia's (and Rudeo's too) not only displays the controls to control the rendering of a multimedia stream, but also displays its metadata, the progress etc. No such features are available with Pocket Player.
1.2.1.1.1 Additional screenshots & usage tips
An example of browsing my (Vista) notebook: the main category list. All these contain the usual categorization: the music list shows the traditional (example of the album view and, inside of it, the list of the individual songs) library view.
The list of videos is also shown; they, however, can’t be played back, not even WMV files (which are, by default, supported by PP with local playback) – only the sound will be heard. If playback starts at all, that is - it doesn’t seem to work on WM6 (only the list is shown, play controls don’t work) ; it does on WM5 as can also be seen in HERE (notice that the movie is being played back). Unfortunately, this also applies to viewing pictures – while their list is correctly displayed, “Play” doesn’t result in their being actually displayed.
PP is also able to use another renderer (screenshot of stepping into the menu); for example, in THIS screenshot, you can see the GUI for remote controlling a device.
1.2.1.1.2 Problems (as of version 3.51)
1. Even Western (äö, for example) accents in the title of the MP3 tags (the one needed to be displayed in the given situation) result in the clients not being able to connect. The Symbian client displays the server’s refusing the connection (“Selected device rejected the operation”):
The Nero Mobile client, when run from another PPC, just crashes and immediately exits when stepping into a view that would contain an accent anywhere. From the same PPC, it “only” refuses to display anything including and after the accent. For example, if you have the album “Hilapiäles” from the artist “Pömpeli”, then, only a single “P” will be displayed as an artist name (the second letter, ö, is already accented) and only “Hilapi” as the album name.
2. When (this is a very rare case but you may still run into it, particularly if you try to remote control a Windows Mobile PDA from, say, a Symbian phone, which defaults to remote rendering) it’s controlled from an external controller and its renderer module is instructed to connect to its MediaServer module, the connection will fail. During this, it just displays a local (192.168.0.1:51524) connection message for about 30 seconds; nothing happens after this, no playback / anything.
3. When operated in direct mode (NOT remote controlled! In the latter case, it has no problems accessing MediaServers!), it can’t connect to other Windows Mobile / Symbian servers (tested with both serving-capable UPnP apps: Pocket Player itself, running on another Pocket PC, and Nokia’s UPnP app). Then, it displays a “Server Error or Access Denied” error message.
1.2.1.2 Rudeo Play & Control 2.9.15
In my RMC Bible, I’ve already discussed the non-UPnP-capable version of this program, Rudeo Control for Windows Media Player. Rudeo Play & Control is entirely different as it’s specifically written for controlling UPnP-compliant servers and renderers – and to play back from the latter.
(playing back a song remotely; also showing the target renderer; note that the song title is only shown at the bottom)
(playing back a song locally, also showing the target renderer)
(server list)
During install time, you can also install a server-side component, which lets for some goodies well-explained in the user guide. It, however, didn’t work with my setup (XP SP2 + WMP 11).
Other screenshots: filelist of the, in the previous screenshot, listed two servers. As can be seen, it correctly lists the categories / files. Quickly playing a title is pretty easy (if you don’t want to fuss with playlists): just tick the given song, tap and hold it and select “Checked – Add and Play” as can be seen in HERE.
It seems it has severe problems with the CPU usage even in pure remote control mode (the same on the Wizard, in pure remote control mode; the red chart is the charted Rudeo executable). The situation is even worse when it locally plays back music (Wizard example screenshot HERE); then, the CPU usage can be so high that the player really quickly chews through the battery. Note that this seems to be a generic problem with all Rudeo products: Rudeo Control for Widows Media Player also had unpredictable, sometimes very high CPU usage (see my previous RMC Bible).
Incidentally, as has already been mentioned, like Nokia’s player and as opposed to Pocket Player and Nero and, it pre-fetches the songs before playing them. This can be a bit time-consuming, largely depending on the speed / optimization of the storage card. Unlike with the Nokia, where you can set where the fetched file should be temporarily stored (either the card or the, at times, much faster built-in storage), you can’t do the same on Rudeo’s controller.
1.2.1.3 Nero Mobile Pro 1.4.0.9
I’ve already reviewed the individual audio file playback and MPEG-4 ASP/AVC playback support of Nero Mobile Pro. Unfortunately, compared to the best (and, at times, even free like TCPMP!) titles, it didn’t really excel at them.
The case is pretty much the same with UPnP. First, it only has pretty basic UPnP support. It has absolutely no MediaServer and (purely remote) MediaController capabilties, unlike all of the alternatives (note that Rudeo can’t act as a MediaServer either; Pocket Player and Nokia can). That is, it can “only” connect to other UPnP MediaServers and play back (locally render) their contents on the PDA itself. That is, you can’t use it at all to, say, remote control the communication between your UPnP-capable flat panel TV and network storage – again, unlike with all the other alternatives.
1.2.2 Symbian (Nokia N-series)
The latest Nokia N-series (that is, multimedia-centric) phones have UPnP support built-in. Before the latest (2007 Autumn / Winter) batch of multimedia Nokia phones, they - in addition to being MediaServers and the ability to send files directly to, say, UPnP printers - were only able to remote control other UPnP devices. That is, they didn’t have local, on-phone rendering (playback) capabilities. Now, with the latest models (N81, N82, N95 8GB ) and firmware upgrades of older models (N95-1 with the v20 firmware), a (pre-fetching) renderer component has also been added.
(main mediaserver list; as can be seen in there, it saw Conduits Pocket Player’s server on my Dell Axim x51v; Orb, Nero Mediahome and the built-in UPnP server in Vista on my notebook called “WR-NOTEBOOK”; the Conduits Pocket Player’s server on my HTC Universal and, finally, the TVersity UPnP server on my notebook.)
A quick tip: by default, when you select a (single) song on an external MediaServer to be played back on the (local) Nokia, when you click on the song, the pop-up window displayed only lists the external renderers.
In order to play back the title on the local Symbian device itself, you must select Play / On device instead:
Note that the other menu item in this submenu, “Via home network”, results in displaying the available renderers on the network – that is, the same dialog as above. Also note that, if you select more than one song to play back with either Mark/Unmark / Mark all viewed or with the traditional multiple selection shortcut on your particular model (for example, on the N95, holding down the pen button while navigating down with the D-pad), you will only be able to use this menu for initiating playback. Simply pressing Action on a title to be played back on another, external renderer won’t work when more than one title are selected.
Note that, in order for the other devices to see your Symbian device (that is, it can act as a MediaServer), you must manually enable “Show phone” in “Visibility in network” in the settings as can be seen in HERE. This needs to be done every time you start Tools / Connectivity / Home media – this setting, unlike with Conduits Pocket Player’s similar setting (Browse / Setting/ Enable sharing), doesn’t stick.
Still speaking of PP, it’s also worth pointing out that, in Pocket Player, sharing your own contents is, by default, disabled; therefore, you may want to click all the three list elements in Browse / Network / Settings so that they become the following:
(the second list item makes Pocket Player controllable from another MediaController. If you don't need it, just don't click it).
Finally, in addition to multimedia playback / remote control, the Symbian UPnP client excels at something the Windows Mobile clients don’t support: handling non-multimedia UPnP devices like wireless UPnP printers. To make use of them, you can just copy any document to them with “Copy to home network”:
1.2.2.1 Problems with the Symbian client
Unlike with all (!) MediaServers (Windows Mobile and desktop alike), it doesn’t support media library or even file system-based file / media separation. That is, while it does have three main categories (Music, Images&Videos, Uploaded) (the latter for direct file transfer – the N95 supports it both as a client and a server – note that few other MediaController clients support this). (The same category screenshot is HERE, taken on the desktop running Cidero, which I’ll elaborate on later.)
Inside these categories, however, ALL the available files are shown without any separation (screenshots: Music; Images&Videos) – neither library-, nor file system-based. Hope the Nokia folks fix this VERY annoying issue some time and at least adds file system-based separation, if not the full Music Player library support.
1.3 Minimizing power usage – with benchmarks
1.3.1 Rendering: Pre-fetching vs. streaming
As has already been explained, a media renderer may opt for pre-fetching a file before / during playback so that it doesn’t have to stream the content all the time from the MediaServer. Two renderers follow this approach: Nokia’s and Rudeo.
Pre-fetching, while it’s certainly has its drawbacks (for example, pre-fetching huge media files may just fail because of the lack of storage space and/or can be lengthy at first), has some definite advantages; most importantly, the Wi-Fi power usage can be minimized – if it automatically powers down itself after a given inactivity time threshold. The following screenshot certainly shows this all:
I’ve played back several songs during the test; the power usage peaks definitely show the boundaries of these songs. (It was slightly before the end of each song that the Wi-Fi unit was activated and the next song was quickly pre-fetched.) As can clearly be seen, the average power usage was 0.57W, which is about only 0.18W more than playing back local MP3’s (see THIS for more info & never before published benchmarks on the latter). Pretty impressive, isn’t it?
Interestingly, keeping the N95 visible (again, it defaults to being invisible) in the Wi-Fi UPnP network (as a server device) was also really battery-friendly – only consuming some 0.11W’s (that is, almost the same as without Wi-Fi).
As far as Rudeo on Windows Mobile is concerned, it also does pre-fetching, which also allows for the Wi-Fi unit’s powering down. However, as the CPU usage of Rudeo is pretty high, the overall power usage will also remain high, particularly with non-battery-friendly CPU’s like the Intel XScale PXA-2XX series (their latest, PXA-3XX series, now, Marvel-branded CPU’s are stated to be better in this respect; I've elaborated on the huge power usage increase with increasing CPU usage when compared to, in this respect, much better architectures like the newer TI OMAP platform for example HERE, in section "1.1.1.1 Battery life considerations" - worth a read!). The following acbTaskMan screenshot (measured on a Dell Axim x51v with minimal backlight and moderate sound volume) clearly shows this:
This chart shows an about 2-3-minute-long initial pre-fetch session, when all the three demo songs were pre-fetched for playback on the local PPC (about 450 mA current, with 600 mA peaks). After the fetching has completed, the player switched to regular playback and the Wi-Fi unit was powered down to idle state, but the CPU usage remained very high (20% at 624 MHz, with much higher peaks) – hence the overall ~280 mA current.
It can clearly be stated that, battery usage-wise, prefetching is WAY better than streaming solutions. The following screenshot shows Nero Mobile Pro (in minimized state – let’s not forget that its graphics takes a LOT of CPU cycles, resulting in even worse figures) streaming (MP3’s from Orb) on the Dell Axim x51v (run without a charger). As can clearly be seen, the average Amperage was around 450 mA’s, while the CPU usage at around 60% - that is, not much higher than with Rudeo (let alone the N95, which has by far the best power management). Yes, prefetching surely has definite advantages.
The situation is similarly bad with Pocket Player, which also uses streaming:
As can clearly be seen, the Amperage has always been around 380 mA (with the lowest backlight level and default Wi-Fi sensitivity setting) – which is still about 100 mA’s more than with Rundo and its Wi-Fi power saving by pre-fetching contents. The somewhat lower CPU usage of Pocket Player doesn’t really help in this respect.
Note that the previous screenshot has been made on the 520 MHz HTC Universal because, on the x51v, for some reason, PP has produced far worse results, where the CPU usage is way more as can also be seen in HERE. Frankly, I don’t know what this is caused by.
Note that both Nokia’s engineers and Rudeo’s developers allow for continuous playback: Nokia pre-fetches the next song while still playing the last one and Rudeo fetches all the songs (and writes to the storage card) while playing the first (few) song(s). This results in no pauses between songs (if there are more than one of them) – only the starting of the playback of the first song will be delayed.
1.3.2 Remote controlling
The situation with pure remote controlling is pretty much the same as with above. The power saving feature of the Nokia kicks in quite fast and results in about 0.15-0.17W generic power usage (that is, about 0.07 Watts more than without Wi-Fi remote control activated). Windows Mobile-based devices, in this mode, fare far better than in the previous case as can clearly be seen in the following screenshot:
As can clearly be seen, the average current is 130-150 mA (just slightly more than without doing anything and a LOT less than the ~400 mA average of active Wi-Fi streaming), which clearly shows the Wi-Fi unit is idling and the CPU usage, which is very low, doesn’t contribute much to the overall power usage.
1.3.2.1 Try disconnecting / powering down your handset when not actively remote controlling!
Finally, a quick tip. As has also been explained in the RMC Bible, you can safely disconnect / power down your handset after initiating a (fully) remote playback – that is, between, for example, a NAS and a flat TV. Then, when you need remote control again, you just power on your device, let the Wi-Fi unit reconnect and you'll almost promptly be able to regain remote control on both the server and the renderer. This is pretty much the same as with traditional, non-UPnP RMC applications and, again, is thoroughly explained in the RMC Bible.
1.4 Networking
If you plan to use your handset in a “real” home environment (to, for example, control the multimedia data flow between a flat TV and a Network Attached Storage), you’ll end up having to use Wi-Fi.
You may (depending on whether your clients are Bluetooth PAN – see below – capable) also want to use Wi-Fi if you “only” have computers on your network. Then, you’ll have somewhat more choices: you can use both infrastructure and peer-to-peer (p2p) mode between the devices. The latter doesn’t require an access point and is supported by both Windows Mobile and Symbian.
However, if you strive for better battery life, you can also use Bluetooth (BT) Personal Area Network (PAN) if and only if all your UPnP components support it. Unfortunately, there’s no widespread support for BT PAN. Symbian devices don’t support it at all; neither do Windows Mobile ones with the MS BT stack in client mode (and, unrestricted, in server mode only with an additional hack). That is, it’s only with Windows Mobile devices with the (in cases, “hacked”, post-installed) Widcomm (Broadcom) BT stack that you can use this form of very battery-friendly form of multimedia sharing / control.
Please also see the related section in the old RMC Bible for more info on all these networking-related questions. Also, let me know if you don’t know how to set up these kinds of networks - but, of course, before asking, first, read the linked article (and all the backlinked ones - I've publsihed several, extensive tutorials on creating for example peer-to-peer Wi-Fi networks).
2. Desktop UPnP apps
Should you want to play with desktop (Windows, Linux, Mac etc.) servers / controllers / renderers, you’ll want to check out the following section. Note that you will in no way need these applications for your mobile UPnP clients to operate in an already-deployed UPnP home network; I’ve only presented it to you so that you know where to look for, say, a pure, but decent and free (!) controller running on any desktop or server OS (for that, I recommend Cidero’s app). These can help a lot with quickly seeing whether a given server is accessible / visible on the network, what content it offers etc.
Another great use for these apps (in this case, Nero MediaHome) is seeing what’s happening in the UPnP network, how many users / clients have connected to your server from which local IP’s. These apps greatly help in tracking down possible networking problems. For this kind of problem fixing, I recommend Nero MediaHome the most.
In the next three subsections, I elaborate on the three main components of the UPnP architecture: (Media)Server, (Media)Controller and (Media)Renderer. In general, there’re no software products implementing all these three functionalities (unlike, say, Conduits Pocket Player on Windows Mobile). There’s On2Share Pro - UPnP AV Suite that promises to implement all of this (it has a 14-day trial and is pretty cheap: only 19.95 euros), but I’ve never managed to make it really work – neither under Windows XP nor under Vista. (I’ve tried to do this on two different desktop PC’s, using two different networking topologies – both peer-to-peer Wi-Fi and using a standard access point. A no-go. While it did list the other UPnP-capable, visible (either a server (upper listbox) or a renderer (lower listbox)) participants:
(another screenshot of the lower part of the server list)
it wasn’t able to communicate with them in any way. (Note that the screenshot has been taken under Vista, using large fonts (a must on a 15" UXGA screen); this is why the lower left buttons are messed up; on XP, with normal fonts, it's correctly rendered. Also note that it displays 127.0.0.1 as the local IP, that is, localhost. This shows the computer had no active Internet connection when the app was started (I've, later, set up an Internet-less p2p Wi-Fi connection manually). Don’t let this make you think I’ve messed up the setup – in other tests, I’ve restarted it so that it received a real LAN IP address. Then, it didn’t work either.)
2.1 (Pure) Servers (MediaServers)
2.1.1 TVersity
Along with Sling (which I haven’t been able to test because it’s still not available in Europe, except for the U.K.) and Orb, TVersity is the most popular remote (WAN; that is, non-local (LAN) UPnP) streaming server, allowing for a lot of niceties; for example, dynamic radio / media transcoding. If you already know this app (because, for example, you’ve used its streaming capabilities over remote mobile networks), you’ll certainly welcome its UPnP capabilities.
(the share config screen; the second tab, with the list of the contents on the server, looks like this – as can clearly be seen, it’s pretty complicated to navigate between the server multimedia contents as there’s no scrollbar. A screenshot of browsing TVersity on a Symbian device is HERE)
TVersity, of course, has its own discussion forum; of it, I recommend THIS thread.
2.1.2 Orb
This is probably the most widely known, free (!!!) home streaming server also compatible with Windows Mobile. It also supports UPnP. It comes with UPnP enabled by default:
Unfortunately, it doesn’t have as nice debug / client configuration capabilities as Nero MobileHome either. But, at least, it’s free and, when it comes to transcoding, definitely more capable than the latter. All in all, highly recommended.
2.1.3 Nero MobileHome
It’s part of the, if you’re into AVC (H.264 / MPEG-4 Part 10) video encoding, pretty much recommended Nero 8 Ultra Edition.
Compared to the first two servers listed above, it has some goodies. For example, with the two servers, it’s impossible to see what clients have been connected, what they’re listening to / watching, what client they use etc. For example, HERE is a list of the renderers found.
The following screenshot:
shows a case in where it’s even more useful: it shows what clients have connected, what they’re streaming / downloading, what they really are etc. In the shot, the first client is Conduits Pocket Player running on my x51v and streaming “02 Track 2.wma” (at 35%); the second is Nero Mobile Pro running on another Pocket PC in the network and streaming “06 Track 6.wma” (at 14%). Also, it lets you define what network interface to use for streaming.
Otherwise, it has pretty much the same capabilities as the former two servers:
- manual addition of shared media directories (note that it also supports automatic refreshing via Nero Scout)
- streams TV
- supports a remote UI
- supports transcoding
(Note that in my forthcoming Multimedia Bible I will continue elaborating on these three products: they have excellent, remote (non-UPnP), smart phone-compliant transcoding and TV/radio streaming capabilities well worth exploiting.)
2.1.4 Other servers
MediaTomb: free, open source, non-Windows
TwonkyVision Media Server (the forum is worth checking out for generic UPnP-related discussions too)
DLink Media Server
Philips Media Manager
JRiver Media Center
Note that Windows Media Connect (still recommended on the Rudeo page) 2.0 is no longer available because the same functionality is built into Windows Media Player 11 for Windows XP or Windows Vista
2.2 (Pure) controllers (MediaControllers)
Cidero - Java-language, multiplatform controller. Don’t be afraid of it being written in Java – it’s very easy to install: just download the installer EXE, run it and you’re set.
It’s a very nice and free app. As it has no built-in renderer, you must use an external one to play back multimedia content.
2.3 (Pure) Renderers
Probably the most important is the Un*x-based GMediaRender; unfortunately, it has no desktop Windows version.
Hardware-wise, Sony PlayStation 3 (PS3) is generally considered one of the best media clients / AV (for example MP4 HD) renderers.
Whoa, AMAZING!
thank you!
this is very much to digest all at once, but i'll get into it and start trying it for myself
UPDATE (12/23/2007): There’s a nice quick summary of how a mobile device can be used for in a home environment HERE, in the first post of the thread. It’s worth a read if you still don't really understand what UPnP can be used for in everyday life. (Note that it discusses the Nokia N95 in this scenario. Of course, any other, UPnP- & remote control-capable mobile device can be utilized in exactly the same way. Also note that it still discusses the old, pre-v20 firmware of the Nokia N95. As has also been mentioned in the (currently) last post of the thread, the N95 has received real renderer capabilities in the meantime.)
Omnia
The Samsung Omnia now comes with uPnP control point software.
yannick said:
The Samsung Omnia now comes with uPnP control point software.
Click to expand...
Click to collapse
cool, thanks, in a subsequent update, I'll post this piece of info.
By wikipedia, a list of hardware and software UPNP media server/player/renderer/...
http://en.wikipedia.org/wiki/UPnP_AV_MediaServers
It hasn't a seccion for windows mobile, anyone for add our seccion for PDA?
great write up!
Watching YouTube videos is a favorite pastime of many. With data charges constantly decreasing (or, should I say, plummeting), not-that-expensive flat 3G data rates getting common, Wi-Fi’s getting pretty ubiquitous and, of course, YouTube’s getting really-really full of videos worth checking out, you might be tempted to watch YouTube (or other) videos on your handset. After all, it's a great pastime and these handhelds have both the processing power, the necessary hardware and, in most cases, connection speed to render these videos well.
In this YouTube Bible, I show you how this all can be done on the three major non-iPhone platforms: Windows Mobile, Symbian S60 and BlackBerry. (As the iPhone, as opposed to most other solutions, already comes with a decent player, there isn’t much point in elaborating on it. You just fire up the YouTube icon and off you go at – if you have Wi-Fi connectivity – very good quality. Nothing needs to be installed and there’re no alternatives you will need to know to make an intelligent decision.)
Note that I’ve published several YouTube-related articles (a quick search for YouTube on my blog reveals these tutorials). These, however, are pretty outdated now – particularly that a lot of vastly superior solutions have been released in the meantime. I’ll, however, refer back to for example the HTC Streaming Media tutorial.
Also note that this Bible is multiplatform, as with the majority of my later Bibles. If you're a fanboy of any of the three reviewed operating system, don't post angry messages like "Why on earth did you include operating system X? I hate it, it's sooooo inferior and lame!". Sorry, both as a gadget-loving geek and as a professional IT advisor / consultant, I MUST know all the mobile operating systems. (Particularly now that the Microsoft folks have just told me they would be interested in some of my week-long lectures on the differences on BlackBerry and Windows Mobile devices. I need such kinds of work because I (more precisely, my employer) prefer getting mobility-related IT consultant contacts as opposed to non-mobility-related ones. This is also why I keep posting on other operating systems - as I need to know them, why wouldn't I post on them? Finally, I won't create a separate version of the Bible for Symbian, BlackBerry and Windows Mobile devices for two reasons: 1. it'd cause me a LOT of additional work not only initially but also when I post a revised, updated version: restructuring the entire Bible, taking out all references to other OS'es; 2. knowing what other operating systems are capable of won't do anyone any harm - you may even find that having read info on another OS useful if you are given a handset running a different OS.)
Also note that, Windows Mobile-wise, the discussion applies to both touchscreen-less MS Smartphones (Windows Mobile 6 Standard) and touchscreen-enabled Pocket PC’s (Windows Mobile 6 Classic / Pro) models. All the reviewed Windows Mobile solutions run on both platforms. In the compatibility lists, I've listed the earliest Windows Mobile operating system a given solution is compatible with but didn't list them all. This means if you see WM2003+, it means compatibility with WM2003 and all subsequent operating system versions (WM2003SE, WM5, WM6, WM6.1), not only with WM2003.
1.1 Browsing the desktop Web version of YouTube
This section applies to both platforms of Windows Mobile starting with WM2003+ and used with Internet Explorer Mobile (IEM) and Opera Mobile; Symbian with integrated Flash Lite 3.
1.1.1 Windows Mobile
1.1.1.1 IEM / Opera Mobile + Flash 7 plug-in
If you install the Flash 7 plug-in (see the Flash Bible HERE for more info on the availability etc.) on your Pocket PC and either use the WM5+ (not earlier: due to bad JavaScript support, they won’t work) Internet Explorer Mobile (IEM) or WM2003+ Opera Mobile (any version), the videos will be played back in-line, just like on the desktop.
This is, however, the worst approach you should ALWAYS avoid because it, in some cases, grinds the entire handset to halt and is very slow, even on high-end Windows Mobile devices. All in all, it’s in NO WAY recommended - there are far superior approaches.
1.1.1.2 IEM + FlashVideoBundle
This is an immensely better solution having all the advantages of the desktop version; most importantly, direct access to YouTube, Google Video & Veoh links sent in, for example, mails. Then, when IEM is invoked, you’re shown a context menu, where you can instruct IEM to show the video in TCPMP, save it into a file or, alternatively, take you right to the page so that you can see for example the comments / related videos:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If you directly enter the URL in the address bar (by, for example, pasting it to there), it’ll too present you with the same context menu; the same will happen if you just click a video link on YouTube (GV etc.) pages.
The current version is 1.4.4; CAB file available for download HERE (if you don’t want to register, I’ve mirrored it HERE); my old, now-outdated article HERE. Installing it is pretty straightforward; just follow the section "Installation instructions" in the tutorial on the homepage.
This is one of the most recommended ways of playing back online videos, particularly if you get links in e-mails / other, offline documents like Word files.
1.1.2 Symbian with Flash Lite 3
In order to play back (Flash, including YouTube) videos embedded in Web pages, you’ll need to have a device with Flash Lite 3 preinstalled. One of them, the, currently, best multimedia handset of all, the Nokia N95 received Flash Lite 3 support in firmware version v21 released some weeks ago.
If you have a compatible handset, you don’t need to install anything else (no third-party apps at all): videos will be played back right in the pages that contain them, with much-much less adverse effects than (currently) with Windows Mobile relying on the CPU-hog Flash 7.
As has already been emphasized, Flash Lite 3 on Symbian behaves much-much better than the full Flash 7 on Windows Mobile. While the latter is in no way recommended, the former – if you have a Symbian device – is. Note that you can still use the Mobile YouTube Web and the MIDlet-based interface too (see sections 1.2 and 1.3, respectively), but they only deliver 3GP videos at a much lower quality than Flash Lite 3. Alternatively, if you need high-quality (Flash / H.264) videos, you may also want to prefer Mobitubia – or the soon-to-be-released, YouTube-capable version of CorePlayer.
Note that Portrait playback will always be oversized as can be seen in THIS screenshot (source link HERE). Also, if you use the standard Nokia Web menu (Options / Rotate Screen) to switch to Landscape mode, it’ll stay oversized. The trick is clicking the Flash Lite 3 surface with the Action button – it’s then that it’ll be resized to fit into the screen as can be seen in the first screenshot.
Also note that there’s still no Flash Lite 3 on Windows Mobile but will, hopefully, be soon released; see THIS and THIS for more info.
1.2 Browsing the mobile version of the YouTube on the Web (Windows Mobile (WM), Symbian, BB(?))
If you fire up YouTube in your mobile Web browser for the first time, you'll be taken to the mobile version available at http://m.youtube.com/ - as opposed to the desktop one. This is vastly different from the desktop version in that it uses 3GP / RTSP - and has much less bandwidth usage even for rendering Web pages themselves.
This, of course, has both advantages and disadvantages. While it has much lower video/audio quality and is incompatible with firewalls (except for directly Net-connected Access Points, which almost all do decent RTSP NAT'ing), it uses applications most likely to be already present on your handset. For example, most Symbian handsets have the RealOne Player sufficient for playing back RTSP streams, but comparatively few have the latest, recently released Flash Lite 3. Similarly, on Windows Mobile, several, mostly HTC-branded devices come (but if your device doesn't have it, you can safely download and install it) with HTC's Streaming Media as is explained HERE. Finally, it MIGHT be compatible with more recent BlackBerries too as they too have an RTSP-capable media player; in my tests, however, it reset my OS 4.5.0.9 (beta)-based BlackBerry 8800 - unlike vTap's streams. (This doesn't necessarily mean it resets all other BlackBerries!)
Note that m.youtube.com already has ALL the videos available, unlike some months ago when it was first announced. That is, if you can live with the lower video / audio quality of 3GP streaming (and/or you don't have a network connection making RTSP streaming impossible), it might be a better choice than the desktop version - on both Symbian and Windows Mobile. Also, its interface offers exactly the same capabilities as that of the desktop version - in a much more bandwidth- and memory-conserving way. This also means you don't need to learn a brand new interface - your can safely rely on your already existing knowledge of the desktop YouTube interface. (Not that the alternative apps and interfaces would be THAT hard to master...)
Also note that if you ever click "View Desktop Version" link once (at the bottom of the page), after that, you'll always be taken to the desktop version.
1.3 Using the official YouTube MIDlet, YouTube for Mobile (beta) (currently, Symbian)
If you navigate to http://m.youtube.com/app from inside the browser of your (select) Nokia or Sony-Ericsson handsets (N73, E65, N95, 6120c, 6110n / k800i, w880i), you can easily download and deploy the client by just clicking the Download link.
This client is a standalone app; that is, you don’t need to fire up for example the Nokia Web browser to get to your videos.
It has both restrictions and advantages. The biggest problem with it is that it can’t work over Wi-Fi connections (even with RTSP NAT correctly working, which is pretty much the case with most current Wi-Fi access points), unlike other clients. That is, you can only use wireless data to access videos. Another problem is that it’s only able to access 3GP streaming, meaning low playback quality.
However, it has a very nice and capable GUI, much better and powerful than that of most of the standalone alternatives on all platforms (not only Symbian). For example, it supports upload, account; it has related videos and is VERY polished – for example, it has search history support, which is even saved through restarts. Some screenshots showing it in action:
(searching in progress)
IMG]http://www.winmobiletech.com//042008YouTubeBible/NativeYTJavaClientRelVideos.png[/IMG]
(related videos)
(search history)
(flagging videos)
(A GUI screenshot of portrait and landscape playback is HERE and HERE; unfortunately, the screen capturer app couldn’t capture the rendered video.)
Note that this app, currently, is NOT compatible with any MIDlet Manager on Windows Mobile, as has also been explained HERE. The reason for my not putting it in the strictly Symbian-only section is that it hopefully will be made compatible with Windows Mobile as well – if Google doesn’t release a native (C++) version for the operating system, as they have done with Google Maps.
Related threads HERE, HERE and HERE.
1.4 vTap (WM, Symbian, BlackBerry)
vTap is an RSS-like content syndication service with integrated, multi-site searching (including all major video sites, WikiPedia etc.) It has both a standalone (Windows Mobile / BlackBerry) client and a Web interface. The latter is of paramount importance with BlackBerry, as it’s, currently, the only way to access online YouTube videos.
First, let’s take a look at the standalone Windows Mobile client. After installing and starting, it presents you a single input field, where you can enter for example the video you’re looking for – as with the traditional YouTube search. It, however, also presents Wikipedia (and other video) hits.
(a Windows Mobile screenshot showing the collected results of a search – again, not only from YouTube)
Its GUI is pretty powerful as it allows for for example feedback, account login etc. Its settings capabilities are also pretty cool (1 2). Also allows for showing related videos which is pretty rare as of the writing of this article.
As far as the BlackBerry is concerned, the native client is only able to search from the Wiki as can be seen in HERE. The vTap folks do state the standalone client is, as with Windows Mobile, able to play videos (or, at least, pass videos to the system-level multimedia player) starting with BB OS version 4.3. This doesn’t seem to be the case with version 4.5[0.9] beta of the operating system (see the 04/23 update of THIS article for more info on acquiring and installing the beta). As can be seen in HERE, there’s no Play icon at all and the menu (screenshot HERE) is much less powerful than that on Windows Mobile. (These are all 4.2.1 BB 8800 screenshots; the client behaves in exactly the same way on the same device with the latest 4.5.0.9 beta OS). Some Pearl users with native 4.3, on the other hand, did state it worked for them.
See for example THIS for more info.
However, this isn’t a problem! There is, fortunately, a way to play back online, streamed content on the BlackBerry too. (Note that the following part has only been tested under 4.5.0.9. It might work on "official" 4.2 / 4.3 OS versions as well.)
1.4.1 The online Mobile vTap
If you navigate to http://m.vtap.com/ on your BlackBerry, you’re presented an interface pretty similar to that of Mobile YouTube. It allows for searching and a lot of other goodies. On BlackBerries, it’s the only way to get online, non-reconverted content, unlike the ways described for example HERE or in the well-known, related CrackBerry.com tutorial. Screenshots showing it in action – again, under OS version 4.5.0.9:
(note that, as with Symbian, I couldn’t make a shot of the rendered contents)
Note that Mobile vTap is also compatible with Symbian; in there, it uses the built-in RealOne player (and RTSP). It must also be compatible with HTC’s Streaming Media on Windows Mobile (haven’t tested this), should you want to prefer it to alternate solutions.
1.5 Operating-system specific, other apps
1.5.1 Windows Mobile
1.5.1.1 CorePlayer
I don’t think anyone needs to introduce CorePlayer (particularly not to readers that have been following my past multimedia-related articles), which has recently received native YouTube browsing / searching support – in addition to, of course, playing it back. And it does the latter extraordinary well. Being based on the fastest AVC (H.264) and HE-AAC decoders, it plays back high-quality (non-3GP) videos with much less overhead than any other YouTube client on Windows Mobile. See for example THIS and THIS post for more info on this.
If you know iPhone’s YouTube player, you already know that of CorePlayer – the latter is very similar to iPhone’s. (Except for, for example, the lack of related videos.) This means it’s very easy to use and, again, has the most CPU-efficient decoding algorithm when it comes to playing back quality AND firewall-friendly, H.264 + AAC content - as opposed to the low-quality RTSP-streamed and, therefore, not firewall-friendly, 3GP content, which has considerably lower demands and can be played back by even non-optimized code without major CPU hits. Some screenshots:
(standard list view)
(detailed view of a selected video)
It’s still worth explaining how you can switch between the RTSP + 3G (low/medium-quality) and H.264 (high-quality, firewall-friendly HTTP-streamed) modes. By default, CP is configured to use the former. If your network topology / connection doesn’t allow for RTSP connections, the current, 1.2.3 version doesn’t display any error message – just times out after some minutes. (This will be fixed in a future version, as is also explained by the developer: "Automate the YouTube Quality Control 'seeking'... this will help incase one setting appears to hang (spinning buffering icon).") If you either want to fix this problem or just want much better audio & video quality, just switch to "High Quality" in Menu > Tools > Preferences > Select Page > Network > YouTube Format:
Note that QTv Display is set by default as the video renderer; therefore, if you don’t see any video (only sound), you’ll need to set the video mode to Raw Framebuffer or, if your PDA has a graphics co-processor (for example, the Intel 2700G), to it in Menu > Tools > Preferences > Select Page > Video > Video output:
Note that with the (unfortunately, still very few) stereo high-quality (H.264) videos (like this) aren’t played back in stereo, unlike with TCPMP-based H.264 / FLV players - or simple 3GP players like that of Nokia Flash Lite 3 or the BlackBerry. This problem will be fixed really soon, as HE-AACv2, the state-of-the-art sound compression technology I’ve often elaborated on in my articles, finally gains support in CorePlayer in the near future. This is just great news – so far, Windows Mobile clearly lagged behind both Symbian S60 (on N-series devices) and BlackBerry 4.5 (which both support HE-AACv2 out of the box, with minimal CPU usage and AVRCP support not available with Windows Mobile) when it came to playing back HE-AACv2.
Also note that, while the YouTube client of CP currently lacks a lot of additional functionality like clip upload, login, online favorites etc., this will soon be fixed as is explained HERE: "we have omitted some features till later on when we add it as a module with login, uploading, related, and bookmarking".
Finally, should be interested in why I recommend CP so much, take a look at my H.264 Bible (if you haven’t already done so), where I’ve thoroughly benchmarked the H.264 (and AAC) decoding efficiency of all media players.
1.5.1.2 Milesmowbray’s YouTubePlay - YouTube Player
There’s another, free(!) and pretty cool, but, being based on the old TCPMP libraries, compared to CorePlayer, less efficient standalone player, Milesmowbray’s YouTubePlay available HERE.
(the search results, highlighting a clip - as you can see, there isn't much you can do - no related videos, flagging, account support and the like)
(it uses a built-in video player for playback - that is, it doesn't rely on external players)
It’s pretty straightforward to use as it’s a stand-alone app: you just install it and fire it up. No further (external) app installs are necessary. See the above-linked thread for user discussion & new versions (albeit, of course, I’ll try to keep you updated).
If you want a standalone (non-Web-based) app and don't want to pay for the, otherwise, technically superior CorePlayer, this app is worth checking out. Note that, however, it's pretty much inferior to CP, capabilities-wise.
1.5.1.3 YTPocket
YTPocket is a decent Web-based interface offering Flash-based, that is, high-quality (as opposed to low-bitrate and, hence, low-quality 3GP streams) and HTTP (meaning firewall-friendliness) streaming. The interface is pretty much similar to that of the Web interface of Mobile YouTube.
As it’s FLV-based, you must have a FLV-capable player to play the videos it downloads. Shouldn’t you already have TCPMP with the FLV plug-in installed, you can easily download them over-the-air from the setup tutorial page of YTPocket.
(the thumbnail list)
(a direct URL can also be entered – or, better, pasted – should you have received a direct link in, say, an e-mail and don’t want to fire up Nokia Web or Opera Mini to find out the title or other parameters of the clip to be able to quickly find it)
(you can also supply the YouTube ID – see the remarks of the previous screenshot)
Note that there used to be another Symbian app to play back YouTube, emTube, but it’s been down for some months and it’s still not known whether it’ll be restarted at all. Also see THIS.
Finally, the Symbian version of CorePlayer will receive the same functionality than the Windows Mobile version in 1-2 weeks (this being written on 04/24/2008). See section 1.5.1.1 for more info.
2. Comparison chart
The feature / comparison chart available HERE is pretty easy to understand based on the info above. It lists the compatibility, quality, protocol (whether it’s using high-quality, firewall-friendly HTTP / H.264 or the low-quality, firewall-unfriendly RTSP 3GP), standard YouTube features like uploading, editing / reading comments, related videos, logging into your account and the ability to save videos for future use (in which YTPocket really rocks).
3. Verdict - what to go for?
There're no hard-and-fast rules for choosing the right solution. First, you need to decide whether the quality (or the lack thereof) of 3GP streams are sufficient for you. If they aren't (and you aren't a BlackBerry user) OR you can't play back RTSP streams (because of your restricted network connection), go for something FLV / H.264-based. Fortunately, both Symbian and Windows Mobile has several apps offering FLV / H.264 playback. For WM, I recommend FlashVideoBundle and/or CorePlayer the most. For Symbian, Mobitubia is a really decent solution - and the forthcoming CorePlayer, if you don't mind the higher price tag. Of course, on Symbian, you can also safely stick with Flash Lite 3 if you have a compatible handset / firmware version (again, remember that Flash Lite 3 being comparatively new, your otherwise compatible phone may still running an older, incompatible firmware - as was the case with the Nokia N95 before firmware version v21).
On the other hand, if your connection isn't firewalled (which would make incoming RSTP connections impossible), the 3GP "quality" is sufficient for you and/or you must reduce network traffic (or, you are on the BlackBerry), you can safely stay with http://m.youtube.com/ (see section 1.2) if you're a Windows Mobile (making sure you do have an RTSP player (pre)installed; for example, the free HTC Streaming Media) or Symbian user or the online Mobile vTap (see section 1.4.1) if you're on BlackBerry.
UPDATE (04/25/2008 12:02PM CET): note that BlueApple.mobi is another great transcoding service compatible with, among other mobile platforms, the (4.3+) BlackBerry. See for example THIS for more info on its BB compatibility.
Also note that I may haven't included some other YouTube transcoder services in the Bible - there're quite a few of them, and I've found the reviewed ones the best.
I thought overall this was a good review. I would take exception on one thing.
You say: If you want a standalone (non-Web-based) app and don't want to pay for the, otherwise, technically superior CorePlayer, this app is worth checking out. Note that, however, it's pretty much inferior to CP, capabilities-wise.
I disagree if we are talking purely about youtube. YouTubePlay plays youtube videos much better than CP1.2.3 on a US 3G network. Sure CP's youtube integration is very nice with the favorites and most viewed etc, but when it comes to play the video you have to decide if you want to lower the resolution or watch it stuttering. Y2P works fine with little buffering using h264. It may work fine over Wifi, i havent been able to test that. Betaboy has said this should be fixed in the next milestone, and if it is, then yes, CP will be superior for youtube viewing. I hope thats the case , as I really do like the CP integration
volwrath said:
I thought overall this was a good review. I would take exception on one thing.
You say: If you want a standalone (non-Web-based) app and don't want to pay for the, otherwise, technically superior CorePlayer, this app is worth checking out. Note that, however, it's pretty much inferior to CP, capabilities-wise.
I disagree if we are talking purely about youtube. YouTubePlay plays youtube videos much better than CP1.2.3 on a US 3G network. Sure CP's youtube integration is very nice with the favorites and most viewed etc, but when it comes to play the video you have to decide if you want to lower the resolution or watch it stuttering. Y2P works fine with little buffering using h264. It may work fine over Wifi, i havent been able to test that. Betaboy has said this should be fixed in the next milestone, and if it is, then yes, CP will be superior for youtube viewing. I hope thats the case , as I really do like the CP integration
Click to expand...
Click to collapse
Yup, many complain about the buffering issues with YouTube and CP; will definitely emphasize this in a future article update. (BTW, interestingly, here in Europe, I have no similar problems with Vodafone (using an unlimited data plan via HSDPA).)
UPDATE (05/10/2008): there is a lot to report on; most importantly, the just-released CorePlayer with its, on Windows Mobile, heavily bugfixed and enhanced YouTube support – and, on Symbian and Palm OS, its pure existence. I, in addition, elaborate on the differences of the three major formats used on YouTube: H.264, FLV and 3GP and give you some excellent screenshots of the real-life difference between them.
First, however, let’s take a look at the operating system-specific news.
1. Symbian
a. some people have asked me to elaborate on myZen, a Java-based and YouTube-compliant player. It’s not recommended at all - it's 3GP / RTSP only with all its drawbacks (sub-par video and audio, not compatible with several wireless operators etc.) Besides, it's, being based on Java, a bit slow. (Albeit this isn't really visible at playing back video as it uses the underlying media player.)
b. I haven’t emphasized this in the initial version of the Bible, but it’s surely worth mentioning: not even the latest (build 4) version of MobiTube can play about 20% of the (FLV) videos off YouTube without (on the high-end N95 with the latest-and-greatest v21 firmware) major stuttering problems. One of these videos can be found HERE. Fortunately, the just-released CorePlayer can play all these videos without problems – or, for that matter, the Flash Lite 3 plug-in, if you don’t mind having to browse the full (and bloated) YouTube site from Nokia S60 Web. The developer has promised to look into the problem. In the meantime, I recommend getting CorePlayer for Symbian to play videos that MobiTube can’t play back. (YouTube does have some advantages over CorePlayer, though; for example, any number of hits. More on this later.)
2. Windows Mobile
milesmowbray has been busily enhancing his youtubeplay app (see the review of an earlier version above) and adding nice features like getting the list of Related videos, a new, much more capable in-play GUI and saving a particular video to the file system. (Screenshots of the latter HERE and HERE). Currently, it’s at version v1.0.0.6 and is worth checking out if you want a free solution, don’t want to browse the bloated, original YouTube site in order to be able to utilize FlashVideoBundle, don’t want to watch low-quality 3GP streams (HTC Streaming Media, http://m.youtube.com/ etc.) and don’t want to use third-party, but FLV-based Web interfaces like YTPocket. Otherwise, if you don’t mind being commercial, the lack of clip saving and Related videos and/or have a VGA Pocket PC, CorePlayer might be a better, more mature solution.
3. CorePlayer 1.2.4
Fortunately, CorePlayer, which has only recently received YouTube support, has received a lot of bugfixes in the meantime, which is certainly very good news for Windows Mobile users. Also, Symbian and Palm OS users rejoice: now, you also have YouTube support!
3.1 Windows Mobile
Let’s start with Windows Mobile. Two huge YouTube problems with pre-1.2.4 versions was the lack of FLV support and the buffering issues have been fixed. I’ll elaborate on what FLV is and how it compares to the other two streaming formats supported by CorePlayer.
As far as the buffering is concerned, the new version no longer exhibits the bad buffering problems of the previous versions, which stopped for buffering quite often even when the connection was far faster than required. In the old versions, this could only be partially fixed by increasing the system buffers to 32M (and enabling microdrive mode). There are no buffering problems with FLV playback either.
Unfortunately, it still has some major functionality problems; most importantly, it still doesn’t list related videos and, even more importantly, it’s only capable of listing 13 videos at most in ANY list. Just an example: if you look for, for example, all parts of Scandinavia: The Forgotten Front - see THIS for the first part - , at least one part will pretty surely be missing if you search for “winter war” using the built-in search tool. (Fortunately, the CorePlayer folks have promised me they would fix all these issues, along with adding support for other video sites – that is, not only YouTube, but also for example dailymotion (which already works in internal test versions) and, hopefully, Google Video.)
This problem is pretty huge on Windows Mobile; for example, with milesmowbray’s youtubeplay as of version v1.0.0.6 (it lists only five items as can also be seen HERE). On Symbian, MobiTube don’t suffer from this: there, 25 clips are shown at a time and you can switch to the next (previous) 25 hits by simply selecting Next / Previous page from the menu.
3.2 Symbian
The Symbian version, which has just received YouTube support, still suffers from the lack of H.264 hardware acceleration. That is, H.264 (480*320) clips are practically unwatchable. On the high-end Nokia N95, it drops about 30-40% of the played frames and has heavy buffering pauses. The somewhat lower-quality FLV playback has no such problems. Therefore, before hardware acceleration is added (or the H.264 playback efficiency seriously enhanced), you’ll want to stick to FLV playback instead of H.264 on Symbian (but not on Windows Mobile, particularly if you have a VGA device).
4. Differences between the three streaming formats: H.264, FLV and 3GP
You may not understand what the three streaming formats, H.264, FLV and 3GP, are, and how they compare to each other, quality-wise. Let’s take a closer look at this question, particularly now that CorePlayer introduced support for FLV in addition to the other two formats.
4.1 H.264
H.264 is the best of all and, currently, is only supported by CorePlayer on both WinMo and Symbian. (The other players are either FLV or 3GP-only.) It has the highest video resolution (480*360), the highest video and audio bit rate with the most advanced codecs (H.264 for video and stereo 44 kHz AAC audio). This, however, also means that it has much higher data usage than the other formats: about 1.8 times more than that of FLV and 3-4 times more than 3GP (also somewhat depending on the audio codec used with the latter). Also, it has much higher CPU demands than FLV or 3GP; this is why, for example, Symbian devices currently can’t play back YouTube videos in the H.264 format. Let’s see an example (the first frame of THIS clip); make sure you compare the quality to that of the two other videos. I’ve deliberately selected a clip with some subtitles; it’s mostly on the latter than you can really see the resolution differences between H.264 and FLV. Also make sure you check out the general blockiness of the videos. (Note that I’ve taken these shots with 95% JPG quality; that is, I haven’t introduced almost any additional blockiness.)
The additional strength of the H.264 format is the support for stereo 44 kHz sound. While, currently, very few (see for example THIS) real-world clips have a stereo soundtrack - and the ones that work on mobiles, like THIS and THIS, don’t necessarily have stereo audio on the desktop.
4.2 FLV
Now, let’s turn to FLV, which is the most widely supported format on mobile platforms. On Windows Mobile, for example, there aren’t other players with H.264 support, while ones with FLV support abound (for example, FlashVideoBundle, milesmowbray’s youtubeplay, YTPocket etc.)
YouTube FLV is, technically, far inferior to H.264: it only has the resolution of 320*240, has much lower bitrate and the technically inferior (worse quality at the same bitrate) H.263 video and MP3 audio format. It doesn’t support stereo audio either.
While on a low-resolution (for example, QVGA) screen the quality difference isn’t so visible as on a high-resolution one (where the difference in the resolution plays a big role in rendering FLV much inferior to H.264), it’s still preferable to go for H.264 even on QVGA handsets because the H.264 videos are just less blocky (much higher bitrate and much more advanced format). Also, the audio is much better (44 vs. 22 kHz and, when possible, stereo). An example screenshot showing the resolution / blockiness on a VGA device:
4.3 3GP
Finally, 3GP, the worst of all – the format that you should avoid at any rate (unless you absolutely need to reduce data usage or don’t need video at all because it’s static like with, say, THIS clip) uses the resolution of 176*144 and a very low video bitrate resulting in a lot of blockiness. An example screenshot follows so that you can see how bad it is:
Note that, audio-wise, there’re two sub-formats of YouTube 3GP streams. The first (better) uses 22 kHz AAC mono audio and is referred to as “Medium-quality” by CorePlayer (as with FLV); the second (worse) uses the 8 kHz AMR speech vocoder to further decrease data usage (and to further reduce audio quality). Of course, the gain is marginal; therefore, if you absolutely need to go 3GP, try preferring the former format.
4.4 Setting the YouTube format in CorePlayer
Don’t forget to set the format in CorePlayer according to your needs and the restrictions of your handheld. (For example, as has already been explained, on a VGA device it’s always worth trying to use H.264 because of the higher source resolution. On a QVGA device, the difference isn’t that big - H.264 is a bit less blocky but, again, requires far more CPU cycles and has much higher data usage. Of course, you should also keep in mind the superior audio quality of the H.264-based streams too.)
Maybe not the best place to post here, but outside of the YouTube support, do you think CorePlayer is worth the money?
TheChampJT said:
Maybe not the best place to post here, but outside of the YouTube support, do you think CorePlayer is worth the money?
Click to expand...
Click to collapse
Depends on what you want to use it for and on which OS. For example, it can't be used for HE-AACv2 playback. If you wouldn't use for it but, say, general non-WMV (ASP, AVC etc) video playback, then, surely.
Great, thanks! Also, great work on all the "Bibles".
Audio with NO video???
Ok, I dont know if this is the correct thread to post but I'll start here...
I'm trying to play saved .flv video files from the storage card on my Hermes/TyTn.
I'm running a Hermes (8525) SuperCID with Schaps4.01
CE OS 5.2.1933 (Build 18533.0.7.0)
I've tried tcpmp.pocketpc.0.72RC1.cab,
TCPMPflvplugin-v0.4.2.CAB,
youtubeplay_1006.CAB
All with no luck. All I get is audio with NO video.
Any advice?
Regards,
UPDATE (05/12/2008):
1. (Symbian):
a. I've tested the last about 20 latest featured videos on YouTube with MobiTubia. All played well. Therefore, it's possible it's only with some older videos that MobiTubia delivers sub-par results; with newer ones, it doesn't seem to.
The Symbian version of CorePlayer, on the other hand, doesn't seem to like firewalled cellular connections. These cause it not to download any clip lists. This works just great under Windows Mobile (and, of course, with MobiTubia under Symbian) and, therefore, must be an internal bug.
b. I've very thoroughly compared the power consumption of MobiTubia to CorePlayer 1.2.4. While MobiTubia consumes a tad more power when it's still loading (caching) the clip in the background, after the clip is cached, it delivers considerably better results (much lower power consumption) than CorePlayer. Therefore, it's always worth going for MobiTubia when your Internet connection speed is much faster than the ~320 kbps stream of FLV videos because, after the caching is finished, the power consumption will be really decreased. CorePlayer, on the other hand, doesn't cache the file and, consequently, it'll use the (with both Wi-Fi and 3G connections, power-hungry) wireless unit all the time.
The following screenshot shows this in effect: the first ~5:30 show CorePlayer playing back a 6-minute clip; the second show the latter with MobiTubia. As can clearly be seen, the latter manages to cache the file in the first about 60% of the total playback time of the clip; after this, it doesn't use the wirleess unit any more, resulting in a heavy power consumption decrease. CorePlayer, on the other hand, streams the YouTube contents all the time, resulting in much higher net power consumption:
I've made another screenshot showing CorePlayer only, repeatedly playing the same 6-minute clip. As can clearly be seen, the power consumption is constantly the same (high) because there's no caching at all.
Let's see some other screenshots comparing the power consumption using HSDPA. As you'll see, the difference won't be as articulated as with Wi-Fi and the average power consumption will be pretty similar because buffering, with much bigger excess power consumption, takes much more time than over Wi-Fi. The following shot shows playing the same clip thru Wi-Fi and, then, HSDPA using MobiTubia:
As can clearly be seen, the average power consumption is bigger because the system were in the low-power (~1.1W) area for a much shorter time than with Wi-Fi. (And, of course, streaming anything (!) via HSDPA will always take much more power than via Wi-Fi, as has also been explained in my Multiplatform Radio Stream Transcoding Bible.)
Let's see the CorePlayer results. Two HSDPA examples follow:
As can clearly be seen, while there indeed isn't any kind of buffering, the overall lower CPU usage of the H.263 / MP3 decoder has resulted in about the same average power consumption as that of MobiTubia.
All in all, as a rule of thumb: on Symbian:
- when you watch YouTube videos over Wi-Fi and would like to have as long battery life as possible, prefer MobiTubia
- when over 3G, both will behave almost the same way.
2. (Windows Mobile): I've continued comparing milesmowbray's youtubeplay to CorePlayer 1.2.4.
a. in youtubeplay, you can fetch the first 50 hits of any search / "Related" operation; but, it seems, no more (it, then, complains about the network's not working.) To set this, go to Config (button in the bottom left) and just increase the number of hits shown with the second slider (Results returned).
b. on the test iPAQ 210, youtubeplay uses about 62-64% CPU time to decode and play back (FLV) videos (in both Portrait and Landscape). CorePlayer, at the same time, uses about 21...23% (again, in FLV). With H.264, of course, CorePlayer requires far more CPU time (more than 80%) and if you run other even slightly CPU-intensive tasks (like acbTaskMan to track CPU usage), there will be some (about 10...30%) dropped frames, particularly with really dynamic videos like those of Call of Duty 2.
This means if you plan to stick to the FLV format (because you're on a QVGA device and, therefore, you couldn't take advantage of the higher resolution of the H.264 video or you're on VGA but the source video is already of bad quality making it unnecessary to stream in H.264), you can save a lot of battery if you go for CorePlayer on CPU architectures that have much higher power consumption with high CPU loads than with low ones. Typically, Intel / Marvel Xscale CPU's belong to this group, where the difference in battery life can even be 1.5...2-fold between two players using 22% and 63% CPU cycles. Of course, with activated Wi-Fi and higher levels of backlight, the difference won't be this pronounced. The only architecture that (somewhat strangely) doesn't exhibit excess power consumption with higher CPU loads is that of Samsung (at least the older architectures; I haven't tested the latest, 6400-series in this respect.)
What about buffering, you may ask. Do alternative solutions like milesmowbray's youtubeplay have an advantage over CorePlayer in the same way as was certainly visible on Symbian? The answer is, unfortunately, no. Just look at the following screenshot, taken via Wi-Fi without power saving enabled on the Dell Axim x51v running WM6.1. (Note that, while CorePlayer had absolutely no problems playing back clips without dropped frames on this particular model, youtubeplay fared much worse. That is, using youtubeplay is in no way recommended on the x51v.)
The CPU usage is shown in the upper and the power consumption on the lower pane. The first ~8 minutes show CorePlayer playing the clip; after that (there's a small discontinuation in the chart) youtubeplay follows. As can clearly be seen, the average power consumption of youtubeplay is much higher than that of CorePlayer. Raising the buffer size from 2048 kbytes to, say, 16Mbytes (to allow for the complete buffering of most clips) won't help at all.
With Wi-Fi power saving enabled, the power consumption is far lower - but, with youtubeplay, it's still definitely larger than with CorePlayer:
All in all, unlike on Symbian, on Windows Mobile you'll always want to stick to CorePlayer in order to absolutely minimize power usage when playing back FLV YouTube videos. (Again, the above power usage tests only only show FLV playback power usage as it's FLV playback that the other players support, not H.264.)
UPDATE (05/12/2008, later): I’ve forgotten to elaborate on the other implications of CorePlayer 1.2.4 having just received FLV support.
One of the most important consequences of this is that you no longer need to use TCPMP as a player together with FlashVideoBundle, should you want to stick to browsing the "full" YouTube in IEM and invoke an external player to play back the videos on them.
That is, you only need to install CorePlayer and, then, the single CAB file of FlashVideoBundle (as of this writing version 1.4.4) available for download HERE and, then (making sure you restart it at least once so that the plug-in is loaded), just fire up YouTube in your (WM5+) IEM and click any video link. In the context menu, just select “Play video” and CorePlayer will be invoked. Cool, eh? You’re no longer dependent on the aging TCPMP but can invoke CorePlayer to play your videos instead. One less programs to install on your handset, not to mention the other advantages (more refined, more battery-friendly drivers, decoders etc.)
If your handheld already has TCPMP pre-installed, you’ll want to either uninstall it or, in CorePlayer, override the file associations. Unfortunately, I couldn’t find out how you should force FlashVideoBundle to pass the execution to CorePlayer instead of TCPMP (without a chance to remove it) with ROM’s containing TCPMP built-in, without any way to uninstall them, like that of Ranju's HTC Universal ROM (v7.6). I’ve tried everything including deleting HKEY_LOCAL_MACHINE\ SOFTWARE\TCPMP in the Registry (the plug-in uses it) – in vain. Unfortunately, simply unassociating the files from inside TCPMP won’t work. I'll let you know when I find a solution.
Great points on the new Coreplayer. It is definitely operating much better.
One question I had that you might be able to answer is what does My Src and My Lists do in the youtube menu? I think my src may be my submitted videos but I dont have any. I do have some videos in quicklist, and they won't show up in My List.
Any ideas? and nice writeup btw
volwrath said:
Great points on the new Coreplayer. It is definitely operating much better.
One question I had that you might be able to answer is what does My Src and My Lists do in the youtube menu? I think my src may be my submitted videos but I dont have any. I do have some videos in quicklist, and they won't show up in My List.
Any ideas? and nice writeup btw
Click to expand...
Click to collapse
They might be reserved for future use (1.3 with its brand new Channels etc.)
Listening to or watching podcasts is great fun. If you think they are boring, meaningless or can’t entertain you during, say, a long fight, you’re wrong. For example, watching all the clips of X-Play, played back on my VGA HP iPAQ 214 (thanks to Smartphone & PPCMag / iPhone Life’s Hal Goldstein for the gift!) could entertain me for long-long hours. (Sure, I’m not of a big 3D FPS gamer on desktop PC’s – I only play text adventures like those of Legend Entertainment and RTS games like Starcraft –; still, I did enjoy witty episodes like Cheating Unleashed: Darth Vader Tryst or Final Fantasy Date).
And, if you’re more of a traditional news viewer / consumer, you’ll definitely prefer automated podcast downloading to hunting for the same video / audio clips on the web. Just a real-world example: Before finding out the Tagesschau (the German news program we usually watch at home in addition to the Finnish YLE programs) podcast feeds, I always had to navigate to HERE (preferably after 9PM and before midnight each day so that I can catch the main evening news program at 8PM) and click the 20:00 link to initiate playback. Then, still two clicks: to start the streaming and to maximize the player screen after the video playback has started. All in all, a lot of clicks and waiting in between – not to take into account you can’t access the programs of the previous day(s).
Diametrically opposed to the awkwardness of all the above, just subscribing to the Tagesschau podcast feed (with downloading the video podcasts (files), the so-called “enclosures“, to the local PC or Windows Mobile, Symbian or BlackBerry handset / smartphone) makes sure you’ll always have access to the main, longest (the one at 20:00) programs – and instantly. That is, you don’t have to (slowly) traverse Web pages, wait some seconds for the video streaming to start to be able to make the player fullscreen – if you are always in a podcaster program (on either a desktop PC or any of the smartphone operating systems), in general, (at least in a well-designed podcaster app like NewsBreak) a single screen tap starts the instant playback.
The same stands for, for example, the MoDaCo (Windows Mobile), All About Symbian (Symbian) or CrackBerry (BlackBerry) podcasts. If you don’t use automatized podcatcher apps to gather these podcasts and make them available offline on your handset (for mobile access; of course, you can also store it on your desktop PC, but the major focus in this article is on fully-mobile podcast/catching), then, you end up, on your desktop PC, having to do a lot of hunting, right-clicking, saving to your hard disk and manual transferring to the storage cards. There, you’ll still need to make sure your mobile media player is able to play these podcasts; this may also require a lot of additional work like starting a library refresh (see dedicated bible HERE) and waiting for it to complete. In cases, this may turn out to be just too slow and time-consuming.
Side note: Difference between podcasters and podcatchers
What’s the difference between podcaster and podcatcher applications, you may ask. The much simpler podcaster apps can only stream (play back) podcasts, but can’t save them to the file system and, consequently, don’t have any kind of scheduling, cleanup or storage usage restriction capabilities. They, nevertheless, allow for subscribing to feeds, which makes it possible to avoid having to enter their Internet address every time.
More advanced ones (in our case, Pocket Player, as opposed to the, as of the current, 1.2.5 version, simpler CorePlayer) even allow for marking podcasts that have already been listened to “read” so that the user won’t listen to them again by mistake as he or she already sees the given podcast has already been consumed. In this regard (too), they provide a far sleeker interface to podcast feeds than traditional Web browsers on mobile platforms, which are much harder to use. With the latter, it takes much more clicks to get to the next podcast; in most cases, Web browsers require podcasts to be saved to the file system first and only let them to be played by a multimedia player later, while podcatching-capable apps are capable of instant streaming etc. Nevertheless, on the BlackBerry platform, still a lot of people prefer downloading podcasts manually (linked to from HERE), via, say, Opera Mini .
The much more advanced podcatcher applications, on the other hand, in addition to being able to play back the podcasts (in several cases, with the help of an external player), are also able to store them in the local file system and can also work in scheduled mode, making it possible to run even lengthy download / synchronization processes when you surely won’t need the handset – for example, during the night.
If you, on the other hand, run a podcatcher application on your handset every night, connecting to the Internet via a Wi-Fi access point of an unlimited Internet connection to download the latest podcasts and to store them on/in your storage (card), you won’t have to waste time on anything explained above. When you wake up in the morning, the latest podcasts will already be available on your handset and you simply don’t have to be afraid of anything else.
Running direct podcatcher applications on your handset – if you do plan to listen to / watch these podcasts right on the phone – is definitely more preferable to doing the same on the desktop and manually synchronizing / copying the files to the handset:
- You don’t have to do any synchronization between your desktop and handset (or memory card swapping if you plan to make a non-high speed transfer faster)
- You don’t even need to switch on your desktop computer for the new podcasts to be downloaded (let alone having to sync it with your handset or, even worse, manually hunt for, select and transfer the new podcasts to it). This results in, among other things, a lot of saved electricity
- You don’t even need to have a desktop computer at all – all you need to get the latest podcasts is your handset itself with an unlimited Internet (or Wi-Fi) connection.
Still, if you do want to know what desktop podcatcher applications there are, you’ll want to read either Smartphone & Pocket PC Mag‘s or Engadget’s tutorials (the former being far more thorough). They both discuss Doppler (probably the best desktop client; another also very popular one is Juice) on the desktop – and synchronizing the clients to your handset. More advanced users / hackers may also want to take a look at the MortScript-based PC -> Windows Mobile syncing solution HERE.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(Doppler on the desktop; by default, it downloads to c: \Documents and Settings\<username>\My Documents\My Music\My Podcasts\<feed name>).
Note that not even popular desktop browsers like Opera support automatic podcast downloading (that is, podcatching). Three screenshots showing this:
(podcasts shown in Opera)
(another rendering example– as you can see, Opera doesn’t download content)
(There isn’t anything you can do in Feeds / Manager Feeds / Edit (Properties) either, except for setting the interval of the auto-retrieve)
There are even fewer write-ups on the handset-based podcaster applications. The most important of them is Podcasts on a PDA..., which discusses three mobile OS'es and only few podcaster apps: WM (Egress), Palm (Quick News), Symbian (Nokia Podcasting) - as you can see, BlackBerries are not discussed.
Note that this roundup is a separate entity from my forthcoming RSS / Syndication Bible (to be published early September). I found it necessary to separate the two roundups from each other as, while, basically, they’re all RSS readers, their aim is different. In addition, some of the podcaster apps are just not recommended as an RSS reader and vice versa: some well-known RSS reader titles like Spb Insight (as of the current, 1.5.1 version) aren’t enclosure-capable at all.
Also note that because there are several high-quality and recommended podcast/catcher apps, I don’t have a definite choice. (If you really want one, I recommend NewsBreak if you are ready to pay for your podcaster and BeyondPod or HubDog if you aren’t.) Therefore, I don’t provide you a full tutorial of any of these apps either. However, in the chart, I do give you a lot of tips and tricks and describe how / where a specific feature can be found. This is why I provide the full menu path of all the, say, feature en/disabling checkboxes in the chart. I also provide several screenshots showing all this.
That is, while I don’t provide a full, 100% tutorial to any of these apps, as with all my chart-based articles, bibles and full roundups, I do provide you with hundreds (!) of tips and tricks in the chart. If you really don’t understand how you can configure a given podcaster, feel free to post a public (no private messages please) note and I answer your questions. I don’t think, however, that you wouldn’t understand them. They’re all (except for FeederReader, which does require a LOT of learning) fairly easy to learn. Just keep playing with your choice for some hours and you’ll start to know it like the palm of your hand. Then, all the puzzles will also fall into their places.
Now, let’s take a quick look at the podcast/catcher applications available for the three mobile platforms. Note that this section is in no way a full discussion and introduction of all the apps. The sole reason for this is the main chart’s having all the information you’ll ever need. That is, don’t expect this humble section to contain as much information as available in the 60 kbyte-long (!) and tabular (which eliminates the need for repeating the same info again and again) chart. Also note that all the apps are podcatchers, unless otherwise noted (with the case of CorePlayer and Pocket Player).
Let’s start with Windows Mobile, with remarks to the BlackBerry version of AudioBay and, finally, the Symbian-based Nokia Podcasting.
BeetzStream SmartRss V4.3157 - RC1
This app requires .Net CF 3.5 SP1 (while the other Compact Framework-based titles don’t need more than CF2) and MS SQL Server Compact Edition 3.5 SP1. The trial version is pretty useless: it limits you to 5 items per channel and will not save any setting changes, as opposed to the, in general, fully functional, 30-day test version of the other apps.
In a nutshell, I don’t really recommend this title - there're far better alternatives.
Kinoma Play
As of version 5.0.60, this recently-released player has excellent (streamed) podcasting features (but not podcatching at all).
It allows for directly entering RSS URL's in the main menu. It’s quite a bit buried under the different menus: it’s available at Settings / Player / Open URL:
The latest update (see THIS) has also introduced auto-pasting features (manual pasting doesn't work as the app uses nonstandard text input fields / areas).
While it doesn't allow for direct OPML input (that is, you can’t explicitly browse the file system to find the given file), if you just put the OPML file in the file system somewhere, it'll find the contents and list it under "My Media Files / Playlists" as in the following screenshot:
Note that if the OPML file also contains subfolders, they’ll be correctly rendered and the OPML file’s original name will be used as the playlist name. An example of this is (the highlighted) “BeyondPodFeeds” item in the above list.
Note that while it streams stuff, it, of course, needs to download multimedia content that it can’t play back streamed. Examples of this are the Tagesschau videos
pRSSreader
As of version 1.4.2, this, because of it being free and open-source, pretty popular generic RSS client has some limited podcatching capabilities. In no way as sophisticated as those of some of the other clients as, unfortunately, it in no way can be forced to automatically download enclosures (again, unlike most other podcatcher clients). In the top-level "Channels" view, Menu / Offline / Cache Unread Items only downloads all the articles, along with their images, and not the enclosures themselves.
Unfortunately, there's no way to initiate anything like "play all" from inside the app either. Fortunately, as pRSSreader stores the individual podcasts using their original name in feed-specific subdirectories (the subdirs having been named after the URL of the
It also has a cache manager (accessible via Menu / Cache Manager); unfortunately, it doesn't allow mass playback either (only mass deletion):
Initiating the in-app download of an enclosure involves several taps: after entering the article (two subsequent taps in the article title list), Menu / Enclosure / Download:
If, on the other hand, you want Internet Explorer Mobile to open the file, you can just click the name of the enclosure at the bottom (which has the same effect as Menu / Enclosure / Open).
Viigo 3.0.18
This is a multiplatform application: has Windows Mobile, BlackBerry and generic (also Symbian-compliant) Java MIDlet ports.
Even the most advanced Windows Mobile version is way less powerful than any of the other podcatchers. In addition, the BlackBerry version, as of current (3.0.224, released on Sept. 12) version has absolutely no podcast support (also see THIS for more info) and neither does the generic Java MIDlet version. Podcatching support is only promised for later. However, as I seriously doubt the podcatching support of it will be any better than the current (very weak) podcatching support of the Windows Mobile version, I wouldn’t be holding my breath either – it’s just too weak, even if you take into account the currently only real podcatcher on the BlackBerry, AudioBay, isn’t top-notch either.
Some WM screenshots:
(main view)
(podcast list view with menu)
(Properties of a feed – as can be seen, except for providing a login/password, absolutely nothing can be set)
(the player. Note that it couldn’t play back m4a (AAC) files; this is just a demo of how it looks like)
(the only setting capabilities Viigo has – see why I don’t recommend it?)
BlackBerry screenshots:
(Main: the feed list. No upper-level menus!)
(the menu in the feed list)
(the above two screenshots (an individual article view and the menu in there) show there aren’t even links for download using the built-in BB browser, Web)
CorePlayer 1.2.5 (also applies to Symbian / Palm OS / iPhone & other, supported OS’es!)
This is a strictly podcasting-capable application you should already have if you’re seriously(!) into multimedia. While it’s no doubt the best all-in-one player for Windows Mobile, Symbian and Palm OS, its podcasting capabilities are pretty limited. Hope this changes with the imminent release of the 1.3 platform with its downloading capabilities.
Incidentally, speaking of the iPhone, the situation seems to be otherwise pretty dire. This will, on the other hand, surely change in the future.
Conduits Pocket Player 3.7
It’s another strictly podcasting-capable application with somewhat better podcasting capabilities & compliance than those of CorePlayer. That is, if you also need podcatching capabilities, you’ll still end up having to get a separate podcatcher app.
A quick intro to accessing feeds: you can add a feed in Browse / Podcasts / Add Podcast Feed:
Double-click the new podcast to see the available enclosures:
Note that this screenshot has been taken with the MoDaCo feed, which Pocket Player has severe problems with. As can be seen, they’re in no way descriptive – unlike with other podcast downloading-capable apps compatible with the MoDaCo feed (that is, not for example CorePlayer). It’s only when actually starting to stream them by, for example, a left-right swipe that more info becomes available on a given MoDaCo podcast:
Note that I haven’t encountered similar problems with the other, tested (and working) feeds.
Hubdog 2.0
This podcatcher client is very famous for its Web & community capabilities. They aside, it’s still a very capable an decent client, albeit, in my opinion, can’t really match the speed and the easiness and intuitiveness of NewsBreak.
BeyondPod 2.8.0
This free app is probably the most featureful catcher of all. Highly recommended unless the speed problem introduced by its slow rendering engine really annoys you.
FeederReader 1.10.0
This is another featureful podcatcher with some really unique capabilities.
Too bad using it is like rocket science. You’ll want to start with the manual and also make you read the tutorials: THIS, THIS and THIS, in this order.
AudioBay 4.0/e0 (Windows Mobile) and 3.4/e0 (BlackBerry 8800);
Note that it also used to have a Symbian S60 version but has been discontinued in the meantime because of Nokia’s Podcasting. The Windows Mobile and the BlackBerry versions, on the other hand, are still developed.
The former (the Windows Mobile) version is pretty much average: not among the best titles but not the worst ones either. The BlackBerry version, on the other hand, is THE way to go. Note that, however,
1. AudioBay has no trial version (this should be fixed by the developer!)
2. Some people have found it to be unreliable, particularly on Verizon
(WM)
(BB)
NewsBreak 2.1
While this certainly isn’t the most featureful application, it’s by far the easiest to use. It has large, nice download icons associated with each podcast easily pressable. As soon as the download is over (which is the fastest of the bunch), the icon (which, after queuing the podcast for download, changes to a “Cancel” icon) changes to a “Play” icon. All this makes it possible to really easily queue, possibly cancel and, then, play back a given podcast. In this regard, NewsBreak is clearly the best of the bunch.
Top-level feed view
Channel view
Article view
Egress 4.0.1
Egress is another very strong title. iPhone(-alike) fans may prefer it to the other apps because of its iPhone-like interface. In my opinion, NewsBreak is better mostly because it takes fewer taps to queue something and is generally faster / easier to use. However, Egress is still a recommended title.
NewsGator Go! for Mobiles (current version as of late August 2008; internal filedates: 03/28/2008)
NewsGator, which has recently made been free, has a very strong Web-based interface. If you look for something like Opera’s Opera Link but with a generic subscription & already-read-flag synchronization, this should be the podcatcher to check out. Otherwise, I would stay away from it: it’s certainly lacking in features and, what is worst, is very-very slow in everyday use – even for normal (podcast-less) RSS use.
Skookum 2.0.0.0
Skookum is an abdandoned, free podcaster app. It has nothing to write home about; albeit, it’s certainly not the worst one either.
The developer is no longer in business (see for example THIS and THIS for more info). Sites like PocketGear only seem to have the commercial, initial and, therefore, in no way recommended, 1.0 version
Note that you will need to use CF1SP3 (or, of course, CF2+) to run it; it crashed on me, along with throwing a FileNotFoundException, right at the beginning with an older version.
Note that, while some of the errors (see see THIS and THIS for additional info) may show you you need to manually install System_SR_enu.cab (linked from HERE) , you won’t need to do this.
Much as the developer’s long been out of business, I haven’t disqualified the app as it’s free.
Symbian
With AudioBay’s Symbian S60 version discontinued (because of Nokia’s app’s release), Nokia Podcasting has become THE podcasting app for all S60 v3 phones. It’s generally very well done, fast at downloading and only lacking in some advanced features like channel image view.
It offers pretty nice, pre-configured choices, parallel downloading (of course, it allows for multiple selection with the Key button + the up/down arrow):
, automatic scheduling. However, it isn’t capable of parsing generic URL’s like that of MoDaCo for feeds. In these cases, you must enter the URL directly in Podcasts / Options / Go to Podcasting / Podcasts / Options / New Podcast:
Don’t forget to set your storage card as the download target at Podcasts / Options / Go to Podcasting / Options / Settings / Download:
The chart
As with most of my generic bible / roundup articles, the focal point of this bible is the feature chart, which makes it possible to pack in as much information in an article as possible, also allowing for direct, easy comparison between the different solutions. As usual, you’ll want to maximize it and, on smaller-resolution screens, zoom out to avoid (excess) scrolling. Sorry for the size: as usual, I wanted to present a full roundup; hence the gigantic size. The chart is here.
Explanation
Today / home plug-in showing the number of new podcasts etc. (NOT just a start / stop / pause control, with the song title, of the currently playing track!): some podcatchers also display the number / title(s) of newly downloaded podcasts (or simple articles).
Does it allow for user-def’d podcast categories?: more advanced catchers allow for organizing podcast feeds into user-defined categories. If you have more than a handful of feeds, this capability can prove VERY useful.
Feed login/password?: there are some private feeds requiring a login/password pair to only allow authenticated users to access their content. Almost all podcast/catchers support this.
Terminology used: particularly if you test more than one app, you may run into terminology inconsistency problems. For example, feeds are referred to as “Channels” by many. Feed contents are generally referred to as “items”, “headlines” or “episodes”. In this row, I’ve collected the terminology used by all apps so that you can avoid any confusion.
Support for non-supported (in general, non-MM) stuff?: here, I’ve listed non-multimedia stuff. Some feeds (for example, the C&L feed) not only have multimedia audio / video content, but also other stuff like YouTube links, Flash (.swf) and Adobe Acrobat (PDF) files etc. In this group, I’ve tested whether these kinds of files can be (manually – automatic download, in general, won’t work, except for very few titles like FeederReader) downloaded.
Download benchmarks (~20M mixed content over 512 kbps ADSL): in this test, I’ve tested how fast the app downloads to a 8GB Class 4 Sandisk card over a lower-end (512 kbps) ADSL connection. High-speed connections, of course, may have resulted in a much more pronounced difference. Just an example: over a very fast connection, NewsBreak is flying, while Viigo remains abysmal, certainly showing its file buffering / flushing algorithm is very weak.
Auto download / fetching: Supported? Refresh intervals / timestamp to execute?: Automatic podcast download / fetching is very important. In this row, I elaborate on which (or both) of the two updating timing is used: interval-based or a given, pre-set time of the day. I’ve also elaborated on the freedom of settings these parameters – that is, the granularity of the timestamp / interval setting. (Can you configure it to refresh the contents every, say, 5 minutes? Or, are you only allowed to do an update, say, at most once an hour?)
Download restrictions settable separately for each feed, as opposed to one, global setting?: Especially with sizable podcasts, it may be very important to be able to set completely different for example auto-deletion / retention parameters for individual feeds.
The storage requirements of different feeds can vary a lot. For example, there can be a feed with podcasts only taking up some 2-3 Mbytes at most (an example of these is Heart of Space, which only offers 30-second-long podcasts taking up only some hundreds of kilobytes), while other podcast episodes can easily be 50-100 Mbyte long (an example is X-Play’s lengthier movies). This means if you have little storage space but would like to keep as many podcasts as possible on your handset, you may opt for only letting for the retention of, say, 1-2 episodes of feeds generally having huge files, while not having so strict restrictions on feeds with small podcasts. In these cases, feed-level configurability (as opposed to one, global setting) can really pay off.
Distinction between allowed / blocked connection types to avoid using (expensive) cellular data?: some podcatchers allow for restricting the type of connection for downloading to avoid high data bills. The majority offering this capability has the ActiveSync vs. cellular distinction.
Can you define whether to force to open a connection if it isn’t available: some (unfortunately, VERY few) apps allow for very advanced functionality like enabling Wi-Fi / BT / the cellular radio (if any) before starting the update (and, when needed, disabling them after the update). In this row, I explained this (and similar) capabilities.
Storage usage restrictable / automatic deletion of listened-to / expired enclosures?: in percentage of free / remaining storage?: this subgroup has detailed information on whether you can fine-tune the storage usage by not letting the podcatcher download stuff that would result in the storage fill up. This is a basic setting and should be supported by all podcatching applications.
Permanent storage in the file system: can the home directory be set?: better apps, in addition to storing the podcasts on a storage card (or a, size-wise, comparable entity), may also allow for setting their home directory to anything, not just a wired-in directory name like \Podcasts.
Settable maximal number of enclosures kept?: Better catchers striving for efficient storage usage may employ a deletion strategy stating the following: whenever the pre-set maximal number of enclosures becomes too small to download the newest podcast(s), the oldest one (or an already-consumed one) is deleted.
Auto-deletion of podcasts older than X days?: storage saving may also be enhanced by allowing for (unconditional – that is, not depending on whether it has been consumed or not; see on this the next row) automatic deletion of podcasts older than X days.
Flags: Already listened to? What functionalities (not listing, deletion etc.) are based on this flag?: A decent podcaster application should at least flag already-consumed media as “read”. Based on this flag (and the visual presentation), the user would have the chance of not listening to the same podcast twice.
Podcasters behave differently when it comes to the read flag. For example, NewsBreak makes sure articles already read are put at the of the headlines, should you still need them. That is, at the beginning of the headlines list, you will only see unread articles. Some other casters “only” unbold read articles. Also, some of them have the “Hide read articles” functionality.
Better podcaster applications also have even more advanced functionality based on the “read” flag. The most important of this is (mass) auto-deletion of such articles. Too bad this really basic functionality is missing from most of them.
Not listened to, but old enough to be deleted (expired)?: in addition to the pretty basic “read” flag, some casters also employ other flags like “expired”, which, in a decent caster, would allow for deleting old, but not (necessarily) listened-to podcasts.
Note that some apps do support this functionality by just offering the “Delete all podcasts older than X days” functionality.
Downloads: Multiple downloading threads at the same time to make performance better?:
This row shows whether enqueued podcasts can be downloaded in parallel. The point in parallel downloading is as follows:
- Some servers serve podcasts considerably slower than your local Internet connection. Say you have a 2 Mbps connection, while the server you’re currently downloading podcasts is only capable of serving a podcast at 500 kbps. This means 1.5 Mbps of your Internet connection remains unused.
- You may want to quickly download something while another download is in progress. For example, let’s assume you’re downloading a huge podcast when you notice there’s another, interesting one you’d like to listen to as soon as possible. In a single-threaded (simple) app, you would either need to cancel the current download(s) to quickly queue the new clip as the first one to download. In a more advanced multithreaded app, you just start the download and it downloads (albeit a bit slower because the bandwidth available may be divided up between the current downloads), without further ado.
Progress bar (or any way to see what has already been downloaded): better apps have some kind of a visual feedback showing how many bytes (and/or percent) of a given podcast (and, preferably, all the queued podcasts) have already been downloaded.
Streaming (playback without downloading the entire enclosure (first)) Supported? : better players allow for streaming – that is, playback without downloading the entire enclosure first. Note that the built-in WMP doesn’t support this; CorePlayer does.
If streamed, random positioning supported?: there are two approaches to streaming – one that allows for quickly fast forwarding into still not downloaded parts of the podcast (that is, allows for really free random access, independent of what has already been downloaded) and the simpler one that doesn’t. Naturally, the former is preferred.
Here, n/a, naturally, shows the given app isn’t at all able to stream.
Feed input (in addition to direct address entering, which is supported by all): OPML import / sync?: There are several ways of making podcast/catcher apps aware of the feeds you’d like to subscribe to. In addition to by directly entering their URL’s, one-by-one, the most important way of importing them is via OPML files.
Note that several of the apps also support exporting into OPML files of your current subscriptions, which makes it easier to transfer your current subscriptions to another (OPML import-capable) podcatcher/caster.
M3U / PLS support?: some apps also allow for mass-importing feed URL’s via the well-known M3U and/or PLS playlist files. (See for example THIS for more info on these formats.)
Pre-defined, built-in library?: many of these apps have some kind of access to predefined, online libraries already offering feeds you can subscribe to.
Online search?: there are several services allowing for feed lookup based on their names. Some of the handset apps have interfaces to directly access these services.
Generic HTML page parsing if unsure about the exact feed URL?: (very) few apps allow for parsing generic HTML pages to find feed URL’s in them. (This is how most desktop browsers and Opera Mini work when they display a “This page has RSS feeds in it” type of message.)
Online, web-based, synchronizable and/or readable account?: one of the best capabilities some of these apps offer is an online account allowing for either account management (importing / deleting etc. feeds, sharing them with your friends, the community etc.) or on-line article reading via any Web browser – or both.
The former greatly simplifies subscribing to feeds (and deploying the same set of feeds to other, OPML importing-capable podcasters later).
Built-in player (if any): AVRCP: while the majority of these apps rely on external players to play even the most basic and widely used podcasting file formats like MP3, some of them have a built-in player to play them back. It’s the limitations, capabilities, CPU (and, consequently, battery) usage of these built-in players that this group is all about.
The first test in this group, AVRCP, discusses whether Bluetooth remote control, AVRCP, is supported by the player (if any). Naturally, as with most of the entries in this group, n/a means there’s no built-in player in the app at all.
CPU usage?: The CPU usage of multimedia players is of extreme importance when it comes to maximizing battery life. This is why I’ve made some extensive tests to find out how these apps behave in this regard. Please also see THIS for more info on the well-established players.
Remembers last position (resume-capable)? And, even better, auto bookmark-capable?: with sometimes lengthy podcasts, it’s essential for a player to be able to resume playback after restarting (simple resume) or even switching to another and, then, returning to the same podcast (more advanced bookmarking capability; now, storing a “last playback position” associated with each podcast file, not just globally for the last played one).
Positioning (with already-local playback); + stands for external players with podcatcher apps without a built-in player: it’s also essential for a podcast playback application to be able to randomly position inside the already-local podcast. Note that this has nothing to do with the positioning capabilities of still-downloading and/or streamed apps, which was elaborated upon earlier.
If it does have a player, can you still use an external one?: almost all the built-in players are definitely inferior (buth CPU usage- and capabilities-wise) to those offered by other, third-party players. Therefore, particularly with podcaster applications having a low-quality player, it’s essential to be able to configure it to be able to invoke an external multimedia player to play back any multimedia content.
Channel / individual song image support: Generic channel image displayed?: This group elaborates on whether generic (non-podcast-specific) channel images and podcast-specific, inline images are supported.
The first test, “Generic channel image displayed?”, shows the podcaster app is able to display the generic image associated with a channel. This is in no way essential, just cool to have and makes it easier to easily spot a feed, particularly if there are more than a handful of them.
Album art / article display? :
Note that, with external players, this will only players that do support embedded artwork in individual podcasts; that is, NOT the built-in Windows Media Player Mobile in Windows Mobile. See the first chart HERE for more info on this question and the compatible apps.
Mass playback / delete operations: Mass playback in a given channel?: this mass operation-specific group elaborates on operations best done in one step instead of doing the same separately for each and every headline / podcast – that is, using mass operations.
The first of the tests, “Mass playback in a given channel?”, elaborates on whether the podcasts of a given channel (feed) can be played back in order without having to manually intervene (that is, start the next one when the previous is finished). This is of extreme importance with shorter clips you’d like to see. Just a real-world example: during my last 10-hour-long bus trip, I’ve watched almost all the episodes of X-Play. These podcasts are, in general, some 2…5 minutes long. As the client (the otherwise great NewsBreak) doesn’t support mass playback, it was quite a nuisance to always having to switch back to NewsBreak (from CorePlayer playing the video) and tap (with my finger) on the next feed’s “Play” icon.
With podcaster apps capable of mass playback (either in a given channel/feed or globally, with all available podcasts), you don’t need to constantly switch back to the podcaster app to start the playback of the next podcast.
Incidentally, behind the scenes, mass playback is accomplished by using playback (m3u / pls / asx files). This is how podcaster apps instruct external players to be aware of more than one playlist items. Also, this is why some of the podcaster apps (for example, Egress) explicitly refer to creating playlist files upon downloading.
Mass playback globally (not just in one channel, but all the new enclosures)?: while the previous row discussed in-feed mass playback (without human intervention), this one refers to playing back all the clips globally, originating from all feeds, not just one. Unfortunately, as with the feed-only playback, very few podcasters support this.
If (any kind of) mass playback is supported, audio / video distinction (unattended “Commute mode“ as referred to by FeederReader?): when you, for example, jog and, therefore, can’t watch the screen of your handset, in a mass playback mode, distinction between audio-only and video content can be highly useful. This way, you can be sure no video will be played back while in mass playback mode; only audio.
Mass deletion of all enclosures? If possible, can you do this on both globally and just in an individual channel?: in addition to mass playback, mass deletion can also be highly useful. Here, I elaborate on both global and in-one-feed mass deletion capabilities.
Filename naming conventions (for quick file system-level lookup, mass playback queuing from external players, deletion etc.): there are two approaches podcatcher applications use when downloading streams (one of them, BeyondPod, also supports both): either keep their original names (in some cases, adding a unique, machine-generated trailer/header to make sure no accidental overwriting will occur) or use a fully machine-generated name, mostly consisting of running indexes.
Both approaches have advantages. If you keep the original podcast filenames (particularly if you do this in separate, feed-specific subdirectories in the file system), you won’t need to do any lookup to find out what a given podcast really is. Also, queuing podcasts for mass playback (particularly if they’re in a separate subdirectory) becomes far easier. However, it’s prone to the overwriting problem, which may be particularly an issue with, in this regard, not very well written applications like
If you only have index-based and/generated random indexes, accidental overwriting won’t even occur. However, you may have a hard time identifying the podcasts in the file system, should you want to access them in an external media player without firing up the podcatch/caster application.
Of course, there are combined solutions as well; for example, Egress uses both a unique, random leading string to make sure no overwriting will take place and, after this, the original filename follows.
Compatibility with some real feeds: MoDaCo: in this pretty large group, I’ve presented some real-world test results on whether these podcast/catcher applications are compliant with some real-world, popular podcasts. The first of the test is MoDaCo’s, which causes some problems to, for example, Pocket Player (the fix is promised for the next version). It’s, otherwise, a pretty usual MP3 podcast. CorePlayer, which, as of version 1.2.5, has still pretty bad RSS feed parsing capabilities, is fully incompatible with this feed.
1Src Palm-powered Podcast (MP3): another usual MP3 podcast, no real catches here, except for Skookum, which can’t download more than one podcast a time, as it erroneously assumes the filename being “redirect.mp3”, which results in downloading subsequent episodes overwriting previous downloads.
Heart of Space (Mp3): another pretty usual feed. The only podcaster not compatible with it is NewsGator Go! for Mobiles: while it can download it, it can’t invoke an external app to play it back. This is a pretty common issue with NewsGator Go! for Mobiles, several other feeds are also suffering from this problem.
SpaceMusic Archive (MP3) and (Current) SpaceMusic : no problems at all with any of the apps.
Radio 538 (AAC-LC) : now, this is a problematic feed causing issues with many apps. For example, CorePlayer has problems with the 080804 issue, while the other episodes (for example, 080811) work just fine.
Also note that it isn’t an MP3 podcast but an AAC-LC one. Therefore, many podcasting/catching apps are simply unable to play it back – or, for that matter, even retrieve it.
Classic Animation (H.264 Baseline video): switching to videos, Classic Animation is a great source of old cartoons. They have their stuff in H.264 baseline format, which means great compatibility with a lot of multimedia players (as opposed to more advanced H.264 formats).
It worked with most podcasters, except for NewsGator Go! for Mobiles, which exhibited the same trailing bug as with a lot of other feeds.
X’Play’s Daily Video Podcast : these videos are high-res (VGA, 640*480) and use a more advanced, non-baseline H.264 format meaning very few players (most importantly, CorePlayer on all mobile platforms except BlackBerry) will be able to play them back.
Tagesschau Podcast (MP3): these MP3 files are the plain audio tracks of the Tagesschau video programs. They’re different from the previous titles (but not the original “video” versions) in that they have a much more complicated feed URL. Probably this is what makes these feeds inaccessible for several podcatcher/caster apps (CorePlayer, Hubdog and the BlackBerry version of AudioBay).
Tagesschau Video Podcast (MP4 / H.264 baseline): the situation is pretty similar with the original video versions of these programmes.
Other sources of information
A REALLY cool post on desktop podcasting
VoiceIndigo for BlackBerry
What are you using to “podcatch”?
A german list
Another quick news item on the PPCMag article
A 2006 thread: RSS reader with podcast support for TyTn, any suggestions?
Mostly a FeederReader-specific thread
Note that, while some feeds (for example, C&L) offers the capability of accessing two videos from one article, physically, they only hold one enclosure, not two (they only link to two videos). An example screenshot series:
No longer existing or plain weak applications
SmartFeed, an old, still widely known, popular app, has been incorporated into NewsGator in the meantime.
The Windows Mobile version (as of beta3) of the otherwise very nice and famous Doppler is pretty much useless and far inferior to any of the products in the chart. Still, a quick elaboration, should you still want to know why I don’t recommend it.
First, unless you have a lot of built-in storage, in Menu / Options / Settings, you’ll want to change the default podcast download path, \My Documents\My Podcasts. Finally, after a double-click on the feed, select Menu / Download podcast. Trying to update feeds / podcasts has always resulted in constant problems; then, also Aborting download… has stalled and required a manual, forced task kill. Therefore, it seems the only way to download the podcasts is via the built-in Internet Explorer (that is, fully manually – which is in no way recommended; after all, podcatchers exist just in order to avoid doing this), you can manually tap the link after double-tapping an article.
PiP (also see for example THIS) has been discontinued in the meantime.
Pocket Podcasts 1.0 is also pretty weak and requires a desktop-side server; this is why (on purpose) I’ve left it out.
Appendix: the Microsoft Zune
The desktop client of the Microsoft Zune allows for podcatching and synchronizing – just like Doppler, Juice and iTunes (and unlike WMP 11). I found it useful to include this section in this guide as
1. after all, the Zune is a portable device
2. Microsoft promises "Zune store integration", which is quite a bit similar to that of Nokia’s on-device music store solution. One can only hope Microsoft also makes the podcatching and synchronizing capabilities of the desktop Zune version 2+ available for Windows Mobile clients as well – even if "only" on the desktop side, and not natively on the Windows Mobile clients (unlike, say, the way Nokia implemented their Podcasting app).
The desktop podcatcher component of Zune has no timing capabilities (it starts downloading new episodes as soon as you connect or wirelessly sync your Zune, which also starts the Zune app on the desktop), which may be a bit disappointing, particularly if you have a lot to download (which may also greatly slow down the desktop) and/or have a slow connection and, therefore, need to wait a lot for all the new episodes to download. Nevertheless, it has a very simple and logical interface, which is really easy to use, while still offering advanced capabilities like feed-specific retention and synchronization settings (the ability to set the number of episodes to store on the desktop / on the Zune, from 1 to 10 and including all).
It also has a built-in search, should you want to avoid having to directly paste the feed URL's to Zune. All you need to do is just entering the name of the podcast feed (like "modaco") to the search input field. It found most the English and German test podcasts. It, however, didn't contain anything Finnish from THIS list, not even English-language ones like Radio Free Finland. I needed to add these feeds, then, one by one.
Unfortunately, it doesn't support OPML import – not even in the current, just-released, 3.0 milestone version. It didn't have problems with parsing any of the directly entered URL's, unlike some of the tested apps.
Some screenshots (of version 2.X; the latest, 3.0 version isn't at all different when it comes to podcatching):
http://www.winmobiletech.com/082008Podcasting/zune20podcast.jpg
(General settings)
http://www.winmobiletech.com/082008Podcasting/zune20podcastseriesstting.jpg
(Feed-specific settings)
http://www.winmobiletech.com/082008Podcasting/zune20podcastmain.jpg
(Main podcasts screen, showing all the subscribed feeds on the left and the episodes in the middle; the state of the current download etc.)
http://www.winmobiletech.com/082008Podcasting/zune20syncgroups.jpg
(sync group-view, also showing the total space)
http://www.winmobiletech.com/082008Podcasting/zune20justsyncing.jpg
(Just Syncing-view)
Unfortunately, the Zune client does have its share of problems. For example, it entirely lacks MP4 (m4a) chapter support (like the ones in the enhanced MoDaCo podcast feeds or the Tiesto feed). Not even the just-released 3.0 desktop/device software fixed this.
Also note that Zunes can't update traditional podcasts over the air (only the newly (in version 3) added channels, but these channels can't be manually created) without the need for syncing with the desktop Zune software. Yeah, I know podcatching (with everything involved: incompatible feeds, incompatible formats can't be natively played back on the Zune etc.) isn't at all trivial; still, I would really welcome full podcasting client support as opposed to the pre-made, no-user-channels-possible channel syncing currently supported. Microsoft could, for example, just port the podcatching code from the desktop software to the device firmware. It's pretty solid and dependable; again, it was able to sync to all the feeds I've thrown at it not necessarily present in Microsoft's library.
(Some other, Zune & podcatching-related articles:
How to manage podcasts in the Zune software: this is the current one; also applies to 3.0.
Some examples of old, outdated, pre-version 2 tutorials:
How to Manage Podcast Content With Your Zune and HOWTO: Podcasting with a Zune. These are, again, outdated; now, there is absolutely no need to use an additional podcatcher in addition to the desktop-side Zune app. (This is also reflected by ExtremeTech's initial article Zune: iPod Killer or Half-Baked Flop?). Note that it was with the release of Zune 2 a year ago that podcatching has been added to the desktop software.)