[General Topics] Menneisyys:
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: