Many of you may have already heard of H.264 (Wiki page HERE) or AVC (for Advanced Video Coding), the latest-and-greatest video standard, widely used in everywhere where the best possible video quality is required with the least possible storage and/or bandwidth usage. It’s pretty much comparable to HE-AAC v2, the latest-and-greatest encoding in audio technology, which allows for quality (!) stereo Web radio streaming at even 24 kbps, and CD-quality recordings at 48 kbps. (Pretty much unbelievable, particularly at 24 kbps, with traditional compressed formats like MP3, WMA or even OGG, isn’t it?)
AVC is way better than the “old” MPEG-4 Part 2 or “ASP”. The latter is more commonly referred to as “DivX, Xvid”; in this article, I only refer to it as “ASP”, while I refer to the above-introduced H.264 format as “AVC”). While it gives you the same (or even better!) video quality, it is, in general, between 50 to 100% smaller and decidedly more flexible.
A lot of misconceptions or plain false info is circulating in the Windows Mobile, Palm and Symbian community; this is why I’ve found it extremely important to publish my AVC guide well before finally publishing my long-promised all-in-one Multimedia Bible.
Now, I take a look at whether you want to use it at all.
1.1 Pros and cons
First, let’s elaborate on why you would want to go for AVC files instead of the well-established and supported, plain, “old” ASP ones.
1.1.1 Cons
1.1.1.1 Battery life considerations
Decoding AVC, depending on the special AVC features used, the bit speed and the resolution, can require up to five times more CPU cycles than doing the same to ASP. In this section, I elaborate on what this results in in practice.
You may know it well enough that the more CPU cycles a given app uses, the less battery life you’ll have. This in itself may be a stumbling block for you.
Of course, this wildly differs between different CPU’s. For example, TI OMAP-based devices (particularly newer, latest-generation ones like the Nokia N95) consume far less power than Xscale-based ones. To demonstrate this, some examples.
A Nokia N95 playing an 320*144
* ASP encoded at 83 kbps (resulting in about ~30% CPU usage)
* AVC encoded at ~400 kbps (resulting in slightly less than full, 100% CPU usage)
results in the following power consumption:
{
"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"
}
(the first half of the chart shows playing back the first, the second half the second video).
As can clearly be seen, the difference really isn’t much – about 280 mW, which roughly corresponds to ~90 minutes battery life decrease using the stock 950 mAh battery. That's about 30-35% battery life decrease.
(Note that I couldn’t make the same on TI OMAP-based Windows Mobile devices as it’s not at all possible to measure the current on them – “only” the CPU usage.)
Now, let’s see how other CPU’s behave in this respect. Let’s see the same test on the 624 MHz Intel Xscale PXA 270-based Dell Axim x51v. (Backlight level: as with the Nokia, the lowest.) In here, I’ve tested a 320*144 AVC encoded at ~400 kbps (about 30% CPU usage at 624 MHz) without any manual quality degradation and a 640*272 AVC encoded at ~460 kbps, without deblocking (near 100% CPU usage). For the test, I’ve enabled dynamic CPU scaling (that is, I didn’t run it on external power) so that the CPU could switch down to a lower frequency while playing back the lower-resolution video to increase the battery life to some degree.
The upper chart shows the power (in mA), the lower the CPU usage. As can clearly be seen, the power usage of playing the high-res AVC video at ~100% CPU usage required about 70% more power (480 / 280 mA) than doing the same with the QVGA-resolution AVC video. That is, while, on the TI OMAP-based Nokia, you will “only” encounter a 35% battery life decrease, on anything (!) Xscale-based, about 70% (!!!!). Yes, the (newer) TI OMAP platform does have a lot of advantages, one of them being not chewing through the battery when running CPU-intensive tasks, while still delivering excellent performance.
What does this all mean?
If you have an Xscale-based handset and have plenty of battery / a spare or an extended one OR you’re running a (particularly new-generation) TI OMAP-based handset (Nokia N95 etc.), you don’t need to be afraid of the battery life: go for the best quality; that is, AVC providing you with the best watching experience.
If, on the other hand, battery life is of extreme importance for you and you use a Xscale-based device, make you will still want to prefer ASP (or, low-quality AVC) to AVC.
1.1.1.2 You’ll be forced for (slow!!) recoding – unlike with ASP
First and foremost, as can also be clearly seen based on my very thorough tests, you in no way can play your familiar, “torrented”, full PAL/NTSC-resolution video clips / movies on current hardware. This is diametrically opposed to the case of ASP, where you, in most cases (except for the slowest TI OMAP-based Windows Mobile devices), can.
This means you MUST recode your videos before watching. You can’t just quickly drop your fresh-torrented, PAL/NTSC full-resolution (720*480 or 576) AVC’s on a memory card and just use CorePlayer (or TCPMP) to watch them. When they become available, that is; currently, on the Torrent scene, mostly, “only” HD (720p / 1080p / 1080i) videos are encoded in AVC, traditional, “low-res” PAL/NTSC rips are (still) all ASP’s.
Not even the best, most powerful handheld devices are able to play full PAL/NTSC-resolution videos (let alone 720p / 1080p / 1080i ones!). You must recode everything to either the native screen width of your device (which, again, isn’t the case with traditional ASP videos) or less and, in cases (for example, with VGA devices and/or slow (200 MHz) TI OMAP-based Windows Mobile handsets), you must deactivate some of the advanced features. This, again, isn't the case with "traditional" ASP files.
As noone not having a mobile device him or herself will deliberately rescale his videos (primarily meant for desktop watching) to a 640 or, God forbid, 320-wide one and, probably, even remove some features, which results in a visible quality decrease. With ASP files, you can just watch files originally meant for desktops on a handset; with AVC files, you can’t.
In addition, recoding, as opposed to creating ASP files, is a time-consuming process. In general, creating an AVC video takes 2-3 times longer than doing the same with an ASP one.
1.1.2 Pros
If you MUST use the least possible video sizes (because, for example, you don’t have an SDHC-enabled handset) with the best possible quality, H.264 is the way to go. It’s simply unbeatable and is way better than ASP at the same (low) bit speed. Again, it’s like how HE-AAC v2 compares to MP3.
Also, the MP4 container format used by the recommended Nero Recode makes it possible to have two (!) sound tracks in the same file. This was very hard to achieve with AVI files without some manual work. To my knowledge, there aren’t any Windows Mobile (Symbian, Palm etc.) related tools that let for storing two sound tracks in an AVI file. (It’s, technically, not impossible.)
Finally, once you learn how to navigate around in Nero Recode, ripping DVD’s or converting your other videos becomes very easy. No command-line tools are necessary – albeit, of course, you can use them too. For free, I should add – the most important command-line tool to encode into AVC, x264, is highly recommended and is of high quality. It, however, takes a while to learn – this is why I tend to recommend Nero Recode instead.
Nero Recode is, at first, seems to be a bit more complicated to use than well-known, established Windows Mobile DVD / video conversion tools like Pocket DVD Studio, Pocket DVD Wizard etc. Also, it’s a lot more expensive (around US$ 90). However, taken into account that several other AVC encoders are more than five times more expensive and you also get a complete suite of for example CD / DVD burners, the price can be justified. And, again, it only takes, say, an hour to completely learn to master the tool - unlike with x264.
(Note that, as the aim of this Bible is NOT showing you all the necessary encoding tools and tricks, I "only" discuss Nero Recode. It's readily available for download as a pretty much usable trial, isn't much overpriced and is MUCH easier to use than free tools. It's particularly because of the latter that I've chosen it to be featured in this Bible. Should you need another tool, look around HERE. I particularly recommend the decoder comparisons linked from HERE.)
1.1.2.1 Sample videos
In order to show you how much better AVC videos are than plain ASP ones, I've uploaded several of my test videos for you to evaluate. They're all 29-second, bilingual (English & German) and with two subtitle streams (English & German) and have been encoded for best quality (two-pass encoding with the best quality defaults).
In order to play them, you'll most probably need an AVC-compliant video player (if you don't already have a H.264 decoder on your system; for example, Cyberlink's newer PowerDVD versions do have a pretty good one - albeit in no way as efficient as CoreAVC, which I'll talk later. To play back these videos, it's more than sufficient). The easiest is getting VideoLAN VLC. Just download & install it (no need to fuss around with separate codecs - it contains all), start and open the video files.
320*144 videos:
87 kbps:
ASP (the worst - at 87 kbps and 320*144, using traditional ASP produces pretty bad results). As with the other bitrates & resolutions, this file is called "ASP.mp4".
AVC with all AVC goodies enabled - now, compare the quality of this title to the above-linked ASP one. Quite different, isn't it? Yes, AVC is WAY better at really low bitspeeds like 87 kbps. The file is named "default.mp4" - as will be the case with other bitrates.
AVC without bilinear prediction / CABAC support: this video has been encoded without two major AVC features to heavily reduce the load at runtime (and help speed up playback). (Note that I'll speak of bilinear prediction / CABAC later.) Nevertheless, even without these features, it's way better than ASP.
The same videos, encoded at 273 kbps and 320*144. As can clearly be seen, ASP produces much better results at this speed than at 87 kbps; still, AVC still has the lead, even without bilinear prediction / CABAC.
Sample videos encoded at three different bitrates (204k, 366k and 464 kbps) and at 640*272. Note that, with the second group, I've also made available two other videos. THIS one demonstrates the video quality degradation with bilinear prediction disabled; THIS with CABAC disabled. (Again, the 363k group also has the video that shows the "combined" effect of disabling both features - it's, again, named "nobilinNoCabac.mp4").
I really recommend scrutinizing these videos. For example, in the next scene at second 13 into the sample movie:
it's really worth checking out the following:
- the wall (it'll be "moving" all the time, producing a very bad effect, particularly with ASP and/or deblocking disabled)
- the effective resolution of the balls on the pool board (it'll be decidedly lower with 320-wide ASP videos than AVC ones, showing ASP not only sacrifies at quality (blockiness), but also at resolution at such low bitrates)
- the "blockiness" of the green pool board around the balls.
As you'll see, ALL these test videos show how much better AVC is, image quality-wise.
Now that you’ve seen both the advantages and disadvantages of AVC, let’s take a look at what players there are to play them.
1.2 Available players for mobile platforms
(Note that this guide doesn't cover the features not directly related to AVC playback - for example, AVRCP support, equalizer etc. because they can also be utilized playing back other content. They'll be all elaborated on in my forthcoming Multimedia Bible.)
1.2.1 Windows Mobile
1.2.1.1 CorePlayer
Without doubt this is the best player out there to play H.264 content. It’s by far the fastest, most compatible and featureful. If you’re seriously into H.264, you MUST buy it: it isn’t THAT expensive.
1.2.1.2 TCPMP
For this free app to be able to play your AVC videos, you MUST download THIS (originally linked from HERE; mirror HERE) add-on CAB file. Install it after having installed TCPMP. The CAB file contains a beta version of an early Windows Mobile CoreAVC port and the well-known AAC decoder already discussed and linked to HERE. (A quick note: CoreAVC is the main AVC decoder of all multimedia products of the CoreCodec folks. CoreAVC, on desktop operating systems, is unrivalled in speed – it’s even faster than some hardware-supported, much more expensive solutions. The speed advantage is certainly visible with the mobile ports as well.)
Note that there is another AVC decoder, the official ffmpeg codec, which is WAY slower than this beta and is, therefore, in no way recommended.
While the app has certain strengths (most importantly, it’s free), I don’t recommend it for serious AVC freaks – it’s just not powerful enough.
1.2.1.3 Nero Mobile Pro
Unfortunately, while the encoder (“Nero Recode”, part of the Nero 8 Ultra Edition) of the same developer is without doubt excellent and highly recommended, their Windows Mobile player, the commercial Nero Mobile Pro, is not recommended for playing back AVC content. (Or, for that matter, currently for anything else either: in my tests, other media players have turned out to be much more efficient and featureful in almost every area. It seems its only advantage is the native ability to play back HE-AAC v2 audio. To do the same, however, you can always use the free TCPMP with the AAC plug-in – and it’ll still result in better battery life than Nero Mobile Pro.)
Unfortunately, there’s no trial version of this app any more. While Nero 7 Ultra Edition Enhanced did have a trial of Nero Mobile Pro, Nero 8 doesn’t. Before a trial is (re)introduced, you can safely take my word: it’s, currently (as of version 1.4.0.9), just not worth the price (I’ve paid some 15 euros + VAT for it). And, it costs the same as the technically VASTLY superior CorePlayer – why would you, then, go for it at all?
As far as its performance is concerned, on VGA Pocket PC’s, it’s only usable with 320-only (QVGA) videos; of them, ONLY with ones without CABAC and Bidirectional Prediction. This pretty much rules it out as a decent player. If you do enable these (important) features, there will be a lot of dropped frames – on even the fastest handsets like the Dell Axim x51v.
640-pixel-wide videos, even ASP ones, badly lag; the AVC ones, in addition, have stuttering sound, even at the lowest stream speeds. That is, it’s impossible to play back VGA content under Nero, not even if you do all the recommended performance tweaks.
On QVGA devices, the situation isn’t better either: it’s only able to play the lowest-speed QVGA AVC movies. On my 400 MHz HP iPAQ h2210, the video was stuttering even when using a 83 kbps video stream (a ~230 kbps one was even worse). I haven’t tested it with deblocking-disabled videos but I don’t think it’d improve the situation.
All in all, stay away from this app. While their encoder (Nero 8 Ultra Edition) is certainly worth purchasing (if you don’t want to manually convert your DVD’s or other files to AVC with alternative tools like x264), Nero Mobile Pro is in no way.
1.2.1.4 In no way recommended, other apps
Philips’ Platform4 player (no longer developed, entirely abandoned, low-quality)
GPAC Osmo4/Osmophone
VideoLan – long-abandoned and has never really worked. When it did, it only produced at least an order of magnitude worse speed than TCPMP / CorePlayer.
1.2.2 Symbian
To play AVC videos under Symbian, your only real choice is CorePlayer.
Note that the built-in RealPlayer is also stated to be AVC-compliant (not only ASP). If it is, then, it must only be compliant with the simple Baseline profile, which isn’t what you will really prefer. I’m absolutely sure it’s not compatible with the Main profile, not even without Bidirectional Prediction and CABAC.
As far as other Symbian players are concerned, SmartMovie (as of version 3.41) doesn’t support AVC videos at all (it doesn’t even list MP4 files). The recently-released MMPlayer (as of version 1.01) doesn’t support AAC sound (see their official list of what’s already supported and what is planned HERE). This means it can’t play back AVC videos either because AVC videos generally use AAC sound tracks.
1.2.3 Palm OS
Here, CorePlayer is your only choice. MMPlayer doesn’t support AVC and, unlike with Windows Mobile, the Palm version of TCPMP doesn’t have an AVC add-on.
1.3 MP4 as a container; compatibility
AVC videos can be delivered in many so-called “containers”. The most widely used is the MP4 container, which, in addition to the video itself, can also have two (AAC) sound tracks, two subtitle streams and chapter support. Nero Recode supports these features. If you would really want to include two sound tracks in your videos and plan selecting your players based on these needs, then, you will find this section useful.
In the following chart, I list the compatibility of mobile players with these features.
http://www.winmobiletech.com/122007H264Bible/t1.png
As can clearly be seen, both Nero and Symbian’s RealPlayer are unable to switch to the second soundtrack. They don’t support chapter information either. The latter may turn out to be a letdown with direct DVD conversions.
Finally, none of these players support the Nero Recode subtitle format – unlike for example the free VideoLAN on desktop operating systems.
1.3.1 Matroska (.MKV) support
There is another, compared to MP4, more advanced container format called Matroska, which is especially popular on the High Definition ripper / Torrent scene (as opposed to “plain” DVD-only resolutions). Matroska files generally contain AVC video. CorePlayer supports these containers.
Note that, however, CorePlayer is only able to play back videos no wider than 1008 pixels. That is, it will NOT play back for example torrented 720p (meaning 1280-wide videos) content – most of current MKV files contain these kinds of videos. This is pretty much understandable if you take into account that most (particlarly QVGA) mobile hardware is simply unable to play back even 640-wide videos, let alone ones with much higher (twice the size!) resolution.
1.4 Fixing the frame drop problem
Unfortunately, as has already been pointed out, playing back AVC files requires a lot of computing power. On especially slower and/or (W)VGA or other hi-res devices, you MUST make some tradeoffs in order to be able to play back your AVC contents without problems (dropped frames).
In addition to lowering the resolution if you use a non-QVGA (read: (W)VGA on Windows Mobile, 320*480 on Palm OS or the screen resolution of communicators like the E90 on Symbian), you have four choices:
1.4.1 Using the simplest (Baseline) profiles instead of Nero’s “Standard – AVC”
Sticking with the simplest (Baseline) profiles means avoiding using the (standard) Main profile. This will still result in considerably better-quality results than with ASP, but, in my opinion, isn’t the best way to go because it’s definitely an overkill. That is, by fine-tuning the much more featureful Main profile, you can get much better results.
That is, if you stick to the Baseline profile (by, say, using the “Mobile AVC” or “Portable AVC” profiles in Nero Recode – as opposed to “Standard AVC”, which roughly corresponds to the “Main” profile of the H.264 standard), you will not have access to a lot of goodies that, otherwise, wouldn’t decrease your playback performance that much but still add a lot of additional functionalities and subtly increased image quality.
For example, if you don’t use the “Standard – AVC” Nero profile, you won’t be able to select HE-AAC for audio encoding, only the substantially worse AAC-LC. As has already been explained in the recently published 2nd Multimedia Bible sneak peek: crossfade / gapless playback, (audio) media compatibility and power usage, CorePlayer (as opposed to most other players; for example, TCPMP) doesn’t use considerably more CPU time for decoding HE-AAC audio; therefore, you’ll want to use HE-AAC with CorePlayer and not AAC-LC. If you, however, use a “dumb” profile, you won’t even have a chance to select HE-AAC.
However, when you do plan to watch your videos with TCPMP only (or, other, technically not so advanced multimedia players), you must keep in mind that the situation is pretty much the opposite. Then, you WILL want to switch back to AAC-LC by selecting the “Settings” radio button (highlighted in HERE, the mouse hovering over it), clicking the “Custom profile:” radio button and selecting AAC-LC as can be seen in HERE.
There will be other cases (for example, playing back AVC on slow TI OMAP CPU’s), when this (using “simple” profiles) is what you will want to prefer. Note that, again, the video quality will still be better than that of traditional ASP at the same bitrate – that is, it’s still a usable tradeoff. On other (faster) platforms (practically, anything non-TI OMAP-based, except for the newer Nokias, which already are based on a vastly enhanced TI OMAP), you will ALWAYS want to stick to the Main H.264 profile (accessible as “Standard AVC” in Nero).
Note that Nero Recode also has some other, device-specific profiles. Of them, many recommend for example the iPod 5.5G profiles for VGA users (it, using the default, automatic settings, encodes 640-wide video at 728kbps). However, I don’t really recommend it because the iPod 5.5G profile doesn’t support a number of advanced features (for example, CABAC and/or Bidirectional Prediction) – why not stick with the Standard profile, then?
Also, many recommend the Sony PSP profiles of Nero. I didn’t find them particularly useful either, particularly if you’re a high-res (VGA etc.) user. The sole reason for this is that it only encodes in low resolution.
1.4.2 Switching off Deblocking
Deblocking is a genuine AVC (not available in ASP) feature to heavily (!!!) reduce blocking effects and really increase image quality. It’s really-really useful, particularly with slow (80…120 kbps QVGA or 200-250 kbps VGA videos), while “only” consumes about 10-20% CPU cycles.
Disabling it will, therefore, increase playback performance by 10-20%. Note the following:
1. You should ONLY disable it when there is simply nothing else to do to increase performance. The two other (encoding-time) tweaks I’ll introduce in the next two sections, that is, disabling CABAC and/or Bidirectional Prediction, result in a much better performance gain, while retaining much better playback quality.
2. Some people state (example HERE) that switching off deblocking at video (re)coding time should be preferred to (plain) runtime switch-off. I’ve thoroughly benchmarked this and found out that, with the recommended CorePlayer, this is not the case (unlike what the original poster stated) - you won’t see almost any performance increase of not encoding your videos with deblocking support at all.
That is, with CorePlayer, where deblocking can be disabled by hand when you play back your video, disabling deblocking at encoding time isn’t necessary – there’re simply no advantages of doing it. With TCPMP or other players that don’t allow for disabling deblocking at runtime, however, you might still want to do this at encoding time. The speed increase will be pretty much similar to that of CorePlayer. (But, again, if you’re seriously into AVC, I simply don’t see the point in sticking with alternative and, technically, inferior products like TCPMP or Symbian’s RealPlayer – CorePlayer is THE fastest and THE best AVC player definitely worth its price.)
Disabling deblocking at runtime (again, only in CorePlayer) is pretty easy: just go to Tools / Preferences, select the Advanced page and scroll down to the “Disable AVC deblocking filter” checkbox. Tick it. Screenshots of this:
(Windows Mobile)
(Symbian)
Disabling deblocking at encoding time (again, if you do NOT use CorePlayer but (inferior) alternatives) is pretty easy too. If you use Nero Recode, after clicking Next on the main screen, click “Nero Digital Settings” in the left list (over the ? and the More >> buttons) and, after enabling the “Expert mode” checkbox under the tree view in the center (it contains a single item, “Encoder”, in non-expert mode, only allowing for switching between one- and two-pass modes) go to AVC Encoder / Encoding Tools. Then, just untick the Deblocking checkbox in the lower center.
1.4.3 Switch off CABAC at encoding time
CABAC is another, new and advanced technology used in the Main profile of AVC. Unfortunately, enabling it also consumes some additional CPU cycles at decoding time. Therefore, you might want to disable it – at encoding time only.
To do this in Nero Recode, go to the same AVC Encoder / Encoding Tools as was the case with disabling Deblocking, and untick “CABAC” (the uppermost checkbox) as can be seen in HERE.
Note that if you don’t see this checkbox, make sure you use the Standard – AVC profile inside the Nero Digital AVC category. In simpler profiles / categories like iPOD, PSP, Nero Digital AVC’s Portable etc., they are inaccessible (because they aren’t used at all by simple profiles).
1.4.4 Switch off Bidirectional Prediction at encoding time
As with Deblocking and CABAC, Bidirectional Prediction is another brand new feature of the non-basic profiles of H.264 (and, consequently, Nero). Unfortunately, it also consumes some additional CPU cycles at runtime and it can, as with CABAC (and unlike Deblocking), only be disabled at encoding time.
To do this in Nero Recode, go to the same AVC Encoder / Encoding Tools as was the case with disabling Deblocking and CABAC, and untick “Bidirectional prediction” (the uppermost checkbox) as can be seen in HERE.
(Note that you can disable both CABAC and Bidirectional Prediction at the same time. Do this if you do need the maximum performance. Don’t forget that, while disabling both results in a huge speed increase, disabling them both will still produce better results than disabling deblocking. Only disable the latter when you’ve already disabled the former two and there still are dropped frames. If it still isn’t working, then, consider using a lower resolution or entirely switching from AVC to the traditional ASP.)
1.4.5 Effects of en/disabling deblocking, CABAC and Bidirectional Prediction
The following chart shows the effect on performance of doing all these hacks. The results have all been measured using the current version (1.1.1 on Windows Mobile, b2 on Symbian) of CorePlayer. The test machine was a VGA Dell Axim x51v – video-wise, probably the fastest handheld around.
The first chart shows the performance gain of not only the combined disabling of CABAC and Bidirectional Prediction, but also the separated results. As can clearly be seen, the performance gain of not using CABAC roughly equals to disabling deblocking - while, again, it maintains MUCH better visual quality and should ALWAYS be preferred over disabling deblocking. The latter should always be the last resort to (try to) get rid of (heavily) dropped frames or bad performance. Disabling Bidirectional Prediction, on the other hand, results in a much higher performance gain: it’s like disabling deblocking AND CABAC at the same time.
The chart also shows the results of disabling the Intel 2700g hardware accelerator acceleration (a single checkbox in CorePlayer). As can clearly be seen, 2700g helps a LOT when playing back ASP videos – particularly high-resolution ones. With the latter, the performance gain can be even 60%. As the Intel 2700g doesn’t help at decoding AVC at all, the results would have been the same in both cases.
I’ve used several test videos with either 640 or 320 width. They all had two HE-AAC soundtracks (default of the Standard – AVC profile of Nero – as opposed to lower-quality profiles, where only AAC-LC is accessible) and two subtitle streams. The latter, of course, (still?) aren’t displayed by CorePlayer. All of the videos have been encoded using two passes and all optimizations. Note that removing one of the sound tracks and the two subtitle streams wouldn’t have resulted in a major speed gain (probably a 0.5% one – at most), which will also be shown in a later chart.
Note that most AVC benchmarks contain two values. The first shows the benchmark with enabled deblocking; the second (after a slash) with disabled one. (Again and again, disabling deblocking, unless your source is high-quality, is NOT recommended. Try creating your AVC videos with either bilinear prediction or CABAC (or both) disabled if you REALLY need some additional speed – the quality degradation will be far less visible than without deblocking.)
The chart also shows the effect of the bitstream speed on the decoding efficiency. It’s a well-known fact that the faster the bitstream, the more CPU it takes to decode it. As can clearly be seen, there is some difference. For example, a 204 kbps 640*272 AVC stream can be decoded with a 91% benchmark, while, when using a 464 kbps stream, this decreases to 82%, which, visually, is much worse (about two times more dropped frames). Fortunately, as AVC behaves extraordinary good at low bitrates (again, just like HE-AAC v2 in sound encoding), you will want to strive for using as low stream speeds as possible. Again, a 204 kbps 640*272 AVC stream is pretty much enjoyable – no need for using a faster stream. Let me emphasize again: a faster stream will only decrease performance.
1.4.5.1 Some other, bitrate-dependent tests
To prove my point and show how increasing the video stream speed decreases performance, I’ve made several other, bitrate-dependent tests with fixed streams. Note that, in here, the stream was a 640 * 384 (with QVGA, 320 * 192) one – that is, considerably thicker than the 640 * 272 stream used in the previous test. The results certainly show this has reduced the performance.
HP iPAQ hx4700:
HP iPAQ h2210:
HTC Universal:
Nokia N95:
1.4.5.2 Dell Axim x51v + TCPMP
The following chart shows how the x51v behaves with TCPMP (the free and, for playing back AVC files, not really recommended predecessor of CorePlayer). In here, I’ve benchmarked both the beta CoreAVC codec (the third and fourth columns) and the official (and much slower) ffmpeg codec (fifth column). As can clearly be seen, the ffmpeg codec is about 100% slower than the beta CoreAVC and the latter is about 26% slower than the one in the commercial CorePlayer. Note that this 26% also contains the additional slowdown introduced by TCPMP’s far less efficient HE-AAC audio decoder. With an AAC-LC test video, the difference wouldn’t have been this bad. (Again, as can be seen in HERE, the (old) HE-AAC decoder of TCPMP is 2.5 times slower than the AAC-LC one. As opposed to the CorePlayer case: There is almost no difference with CorePlayer’s AAC decoders.)
1.4.5.3 Other VGA Pocket PC’s
Let’s continue with some other test devices – in this section, Windows Mobile only. Let’s take a look at two other VGA devices, the 624 MHz HP iPAQ hx4700 (with an ATi chipset) and the 520 MHz HTC Universal phone (the latter without any hardware graphics accelerator). The tests, of course, have all been made with the latest CorePlayer (TCPMP was only used with x51v to show how slower it is compared to CorePlayer). As can clearly be seen, in AVC mode, the two devices performed equally well – and slightly (but not much!) worse than the “speedking” Dell Axim x51v. This also means if you have any of these devices (just like me), you may want to prefer them to x51v because of the far better-quality screen (much better color reproduction, no polarization problems etc.)
As can also be seen in these charts, the lack of any (previous-generation like the Intel 2700g in the Dell Axim x51v or the ATI chipset used in the hx4700) hardware accelerator in a VGA device isn’t a problem. The hardware acceleration of ATI and Intel 2700g (currently, the two chipsets supported by CorePlayer and TCPMP – no support for GoForce 5500 and Qualcomm 7200 yet) only helps ASP playback, not AVC one. It’s only the latest Marvell (ex-Intel) XScale 3xx (Monahan) series that has support for AVC decoding – not earlier designs. (Unfortunately, currently, only the brand new iPAQ’s (will) have the new Xscale CPU’s and nothing else.)
This also explains why, it’s only in the not recommended, old ASP mode that the (hardware accelerated) Dell and iPAQ are considerably faster than the non-accelerated Universal (or, the same devices themselves with disabled acceleration).
HTC Universal:
HP iPAQ hx4700:
Note that the “Video” setting dialog also contains a “Video quality” drop-down list. It should never be used because in the “Medium” setting, it severely degrades video quality (it effectively halves (!) the original (!) resolution – that is, VGA source becomes QVGA) and, in “Low” setting, almost noting will be visible. The speed gain its usage results in is pretty low too. Finally, it only has an effect on non-AVC (for example, ASP) source; this is why I’ve added the MQ (“Medium Quality”) remarks in there. (For example, (MQ: 319) with the HTC Universal playing back a 204 kbps VGA movie means 319% benchmark when the video quality is set to Medium.)
Halving the original resolution means that, if you play back a VGA ASP movie on a QVGA device that supports the quality setting, in general, you can give a try to switching to Medium quality – you won’t see much image degradation (as opposed to what you would see on a VGA device). This especially pays off if, otherwise, you couldn’t play back the video without dropped frames.
1.4.5.4 QVGA Pocket PC’s and MS Smartphones
Now, from VGA Pocket PC’s, let’s move to QVGA devices (Pocket PC’s and MS Smartphones alike): the pretty old, WM2003 HP iPAQ 2210 (run by a 400 MHz Intel Xscale PXA-255) and the new, low-speed HTC Vox (s710) MS Smartphone, run by a 200 MHz TI OMAP CPU. (Note that, as far as other TI OMAP-based models are concerned, I’ve also benchmarked the HTC Wizard. I’ll show the results in a later chart.)
HP iPAQ 2210:
HTC Vox / s710:
As can clearly be seen, the 400 MHz iPAQ 2210 is just able to play back QVGA movies without having to resort to manual quality degradation (bilinear prediction / CABAC / deblocking). With the 200 MHz TI OMAP Vox, the situation is far worse – you cannot watch QVGA-width AVC videos on Windows Mobile models based on this CPU without manually decreasing the quality in encoding time (in runtime, just disabling deblocking won’t suffice).
1.4.5.5 Nokia N95
Finally, let’s see how probably the best multimedia smartphone of today, the TI OMAP-based (running at 330 MHz) Nokia N95 (firmware version v20, which is a bit faster at video playback (too) than v12) fares:
As can clearly be seen, it’s just able to play back 640*272 ASP videos without dropped frames – unlike the Vox or anything Windows Mobile based on the TI OMAP platform (without heavy overclocking).
1.4.5.6 Note that…
I haven’t benchmarked any Qualcomm MS7200-based devices because the next, soon-to-be-released, 1.2 version of CorePlayer will have much better support for it. Also, GoForce 4000 / 5500-based devices like the O2 XDA Flame are promised hardware support sometimes next year – see THIS for more info. Therefore, I haven’t tested them either. According to serveral users, both Acer (GoForce 4000) and the Flame (5500) have severe problems with playing back video – as is the case with the Qualcomm MS7200-based devices right now.
The source video I used was a 640*272 / 320*144 one – that is, a traditional 2.39:1 (35 mm anamorphic / Panavision / 'Scope) movie. With, vertically, considerably bigger movies (1.85:1, 16:9 (1.78:1) or even plain 4:3 – see THIS for more info) will result in a somewhat worse results.
For example, with a real 4:3 (640*480, VGA) 550 kbps ASP source, the Nokia N95 benchmarks at about 93%, as opposed to the ~111% of the “thin” 2.39:1 movie resized to 640*272 (keeping the aspect ratio).
1.4.6 Other tweaking
I’ve also thoroughly tested the performance gain using other checkboxes in the already-known (it’s there that you need to disable deblocking) Advanced tab of CorePlayer. Note that the test video was a fast one (the Standard - AVC 640-wide one was 1995 kbps, the Standard 320-wide one was 1468 kbps etc.); with much lower (and, therefore, much more recommended) bitrates (between 80…450 kbps, depending on the resolution), the absolute numbers would have been considerably higher, while the relative rations would have stayed approximately the same.
As can clearly be seen, trying to increase the performance with the other, Advanced checkboxes are pretty much futile. As a rule of thumb, it’s only the three parameters (Deblocking both runtime and encoding time and CABAC / Bidirectional Prediction at encoding time) that you should pay attention to. Also note that, by default, CorePlayer defaults to the best and most effective playback method (video output). It’s only with some ATI-based devices that you MAY want to override its decisions, should you encounter for example the infamous greenish effect.
1.4.7 Resolution-dependent benchmarks
I’ve also made some resolution-dependent benchmarks to see how the players behave with non-QVGA / VGA source videos. In this test, I’ve let Nero Recode set the target resolution depending on the manually set bitrate.
Incidentally, this (Nero Recode itself decides the best resolution for a given bitrate) is the default how encoding works. This may be an overkill in a lot of cases. For example, even a 200 kbps 640*272 AVC stream looks great, while Nero Recode insists of only allowing for this size at the bitrate of 533 kbps. This is a big overkill if your premium concern is storage space. Again and again, even 200 kbps 640-wide streams can look great, particularly those of “traditional” “35 mm” (2:39:1) movies. No need for wasting almost three times more storage on the video stream.
Therefore, if you do want to ALWAYS force the Nero Recode to convert your videos / DVD’s to either 320- or 640-wide videos, you must manually click the Video button (the lowermost large button on the right), go to the Resize tab and fill in both the horizontal and vertical size. In THIS screenshot, I’ve filled in 640 for the horizontal and 272 the vertical size. Uncheck the “Letterboxing” checkbox (if ticked).
Note that, as there’s no “keep aspect ratio” functionality in here, you must manually compute the vertical size, based on the original one. That is, if the original is, say, 720*300, then, you’ll need to
1, divide 300 (the original size) by the result of 720/640 = 1.125 (or, if you plan to watch the video on a QVGA screen, 720/320 = 2.25). The result is 266 (or, with the QVGA case, 133).
2, now, you’ll need to find the least multiple of 16 closest to the result. To find it, divide 266 (133) by 16 and round up. The results are:
266 / 16 = 16.625; rounded up: 17
133 / 16 = 8.3125; rounded up: 9
3, multiply the rounded-up integer with 16 (272 and 144, respectively); this will be the new vertical size.
Now, the chart:
With exactly the same video files (and, in addition, with a one pass, one soundtrack, no subtitle file and a iPod 5.5G –specific one to see whether they result in a better performance), I’ve also made some other tests with the three VGA devices to see how they play them back. As can clearly be seen, there isn’t much difference.
First, the results clearly show including a second soundtrack and/or subtitles doesn’t really cause any real speed hit. That is, feel free to do it if you’re either a language buff (and like watching movies in different languages) or would like to listen to the commentary soundtrack, if any. (Note that, currently, few desktop-based media players can display the Nero subtitle streams: of course, Nero’s own Showtime and VideoLAN.)
As can also be clearly seen (just compare the 640-wide result to that of the 624 and the 688-wide: as can clearly be seen, there isn’t much difference), the overhead caused by having to resize the video to (horizontally) fill in the entire screen is pretty low (as opposed to what some people state).
Still, as you won’t take advantage of the extra 80 pixels of the original 720-wide video, there isn’t much point in NOT reconverting it. Again and again, with AVC videos and current hardware (that is, before the VGA iPAQ 2xx series with the Marvel Xscale CPU’s hits the street and CorePlayer receives support for it), you MUST convert your videos to be enjoyable on your handsets – as opposed to most ASP videos played on most Windows Mobile / hi-end Symbian handsets.
The other direction (not using a full 640-wide stream), on the other hand, can pay off. If you don’t want to disable any of the special AVC features (deblocking / CABAC / Bidirectional Prediction), then, resizing your videos to be 544 pixels wide will still yield an above-100 benchmark, meaning flawless playback (mostly) without dropped frames.
There is another usage area where you can make good use of the almost non-existing performance degradation caused by CorePlayer’s reisizing the non-320/640-pixels-wide content to the screen. For example, take the example of the QVGA Nokia N95, which has an analogue TV output. A 320 pixels wide video is pretty much pixelizated; a 400-pixel-wide isn’t so. The latter is still on the verge of playability without (many) dropped frames (and, if you’re lucky enough, even without having to disable deblocking). Therefore, in cases like this, it’s preferable to create a 400-pixels wide video, which can be played back pretty well on both the built-in QVGA (320 pixels wide) screen and an external TV set. (Also see THIS for more info on this subject.)
1.4.8 High-bitrate tests
Earlier in this article, I’ve already presented some bitrate-related tests to find out what effect the stream bitrate has on the playback speed. I’ve also decided to test some additional situations – extremely large stream bitrates to find out how the players react.
Note that, in these tests, I used the ffmpeg codec (instead of the much more recommended beta CoreAVC port) to benchmark TCPMP’s AVC playback.
Also note that the first two tests show how official trailers like those of Get Smart can be played back. This also shows that high-res, official AVC trailers created for desktop players (read: no CPU optimizations took place: with CABAC, deblocking and Bidirectional Prediction are all enabled), in general, can’t be played back, not even on the, otherwise, fastest x51v.
As the previous chart, Windows Mobile-wise, only contains data on the x51v (as far as CorePlayer, the recommended player is concerned), I’ve repeated the tests on all the other test Windows Mobile Pocket PC’s, including the 400 MHz Samsung & ATI-based HTC Trinity.
1.5 Using Nero Recode
There is an excellent and pretty much up-to-date tutorial on using Nero Recode HERE. This is why I haven’t elaborated on basic subjects like importing a video file or a DVD. Keep in mind, however, that the subjects not discussed in the Doom9 tutorial (forcing the 320/640-wide output with manual resizing; unticking the two (three) checkboxes to dramatically increase performance etc.) are only discussed in my tutorial.
1.6 Verdict
With the hacks / performance improvements I’ve thoroughly explained in section “1.4 Fixing the frame drop problem”, I’m absolutely sure you’ll love AVC, particularly if you don’t mind having to recode your movies and/or you absolutely need the least possible storage usage. AVC, sometimes together with the hacks, is indeed a killer video compression format, even on low-power mobile platforms.
UPDATE (12/24/2007):
TCPMP has turned out to support the same tweaks as CorePlayer. Most importantly, it supports disabling deblocking at runtime – as opposed to what has been stated in the Bible. (Sorry – I won’t re-edit the original Bible.)
Thanks to BrightHand forum member jigwashere, I have been pointed to the AAC and AVC plug-ins for the Palm OS version of TCPMP.
The AAC plug-in is the same as with the Windows Mobile version; that is, it even allows for decoding HE-AAC v2 sound. This is certainly very good news.
The AVC plug-in, unfortunately, only supports the standard Baseline profile (corresponding to the Mobile / Portable AVC profiles of Nero Recode), unlike on Pocket PC, where also the standard Main profile is supported. Nevertheless, it’s, on the T3, blazingly fast playing these “simple” AVC videos - I wouldn't have thought my old Tungsten T3 is SO fast with TCPMP in full screen mode. Remember, even the baseline profile of AVC is WAY better, image quality-wise, than ASP at the same bit speed. (Assuming low bit speeds, of course – not, say, over 1000 kbps.)
Still speaking of the T3, the 204 kbps 640-wide ASP test video benchmarked at 124% in fill full screen and 135% in non-filling (that is, keeping the original aspect ratio and showing everything) mode. These results are definitely better than the 640-wide ASP playback results on QVGA Pocket PC’s, even under the, otherwise, faster and more optimized CorePlayer. Frankly, I wouldn’t have ever thought the 4.5-year-old Tungsten T3 is so nice a device for ASP playback, even with TCPMP – again, even in full screen.
A new version of Nero Recode (3; in Nero 8.2) has been released in the meantime (some 6 days ago); see THIS for more info & changes.
UPDATE (12/29/2007): AAS Top Story (!) frontpage (screenshot)
UPDATE (01/03/2008): let me also present the standard benchmark results of the QVGA, 400 MHz Samsung + ATi-based HTC Trinity / P3600. This chart belongs to Section 1.4.5.4, “QVGA Pocket PC’s and MS Smartphones”.
Also note that I’ve made some CPU usage tests to find out how the power usage on Samsung-based Windows Mobile handsets and PDA’s increase with increasing CPU usage. The results are pretty good: pretty much close to the (excellent) Nokia N95 results shown in Section “1.1.1.1 Battery life considerations” and WAY better than the Intel Xscale PXA-27x figures. These results can be found in my Radio Stream Transcoding Bible, in the “UPDATE (01/03/2008)” section at the bottom.
UPDATE (05/03/2008): For my just-published HP iPAQ 210 in-depth review, I’ve thoroughly tested the H.264 (and ASP) performance of the latest, 1.2.3 CorePlayer version. With Intel Xscale PXA270-based handsets, there is absolutely no difference. On models based on the Marvell Xscale PXA310/320, on the other hand, there is between 30…50% performance increase, making the Xscale PXA310/320 platform definitely better to play back AVC (H.264) than PXA270. You can find more info in Section 1.4 HERE (cross-posted to: PPCT, AximSite, XDA-Devs, BH, HF, MoDaCo.)
UPDATE (01/25/2009):
1. CorePlayer 1.3 has been released for both Windows Mobile and Symbian in the meantime. I've made some very thorough tests on it to find out whether it's faster at playing back H.264 than the 1.2.x series or whether there is H.264-specific decoding acceleration support of the Xscale 3xx series (tested this with the 310-based HP iPAQ 210) or the TI OMAP 2xxx-series (tested this on the Nokia N95 equipped with an OMAP 2420), two chip(set)s announced as ones that might receive hardware support in the future. Unfortunately, there isn't. Nevertheless, if you have a previous version of CorePlayer, you will want to update to the new version – it has much better YouTube support. For example, it supports iterating over all the search / category results and also supports the latest YouTube video formats. Unfortunately, HE-AACv2 and, on Symbian S60, WMV support is still painfully missing – I really-really hope they'll be added before long.
2. I've also played a bit with the latest (1.8.5.0) version of the desktop version of CoreAVC, the desktop decoder for H.264 and directly compared it to the recently-released DivX Player 7.0, which, among other things, has a brand new H.264 decoder. I've also thrown the latest (0.9.8a) version of VideoLan VLC player to see how the two compare to the well-established (but not very efficient, H.264 playback-wise), free, all-in-one video player.
All my tests have been conducted on a 2 GHz IBM ThinkPad t42p with a Pentium-M Dothan running at 2 GHz, 2GB of RAM and an UXGA screen, under the recently-released build 7000 of Windows 7 beta. I've run the tests in full screen mode. (Note that, unlike with, say, the IBM ThinkPad a31p and HP TC1100, video acceleration is fully supported on the t42p. Without it, watching high-resolution videos would be a painful experience.)
I've mostly used (torrented) 720p material like Ratatouille (video encoded at 1280x528 @ 4380 Kbps, bilingual audio left at the default 640kbps AC3) and Harry Potter and the Chamber of Secrets, encoded using very similar parameters. Of the former, I especially took care of checking switching between the two soundtracks (English / German); of the latter, I paid special attention to the jerkiness of the animation at the end of the movie, starting at 2:31:05. In addition, I've thrown in some 1024*768*15 fps Canon IXUS SD960 video clips encoded by the latest (version 2009 build .35), highly recommended SUPER (Simplified Universal Player Encoder & Renderer) using 1200 kbps, 15 fps video and LLC-AAC 64 kbps 44 kHz mono audio.
The results are as follows: VLC, as one could easily guess, was by far the slowest to render. It just couldn't produce enjoyable results – the 720p videos stuttered so bad. (The much simpler 1024*768*15fps videos were, of course, played back without problems.)
The free(!) DivX Player was much-much better. It delivered far less stuttering. A quick note: it, by default, doesn't support AC3. Therefore, you'll want to install AC3filter [latest, tested version: 1.51]. Note that, as is explained in section 4.10 HERE, you'll also want to do this if you use other players and find the audio volume low while playing back movies with an AC3 soundtrack; this also applies to CoreAVC and any compliant player like the built-in Windows Media Player or, in newer Windows versions, Windows Media Center. (Note that these do play back AC3 soundtracks – at least under Windows 7 – without installing any codecpack; just pretty quietly) Just install the driver and, under XP, follow the just-linked tutorial; under Vista / Windows 7, go to All Programs / AC3Filter / AC3Filter Config and raise the gain level.
CoreAVC was still (a bit) better than DivX Player. While the difference between CoreAVC and DivX Player was certainly much-much lower than between VLC and DivX Player, I do think it's still worth paying for the standard version of CoreAVC (unfortunately, the Professional version still doesn't support hardware acceleration and it'll unlikely receive any, based on the comments HERE) if you want to minimize CPU utilization.
Note that I've tried very hard to remove (or reduce) stuttering in all players. In CoreAVC, setting "Deblocking" to "Skip always" from the default "Standard" didn't seem to have any effect at all – the video, with very fast panning / action, occassionally stuttered, while the CPU usage, interestingly, remained around 30-40%. In Divx Player, under Tools / Preferences / Video, the "Post-processing mode" drop-down list turned out to be uneditable – it is set to "Custom deblocking". Finally, I didn't really bother with VLC as it was bad enough and in no way recommended for H.264 playback. If you absolutely must use a free H.264 player (and can't shell out $8 for the Standard edition of CoreAVC), go for the (in this regard, much superior) DivX Player 7 instead.
3. I've found the above-mentioned SUPER (Simplified Universal Player Encoder & Renderer) a very-very easy-to-use tool to convert your stuff into H.264. While in my previous H.264 bible I recommended Nero Recode for the task (because of its simplicity), now, I tell you to go for SUPER instead. It has a very simple and logical user interface you'll learn in a minute: no need to use x264 (the famous encoder) from the command line any more, with a lot of cryptic options and commands. You can do the same right from SUPER, without having to read a lot of manuals on the different switches of x264. Also, it's capable of batch processing: you just drop some source files in it and, after setting the output audio/video/container parameters, just start transcoding. It's really easy and the encoder itself is, according to most people, both better and faster than that of Nero – and, yes, it's completely free!
Note that SUPER, being "just" a front-end to some command-line codecs like x264, doesn't support cutting / editing video files before being re-encoded (transcoded). For this task, I recommend SolveigMM Video Splitter the most because it's capable of cutting videos without re-encoding them. This way, it's both very fast and doesn't introduce any kind of quality decrease. Unfortunately, it isn't free (it costs 35 euros); however, it's well worth the price if you need to cut / edit video files often. Note that the 21-day evaluation version is completely usable and has no restrictions. It's perfectly usable unless you have MKV files as source – "traditional" AVI, MP3, WMV, WMA etc. files are all supported. Note that DVD's are also supposed to be supported; however, I've repeatedly received "Can't start trim process (The parameter is incorrect HRESULT: 0x80070057)" messages as of version 2.1.901.22, upon trying to edit / trim VOB files from DVD – without, of course, protection. WMV, AVI etc. files worked without problems.
4. Still speaking of desktop Windows, I’ve also tested the video / audio streaming offers to be able to save streaming or non-streaming content. You might also want to read the following section if you ever wondered how you can save for example streaming WMV videos, MP3 broadcasts and the like.
First, if you’re watching a non-live source (that is, pre-produced videos like those of YouTube), in a Web browser, there is chance it’s sent to you in Flash format. (Most video sites like YouTube use flash.) The easiest way to save these videos is using Opera as your main browser and navigating to \Users\username\AppData\Local\Opera\Opera 10 Preview\profile\cache4\ in Vista/W7 (in XP, change the leading “Users” to “Documents and Settings”) and, before navigating to the page containing the video, just entirely delete the contents of this directory. Then, you’ll easily spot the FLV videos downloaded to the cache upon navigating to the page with an inline videos and, then, starting to play it. Remember to rename the videos to something.FLV. These FLV files can be directly played back by, for example, the free and (unless you want to play back H.264) excellent VideoLan VLC player.
Most of the Flash-based video sources (YouTube, Google Video etc.) allow for quickly finding their FLV videos this way. Note that the above-explained way of finding them also works with Internet Explorer; however, then, you’ll need to make some searches with, say, Total Commander’s built-in file search routine (Alt-F7) unless you’re ready to traverse all the (numerous) subdirectories IE creates. This is why I recommend Opera for this task (too – after all, Opera is an excellent browser worth switching to not only because of this.) I’ve found only one exception – a regional TV broadcaster “ATV” (an example video is HERE), which uses some special, non-caching format I could only save with WMRecorder 12.3+ (but not with previous versions, not even 12.1).
Streaming video formats are another question. WMV, which is, today, the most commonly used (see for example the direct TV stream library HERE) format, saving the stream is way more complicated. With some (few) WMV streams (offering only pre-recorded stuff), you can just create a HTML file pointing to the WMV server / file you can easily get if you examine the page source for the original address and just trying to save the contents with a right click. With real live streams, however, this won’t work – then, you’ll need to use a third-party app. In my tests, WMRecorder has turned out to be the best in this respect when operated in ADA mode. Make sure you give the trial version a try to see whether your particular hardware configuration is supported so that it can run in ADA mode. It works wonderfully on both my HP TC1100 and IBM ThinkPad t42p (2373W6M) under both Windows 7 and Windows XP – and also on my IBM ThinkPad a31p (2653AG9) under XP (haven’t checked it under Windows 7 on my a31p). Note that, under Windows 7 on my t42p, I’m always receiving (with version 12.1; haven’t checked the latest, 12.4 version in this respect) “URL Finder has stopped working” errors; nevertheless, it does catch streaming download initializations issued before the URL finder being killed. And, if you do encounter URL Finder problems, just close and restart WMRecorder.
Related
Anyone that has read the Windows Mobile Audio Recording Bible knows Audio Recorder by Resco, one of the best audio recorder solutions for Windows Mobile.
Resco has just released a public beta of the brand new version of the application. It’s available here and certainly worth checking out if you like Resco Audio Recorder and want something better.
{
"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"
}
You can read the official “what’s news” list at the above-linked page. Here, I “only” elaborate on MY real-world, unbiased benchmarks and pros/cons list. I give special attention to providing a side-by-side comparison to PMRecorder, the best, free automated call recorder solution for Windows Mobile.
This also means you’ll want to read the PMRecorder article, the Windows Mobile Audio Recording Bible and, with the MP3 playback CPU usage benchmarks, the Windows Mobile Multimedia Players’ CPU usage Bible to fully understand this review; I don’t explain everything from the basics here. Also note that the pros/cons list only discusses the changes between the previous and the current version.
CPU usage benchmarks
MP3 playback and equalizer (again, please see THIS for more info):
At my test Dell Axim x51v A12 running at 208 MHz, in background: ~11% CPU cycles
In foreground: ~23%, with (from the app) switched off screen too!
Equalizer: ~42.5% (also in background; meaning four times higher CPU usage! Really bad!)
Recording:
“HQ” MP3: ~100%, default LQ 11 kHz (but 56 kbps!) MP3: ~50% on the 273 MHz HTC Wizard
Speex (32 kHz q3 18 kbps): 71% on the 273 and 85% on the 236 MHz HTC Wizard; at 195 MHz, useless. Add the in-call overhead to this and you'll understand why there's some small stuttering when auto-recording calls with slower PPC’s (even at 273 MHz with the HTC Wizard, which is originally equipped with a 195 MHz TI OMAP CPU) with quality speech codecs like this. (Haven't tested this at even higher CPU frequencies.)
Universal, 520 MHz: 39%
PPC2k2, 206 MHz StrongARM iPAQ 3660 running at 236 MHz: default 8k/q1/14kbps OGG ok (but NOT at 206 MHz); 18 kbps Speex not even then (let alone the standard 206 MHz!)
The changes
There are a lot of them; I've listed most of them in the pros/cons lists. In addition to them, for example the file conversion / export (Tools / Save As) could be mentioned, which has been restructured; now, instead of being presented the traditional format setting screen (two or, depending on the output format (whether it allows for quality settings), three drop-down lists) and, after clicking Export, the traditional file save dialog where you can supply the filename and path. Now, this has completely been changed (1 2 3).
Note that this is just one of the subtle changes - there are a LOT of them. See the lists below.
The good
Phone call recording capabilities with time/date and caller name/number in the filename; at a much better quality/size ratio (when you use Speex) than the two predefined modes (low-quality GSM and storage-hungry PCM) of PMRecorder (note my CPU use-, foreground operation- and location-specific suffix-related remarks in the Cons section though!)
The date / time settings in the filename can be much more thoroughly set than in previous version, where only date and time could be set and you couldn’t separately specify year / month / day / hour / minute (still no seconds); also supports creating folders based on the date. For example, the screenshot above shows recording with the “%Y-%M-%D-%h-%m-“ filename setting (note that 001 (002 etc.) is auto-added to files started to be recorded in the same minute as a previous one. This is for avoiding overwriting files.).
Support for ancient Pocket PC 2002 OS; what is more, unlike with the previous version, it also supports Speex and OGG on it! (Not that a 206 MHz StrongARM iPAQ would be able to record into these formats without problems; with Speex, not even at 236 MHz.)
Clock counter doesn’t seem to stop at 9:99:99 (that is, at 10 hours) – this may be handy with extremely long recordings. (Previous versions were also able to record even longer recordings, but their counter stopped at 10 hours)
Dynamic CPU load checking upon recording to see whether the recording will have in any kind of stuttering. This is much more dynamically adaptable to the current CPU load (because of other processes) than the old, static approach, where you could to make static tests upon selecting the target format.
Now, unlike ALL the alternatives (except for the built-in Notes), it allows for one-button recording. And it's astonishingly quick at it! The time needed to start recording after shortly (it's sufficient) pressing the assigned hardware button (it only needs to be done from inside Resco, not in the system-level Settings/Button applet!) can be as low as 2 seconds with the simplest WAV and RAF outputs. With more dedicate outputs, it's slightly higher; with, for speech, the most recommended Speex it's 2.5 seconds and with the otherwise, in the current "quality" level (see the cons section!) not at all recommended MP3 output, 3.8s. All measured on a Dell Axim x51v (A12 ROM), where it only takes the built-in Notes 0.9s to indeed start recording. Let me point out that some of the alternatives need even three times more time to start recording (see for example Audacity Personal DVR (Digital Voice Recorder), which needs seven seconds for this on exactly the same machine!).
Note that you MUST assign a recording-related hardware button for one-button recording to work. Otherwise, the “Recording / Use record button to launch Audio Recorder and start recording” in Options can't be checked. To do this, go to the Buttons tab and assign any button. Then, you will already be able to enable one-button recording by checking in the above-mentioned checkbox.
I also recommend checking in the two upper checkboxes in the Recording tab so that you can hear when the recording starts and, when you use a button to stop it, stops. Especially the former will really help in knowing when you can start speaking. This is because Resco needs some time to load and start recording. With the additional, discrete beep at the beginning of the recording is certainly welcome - it helps a lot in your knowing when you can start speaking.
Unlike with PMRecorder, post-processing isn’t needed to convert recordings to a standard format – they’re already standardized, with only the filename having date- and caller/called-related info
As with previous versions, low CPU usage when playing back MP3’s (but NOT when using the equalizer!)
Equalizer with presets
More streamlined (simpler and more logical) Options dialogs
The file context menus are a direct replica of those of Resco File Explorer; in addition to standard stuff like Copy / Move to, they even contain Send To. This means it’s much easier to do file copying / sending stuff from inside the new version than from previous ones.
There is another brand new addition, a sleep timer (Tools / Sleep), should you plan to use the app as a player (which is highly preferred as its CPU usage, while playing back MP3, is very low).
As opposed to PMRecorder, Resco doesn’t need to be explicitly started because it registers itself in the system. This has several consequences:
it has about an order less memory consumption (not that PMRecorder’s 500k would be THAT high) – about 50k
even better, the operating system doesn’t shut down the task when it deems to be necessary. This is a BIG advantage over PMRecorder!
you don’t need to make sure Resco is started by, say, putting a link to \Windows\Startup; also, you don’t need minimize the task upon booting. And, of course, it won’t be visible in the active task list either.
The bad
Still uselessly low-quality MP3 codec (can’t be compared to that of NoteM or ViTO’s SoundExplorer); furthermore, it’s taking 100% CPU time even at 624 MHz (as opposed to previous versions) at better(?) quality settings (44 kHz/48 and 96 kbps). It’s acceptable with the standard low-quality setting, though, but, even then, using NoteM or SoundExplorer is far more preferable.
While playing back, animation (which doubles CPU usage) can’t be disabled and it’s active even when you use the built-in screen off; it’s only when you send the app in the background that it stops working (and consuming CPU cycles)
File association doesn’t work
Speex playback is still buggy: overlaps the first ~28 minutes to the rest and, therefore, needs another player (Foobar2000, for example) to correctly play back longer clips
The current build doesn't play RAF files (not that they'd be THAT important)
The current build can't convert OGG files to anything else
Usingg the equalizer results in four-fold CPU usage and is, therefore, not recommended (try using hardware-level equalizers - see my earlier articles); the developer promises it'll look into the problem
Still no AVRCP support; developer promises it for both later versions of the app and Resco Radio
When there’re home/mobile etc. suffixes in a number (for example, /H for home, /M for mobile etc) as can be seen in here (see the /H at the end of the (for the most part hidden) number), Resco won’t be able to create a file. Of course, this isn’t a problem when there are no such suffixes in the incoming/outgoing number OR you have a contact name for the number (and the contact name doesn’t contain characters like these, I suppose). BTW, as can also be seen in the example screenshot (see the two call recordings in the recording list), private incoming calls aren’t named, as one would expect (and as is the case with PMRecorder). The developer promises a fix.
Resco is brought to the foreground upon recording calls. While you can switch back to Phone to be able to, say, use the keypad, this may be a nuisance. (Note that the red phone button (hang up a call) certainly works when Resco is actively in the foreground.) The developer promises a fix.
Doesn’t support the PDAudio card any more, it seems (not that the PDAudio would be THAT common, particularly now that it's, to my knowledge, discontinued).
Verdict
The best (if you don't take the bad MP3 coder into account) have been made even better. Highly recommended, particularly if you don't need the equalizer / MP3 recording / RAF playback and want a really decent phone conversation recorder. It blows PMRecorder, the, so far, best phone call autorecorder application out of water easily, particularly because you can be absolutely sure all the time it will record your calls without having to manually make sure it will.
Article updated.
As you may already have noticed, I've been promoting the Qualcomm MSM7200 chipset-based handsets not only because of their, compared to the alternative chipsets / processors, more advanced features; for example, the pretty good, albeit a bit worse than now industry-standard SiRFstarIII GPS, HSPA support built-in; speed advantage over most other CPU's; being ARM11-based etc. But also because of their three-dimensional (3D) graphics and multimedia decoding acceleration support.
3D acceleration is a MUST for both running (yes, you've guessed) 3D games, some emulators (for example, Tala's SNES, PocketGBA or some arcade emulators - see my emulation-related articles). Multimedia decoding, in general, also means MPEG video decoding support, which, through the much lower CPU usage, may result in drastic battery life increase. A perfect example of this is decoding non-H.264 (unfortunately, decoding H.264 isn't supported by the 2700G) video on the Intel 2700G-based Dell Axim x50v and x51v. Enabling the explicit 2700G support inside TCPMP (or CorePlayer) results in the possibility of drastically underclocking the PDA. Typically, a full-res (PAL / NTSC) AVI file can be played back underclocked to 208 MHz, as opposed to 624 MHz, which the handheld would constantly run at when only using software-only decoding. This means a GREATLY enhanced battery life.
The developers of CorePlayer (the premiere video player for all(!!) mobile platforms (yes, even the iPhone will be supported!!) have announced they would look into the problem. BTW, they also promise support for the GoForce 5500 already available in the O2 XDA Flame, the Toshiba G900 and some forthcoming i-Mate PDA’s. Also, they promise support for the 3D accelerator in the Nokia E90 / N93(i) / N95, the S-E P990 / M600 / W950 / P1 / W960 and the Moto Z8.
Unfortunately, currently, it seems at least the HTC Kaiser (a.k.a. AT&T Tilt) doesn’t support any kind of hardware acceleration. Currently, all it does is software-only acceleration not taking advantage of the built-in hardware support at all.
This is certainly bad news. We can only hope either Qualcomm or HTC enables the access of the 3D accelerator to applications.
In the above-linked thread, I’ve asked the XDA-Devs folks to post (as I’ve also did with the O2 XDA Flame ones) to test whether ANY of the games / emulators listed as 3D accelerator-capable (see their list in the already-linked Flame article) run and make use of the 3D acceleration. (No need to test the multimedia decoding: I already know it doesn’t work).
If you do have a Qualcomm-based handset (in addition to the Kaiser, for example, the HTC s730) and would like to contribute to enabling 3D / multimedia support, make sure you join us HERE to share your experience.
Finally, if you work for Qualcomm and/or HTC, please PLEASE do something to cure these problems. A major selling point of the Kaiser (or, for that matter, ANY Qualcomm-based Windows Mobile handset) is the (promised) 3D and multimedia decoding support. We DO need it. We DO want to run 3D games, we DO want to have multimedia (video) players NOT chewing through our batteries, we DO want to run emulators at a decent speed. Do look at Nokia and Sony-Ericsson. They’ve been using 3D accelerators in their models for quite some time and they DO support it via both native and Java apps.
I want to know what is the best format to convert videos for ppc so i can get best combination of quality and performance, size dosnt matter for me.
I am alao looking for the best practice guide.... so i can learn how to get smooth video playback.
H.264. Read my H.264 Bible, it exaplains everything.
Thanks I am looking for your bible.
I think I may have overlooked something obvious, but where is your bible?
I'm having terrible trouble getting decent video playback on my i-mate 9502
Here guys
http://www.allaboutsymbian.com/forum/showthread.php?t=67863
It seems you can't expect much from the 9502 - it doesn't have working drivers either - see http://forum.xda-developers.com/showthread.php?t=351788&page=8
You could give CorePlayer a try, though
I still have a problem that I have a wmv which play smoothly on my pc but now I convert it to h.264 but it still lagy (as before) on my wizard.
Do you use CorePlayer?
Did you try optimizing (bo Cabac etc?)
I am using core player latest build but I dont know about "optimizing (bo Cabac etc?)"
Can you explain me?
btw I convert the video from xilisoft in 320 res
azfar said:
I am using core player latest build but I dont know about "optimizing (bo Cabac etc?)"
Can you explain me?
Click to expand...
Click to collapse
I've explained this all in the H.264 Bible... there're a lot of areas of optimization.
BTW, the Wizard is VERY slow. Therefore, I recommend not only goig for CorePlayer, but also sticking to DivX if the increased storage requirements aren't a problem.
you mean divx codec, not player right?
azfar said:
you mean divx codec, not player right?
Click to expand...
Click to collapse
Both. You need to encode your stuff with DivX and play back preferably with TCPMP or, even better, CorePlayer.
I switched my 9502's coreplayer setings to RawFramebuffer and now it plays QVGA video at an acceptable 24fps / 500kbps no problem. Still seems to hate VGA video though, but I guess that's a non-issue until they bring out the SDHC patch.
mike freegan said:
I switched my 9502's coreplayer setings to RawFramebuffer and now it plays QVGA video at an acceptable 24fps / 500kbps no problem. Still seems to hate VGA video though, but I guess that's a non-issue until they bring out the SDHC patch.
Click to expand...
Click to collapse
any other core player video settings for better performance?
The H.264 codec is not a good choice for playback on slower devices. If you flip though the h.264 bible (linked below) you'll see that even a 330 MHz OMAP (N95) isn't able to handle a h.264 video 100% without disabling features. You haven't got a chance with a 200 MHz OMAP and your going to have high CPU utilization with a 400 MHz CPU.
http://www.aximsite.com/boards/applications/222389-h-264-k-mpeg-4-part-10-avc-bible.html
If size is not a factor, then you're not gaining anything by using h.264. The main benefit of h.264 over XviD is better quality at the same size or same quality at a lower size. XviD/DivX has much lower compression complexity and requires less CPU power/utilization to decode but ends up taking more space.
If you have a fast processor and you want the best quality at the smallest size, go with h.264/AVC. If size is not a factor, stick with XviD/DivX(ASP). Even with a fast processor, you will have lower CPU utilization and longer battery life (assuming you are using CPU scaling).
Check out my guide if you want some help converting to XviD.
http://forum.videohelp.com/topic349738.html
trueg said:
The H.264 codec is not a good choice for playback on slower devices. If you flip though the h.264 bible (linked below) you'll see that even a 300 MHz OMAP (N95) isn't able to handle a h.264 video 100% without disabling features. You haven't got a chance with a 200 MHz OMAP and your going to have high CPU utilization with a 400 MHz CPU.
http://www.aximsite.com/boards/applications/222389-h-264-k-mpeg-4-part-10-avc-bible.html
If size is not a factor, then you're not gaining anything by using h.264. The main benefit of h.264 over XviD is better quality at the same size or same quality at a lower size. XviD/DivX has much lower compression complexity and requires less CPU power/utilization to decode but ends up taking more space.
If you have a fast processor and you want the best quality at the smallest size, go with h.264/AVC. If size is not a factor, stick with XviD/DivX(ASP). Even with a fast processor, you will have lower CPU utilization and longer battery life (assuming you are using CPU scaling).
Check out my guide if you want some help converting to XviD.
http://forum.videohelp.com/topic349738.html
Click to expand...
Click to collapse
unfortunately the software you refer doesnt support wmv conversion.
Well, honestly I've never needed to convert a wmv(ASF) video before. I never would have thought it would not accept WMV files, but I downloaded a music video to test and indeed, even when forced, PocketDivxEncoder wouldn't accept it. I then tried AutoGK which is another high quality converter/front end and it also would not accept WMV files (I would assume the same for Gordon Knot).
To aid you in your quest, I went on a search for tools to help you in your task.
Tools tested....
AllToAVI - http://www.videohelp.com/tools/alltoavi - easy to install, fairly intuitive, fast encoding, no option for cropping or rotation, limited audio options.
--I ran a quick test on my wmv music video using AllToAVI. The original WMV did not play very well (worse than a slide show) on my HTC Touch (Elfin - 201Mhz OMAP). The resulting XVID was actually the same size, but played perfectly.
WinFF - http://www.videohelp.com/tools/WinFF - easy to install, minimalist interface (very limited), fast encoding. Unlike AllToAVI, WinFF did not analyze the source or make suggestions on video frame rate or aspect ratio. It worked well enough and the resulting XVID looked as good and played as well as the file created by AllToAVI.
MediaCoder - http://www.videohelp.com/tools/MediaCoder - wow, this program is pretty amazing. Easy to install, tons of options, fast encoding. This program is much more customizable than PocketDivXEncoder, but this is to be expected. This program can convert from pretty much any codec to pretty much any codec. There are options for pretty much every aspect of the conversion process (which may be too much for some people). The resultant video was again the same size, but quality was a bit higher since I was able to crop the black bars.
Basically, if you can use PocketDivXEncoder (i.e. your video is supported) stick with it since it is fast, high quality and easy to use. If you want the ability to customize every single aspect of the conversion, use Media Coder. If you can't use PocketDivXEncoder and you want something very simply to convert your unsupported video, give AllToAVI a shot.
many thanks for your efforts. I am tryijgnall those convertors and will let you know the results.
can I play the 700MB dvdrip (.avi divx) version of movie on pda. Can it handle it?
NOTE: USE OF THIS THREAD AND INFO ASSUMES YOU HAVE LEGAL AUTHORITY TO USE / ENCODE ALL SOURCE MATERIALS. I AM A US CITIZEN AND A SOLDIER, AND HENCE FALL UNDER JURISDICTION OF MANY ORGANIZATIONS, TO INCLUDE THE FEDERAL CENSORSHIP CLUB (FCC) AND THE DOUCHEBAGS MOLESTING CONSUMERS ACT. NO QUESTIONS WILL BE FIELDED REGARDING RIPPING, DOWNLOADING, OR PIRATING OF SOURCE MEDIA, REGARDLESS OF THE INQUIRER'S NATIONALITY. - Fathead, P.I.
This thread will be about video encoding, with the end product being the Raphael. My current Device, Radio and ROM are in my sig and updated for reference.
The premise of this guide: Using freely available (NON-WAREZ) CODEC and software, the user will be able to create video with audio playable on a HTC Touch Pro. The video will be of a watchable quality and small in file size.
Some of you may be familiar with my work on SEGA Dreamcast with GypPlay, DC-Divx, DC-VCD standard, and XDP (X-Rips, Inc. Dreampassport, English translation of DP 2 and above)
- Fathead, P.I.
----- START OF THEOREY -----
If you're like me, the first thing you asked yourself after buying your Fuse was "HOLY ****! I can run 4x the storage on this thing that my old Wizard could!" Yes, 16 GB of Micro-SD goodness is freakin' sweet. But how to use it? You can only listen to so much music per week, even with Napster To Go. You can only play so many games. (I'm further reduced due to lack of a usable joy pad for Pocket Nester.) Why not throw some movies on this joker?
----- VIDEO FORMAT -----
The first thing most people want to know is "What resolution and format should I use?" I am a longtime fan of Divx. I have used it to successfully create video content for low end devices, specifically the SEGA Dreamcast. Creating or downsampling content for a mobile phone gives us a considerable edge over bigger-screen counterparts. Before we jump into the configuration of settings and knob-dicking with software, let's figure out just what kind of video we want to produce.
FRAME RATE
Most content you find will come in one of 3 frame rates:
30 FPS (VHS / NTSC Broadcast / DVD / Blu-Ray(?) )
25 FPS (PAL)
23.976 FPS (Actual frame rate used to record cinema and produce much media)
The first thing you need to realize is that many things initially encoded in 30 FPS can be converted back to 23.976 FPS with no loss of fluidity or data. If your source is a webcam, skip the scaling to 23.976 and drop down to frame decimation. If your source is film, you're in luck. The other frames are just dummy frames that waste a little data. Deleting those frames frees up more video data to better express the picture information in the other 23.976 frames. This trick allows you to:
A. Use a lower bitrate (and hence smaller file) for the same picture OR
B. Get a better picture at the current bitrate
To figure out the frame rate, load up your file in V-Dub and go to File - File Information. The Data Rate box in the Video Stream area will tell you current bit rate, while frame size will give you resolution and frame rate. If you have a 23.976 FPS source, continue. If you have a 30 FPS source that you think should be 23.976 FPS (Film, etc) :
1. Load up the file in V-Dub.
2. Go to the Video drop down menu. Select Frame Rate (CTL+R is shortcut)
3. Change the Frame Rate on the source to 23.976 FPS.
If you continue to have audio sync issues with this method, leave the file at 30 FPS and continue.
Now we are going to look at frame decimation. Frame decimation drops every X frame while keeping the audio sync'd. The end result is a file X the frame rate of the source. While this is noticeable on large screens, on the Touch Pro / Diamond Screens (and probably even the HD), it shouldn't be an issue at all. You can play with this option. It is more noticeable on film, but I cannot see a difference at all on animated sources.
I use the decimate by 2 option in VDub. Video -> Frame Rate (CTL+R shortcut) and select Decimate video frame rate by 2. Our output video is now half the frame rate of our source. The end result is we can:
A. Get a better picture with the current video bit rate OR
B. Lower the video bit rate to get the same picture in a smaller size.
I use option B. Another big advantage here is that the device is trying to decode half the frames. A general rule about audio and video playback: The lower the bit rate you ask the device to handle, the less work it has to do to decode and display the video, and less battery power will be used.
RESOLUTION
Most content you will find is around 640 x 480. DVD sources usually come around 720x480. Blu-Ray would be above that, but possibly scaled down. We are going to watch this movie on a 3 inch screen. Guess what that means? If we never found a video about 320x240, or comparable widescreen resolution, It wouldn't matter. At all. Stepping up to 640x480 is just going to quadruple the amount of pixels we are trying to express on a limited budget.
A handy tool I use in V-Dub is the 2:1 reduction filter (high quality). To kick kit on, go to Video -> Filters (CTL+F). Click add, and it should be the first filter you can choose. This cuts your resolution by half. As a rule of thumb, If I've got a source that's around 640x480 (or 16:9 equiv) or higher, I hit it with the 2:1. You'll find oddball sources like 480 x 360, you can give it a shot, but it might not be worth it. Again, lower resolution means less pixels to express both in bit rate and in reproduction (playback).
Pausing here again, tired as hell.
THE SOFTWARE I USE
Video Editing / Audio and Video Compression and Mux - Virtual Dub. Totally free. I usually refer to this as VDub.
Home
Download
Audio Compression CODEC - LAME MP3 - Free and versatile.
Home
Compiled Binaries
Use the ACM Binary here for Windows and Virtual Dub
Video Compression CODEC / PC and SP/PPC Player - Divx - Decoder, player, mobile player, and MOST of the Encoder are FREE. DO NOT POST ABOUT CRACKING THIS.
Home / CODEC and PC Player
MOBILE (PPC and SP) Player
One more for good measure...
Okay, replies and requests, go!
Am I correct in thinking that videos should be encoded in 640 x 480 ?
*RESERVED*
cucusoft
i use Cucusoft Ultimate DVD + Video Converter Suite
mpeg-4
video bitrate 600kbit/s
framerate, depends from 23.976 to 25 (not important)
videosize 480x368
format 4:3
audio aac
128kb/s
samplerate 48000k
2 chanels stereo
it works fine, no framedrops
played with coreplayer 1.25 build 4506
I just use the standard 700mb divx movie in .avi
I use the free divx player V0.91
Smaller would be sweeter.
Taking a break for a bit, added some new material. Internets in the hotel are barely functional.
I'll be focusing on getting files down to smaller levels. The theorey should give you enough information to start dramatically cutting your file sizes. I've been moving my Boondocks DVD over to Divx 6.8 movies. Averaging 40 megs per episode.
I have been using spb mobile dvd for a few years now. It is very easy to use can convert straight from a dvd or a video file and supports vga res.
Will have to check that one out, have been thinking about backing up my DVD's to mobile, will be traveling about 26 - 30 weeks out of the year and need some boredom killers.
Gonna score some sleep and SEGA time, later all.
Added some new info, taking a pre breakfast nap.
i use slysoft clonedvdmobile. output at vga res and filesize around 700mb seems to run fine for me...although its not free, its well worth the money
Brendo said:
i use slysoft clonedvdmobile. output at vga res and filesize around 700mb seems to run fine for me...although its not free, its well worth the money
Click to expand...
Click to collapse
This is a great bit of software. It also utilises all 4 cores on my Q6600. Another fantastic program is DvDFab which can transcode DVD to Divx/Xvid/MP4 etc on the fly, or dump the Video TS to your HD.
Going to have to check all this out. Have many a DVD that needs ripped. Wonder if any of those have a frame decimation feature. I like my 30 - 40 meg per episode cartoons.
Based on some comments in other threads, I've tried a couple of freeware programs to try to encode in the format that works so well with WMP (MP4, H.264, 640x368, 1000 Kbps, AAC @ 96Kbps): DVD Decrypter + SUPER for one and AutoMKV for the other. However, I haven't been fully successful with either, so I'm hoping that someone who uses these tools can clue me in on the appropriate settings and procedures for encoding.
The combination of DVD Decrypter and SUPER creates very nice movies for playback on the Fuze. Unfortunately, DVD Decrypter keeps the VOB structure from the DVD and SUPER follows suit, which means that a movie will be broken into several pieces at arbitrary points: unsatisfactory, to say the least. The SUPER support forum mentions a way to join inputs into a single output, but following what I understood those instructions to say did not, in fact, result in a combined file.
AutoMKV is very convenient, as it is a single program (or at least UI) to both rip and encode. Unfortunately, I haven't found the settings that generate output that is comparable to the SUPER output -- WMP won't play any of the files I've managed to create so far.
Anybody use these successfully and can share how they do it? TIA.
amerisoft, works very well for me so far, except an occasional blank screen
Just wanted to add...
I don't bother encoding video anymore. Sure, a full-blown 50 minute xvid show might be 400meg. However, the touch pro does not have any issue playing such files back.
Makes life much easier!
I'd agree. I've loaded up a couple of 700MB XVIDs and had no problem playing them.
For some reason, my Sprint Touch Pro has issues playing back even reasonable quality video. For instance, 640x480 video at 1200k (MP4) is a little choppy in WMP, and almost -everything- is extremely choppy in TCPMP, no matter how it's encoded, including 350MB 45-minute XVid TV shows.
AndyCR said:
For some reason, my Sprint Touch Pro has issues playing back even reasonable quality video. For instance, 640x480 video at 1200k (MP4) is a little choppy in WMP, and almost -everything- is extremely choppy in TCPMP, no matter how it's encoded, including 350MB 45-minute XVid TV shows.
Click to expand...
Click to collapse
As I understand it, it's a driver issue. (This is what I've gathered across numerous postings here; someone please correct me if I've gotten something wrong.) The Qualcomm chipset in the TP/Fuze has an efficient driver called Qtv, but Qualcomm charges for a license. WMP appears to incorporate the driver, so it's able to handle moderately challenging videos. 1200 Kbps might be a little more than it's capable of displaying smoothly, but people have reported that 1000 Kbps plays well. On my one trial with DVD Decrypter + SUPER, that was the case for me, too -- full resolution and smooth motion for a video ripped from a DVD with the specs I reported in my earlier message in this thread.
TCPMP, on the other hand, does not include the Qtv driver, so in order to get smooth playback you have to reduce the size, resolution, or frame rate.
Coreplayer has a reverse-engineered partial driver for Qtv. As a result, it falls between TCPMP and WP in capabilities. It is claimed that version 3.0 of Coreplayer will have full Qtv support.
Review, benchmark & comparison: remote controller / presentation suite REDFLY Mobile
It was just a few days ago that Celio Corp, manufacturer of the two (C8N and C7) REDFLY Mobile Companions, have released their own REDFLY Mobile Viewer application, which runs on traditional PC’s (as opposed to the netbook-alike Mobile Companions). (There is a comparison of these three products HERE.)
It, at the first glance, is pretty similar to the well-established phone controller applications already available on Windows Mobile: SOTI’s Pocket Controller, MyMobiler, VirtualCE and so on. (See my last roundup of them HERE) However, there’s a major difference between it and any other, previous phone controller solutions: it’s able to show the contents of the phone’s screen in resolutions up to SVGA (800*600) or XGA (1024*768) on phones with less and equal/more than 128 Mbytes of built-in RAM, respectively.
This means if you have a QVGA (320*240) phone, you can still enjoy using (most of) its applications (and even some games) in either SVGA or XGA resolution, depending on whether it has 64 Mbytes of RAM built-in, or more. On top of this, it has excellent screen redraw efficiency and very low CPU utilization – the latter is very hard to measure even on slower models.
This, basically, offers the same possibilities as either a built-in, digital VGA output (like that of the Dell Axim x50v/x51v or the i-mate 6150/8150). Note that these shouldn’t be mistaken for analogue TV output found in, for example, the i-mate 8502/9502 – the latter has far worse quality and, for “real” presentations (unless it’s a showing lower-res videos only), pretty much useless resolution. Several Symbian S60 phones like the Nokia N95, N82 etc. also have analogue TV output only. (See THIS for more info on these questions.) Also note that the VGA output speed will still be much lower than that of phones or PDA’s with built-in video output circuitry: they, in general, are capable to provide 100% speed when driving an external monitor (even the Dell Axim x50v/x51v, at XGA resolution, with disabled internal screen). An external, software-based solution will have much lower speeds – that is, you won’t for example want to demo the video playback or fast-paced action gaming capabilities of your phone using REDFLY Mobile Viewer. Nevertheless, REDFLY Mobile Viewer is still one of the fastest screen displayer applications – in some tests, it has turned out to be even faster than SOTI’s Pocket Controller, the so far, best application in this respect.
Installation
Get both the desktop EXE (REDFLYMobileViewer.exe) and the CAB file from http://www.celiocorp.com/viewer. These must be separately downloaded and require receiving two e-mails with the download links. Note that this is a 60-day trial version.
There are four different client CAB’s available: RFS5*.CAB, RFS6*.CAB, RFP5*.CAB or RFP6*.CAB. It’s pretty easy to find out which is which. After the leading “RF”, the next letter (either S or P) shows whether it’s a phone / PDA is a touchscreen-enabled, professional (P) or a touchscreen-less, standard (S) phone. Similarly, the next digit, 5 or 6, refers to the Windows Mobile version (5 or 6; note that earlier versions aren’t supported).
After downloading the files, install REDFLYMobileViewer.exe on your desktop and transfer the (right) CAB file to your phone / PDA. Install it on the latter by tapping it; let it restart your phone so that the Redfly client service can start listening. (Note that I would certainly have welcome a solution employed by most other remote controllers: upon noticing the client phone doesn’t have a deployed CAB, they could do it automatically. Hope this is fixed in the future.)
After rebooting the phone (PDA) and reconnecting USB so that activeSync / WDMC is started, you can already click the “Connect” button in the desktop controller.
Opinions, comparisons
Indeed the extended resolution works great. I’ve tested it with the following apps:
- Internet Explorer Mobile (on the iPAQ 210, HTC Wizard and HTC s710)
- Opera Mini 4.2 and some games running under Jbed
- Built-in system applications, setting utilities etc.
- Office Mobile applications
All of these applications (and the dynamic resizing-capable games) did sense the non-standard (non-QVGA/VGA) screen resolutions and resized themselves without any problem.
Second, the speed. If you’ve read my previous phone / PDA controller articles, you know it well enough the more data you’re transferring over USB from the comparatively low-powered, slow processor of the phone, the slower the presentation will be; that is, the frame rate will drop.
While certainly not without problems (slowdown being the most important), REDFLY Mobile Viewer certainly excelled in this area too – it delivered a consistently good framerate at even the highest resolutions. In this regard, only the fastest SOTI’s Pocket Controller can be compared to it.
There are some problems with it, though. Should you want to use this suite as a generic PDA / phone controller suite, you’ll find some of the missing functionalities (for example, clipboard synchronization or, at least, emulating pasting text to the PDA / phone via the keyboard) and incompatibility issues (you simply can’t run some games and apps – most importantly, ones that can only work in Portrait mode) pretty restricting. That is, if you’re looking for a traditional PDA / phone controller and you are absolutely sure you won’t make advantage of the resolution enhancement capabilities of the app, just look elsewhere: even SOTI’s Pocket Controller is cheaper – and is much more featureful (except for, of course, the resolution enhancement).
Screenshots
Let me present you some shots of the app controlling several of my phones / PDA’s. Note that the shots are all pretty huge; this is why I’ve only put in low-resolution, low-quality thumbnails in my article. Just click them to see the original, high-quality, large images
Opera Mini running on my HP iPAQ 210 in XGA resolution
On devices with 128+ MByte RAM (like the HP iPAQ 210), you can select resolutions larger than SVGA (800*600)
On devices with less RAM (say, 64 Mbyte), you can only use either WVGA or SVGA (the other two menu items are grayed out):
(taken on a HTC Wizard)
(taken on a HTC s710 touchscreen-less smartphone)
Just like on my WM6.1-based WM Professional Pocket PC phone, the HTC Universal, it didn’t work on my WM5 176*220 HTC s310 (Oxygen) (screenshot here) so I couldn’t test how it fares.
Benchmarks
As far as CPU usage is concerned, while not connected, it’s sufficiently low: 0.2…0.4% (REDFLY.exe) on the 200 MHz Wizard (and even less on faster devices). While actively controlling the phone, it still remains almost unmeasurable – WAY better than most other, comparable solutions.
As far as screen redraw speeds are concerned (see THIS for more info on all this),
- on the QVGA, 200 MHz Wizard, the number drawing benchmark has shown every second frame (and lasted 10s). Video HERE
- on the VGA 624 MHz HP iPAQ 210, the number drawing benchmark has shown every 1.5 frame (but lasted 19s – that is, there has been some lagging). Video HERE.
Note that Nanobotz, the other “standard” program I use to evaluate screen redraw efficiency, didn’t start with Redfly being active. When starting the Redfly client with the already-running game, nothing could be seen on the desktop either – it was all black. Nevertheless, Speed Racer delivered VERY good results – approximately 1 fps on a 200 MHz (!!!) HTC s710 / Vox Smartphone (video HERE).
In a nutshell, compared to other PDA / phone controller solutions
Pros:
- Revolutionary resolution extension on both all devices
- very low CPU usage
- support for special buttons not necessarily present on all models: the two softkeys, OK and the red/green phone buttons (not present on WM Classic models)
- decent screen refresh speed
- no keyboard input problems on WM Standard (no-touchscreen) devices
- no compatibility problems with Windows 7 (tested under build 7000)
Cons:
- No built-in screenshot capabilities
- No clipboard synchronization or paste emulation via keyboard
- No goodies like file synching / registry editor
- Can’t operate in Portrait mode: if you switch to it manually on the PDA, it won’t obey
- Limited compatibility with some? most? games (Portrait only?) – iGo doesn’t work either. Airfadude, in the other hand, works:
so do Java games under Jbed. For example, Speed Racer running in 800*480:
(video, taken in the 800*480 mode on the slow [200 MHz] HTC s710 HERE)
- If you don’t want to take advantage of the screen resolution, very expensive ($39.99) – even more than SOTI’s Pocket Controller
- resolutions over SVGA only available on models with 128+ MB of RAM (note that it will work with far less actual free RAM)
- It seems to be incompatible with some models (like the above-mentioned HTC Universal and s310)