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:
(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?
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:
(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.
Last edited: