Subject: [rtcweb] Video decoder complexity and battery power optimizations with hardware decoding

From: Stephan Wenger <[email-masked]>
Date: Tue, 31 Jul 2012 00:12:25 +0000

Hi all,
I promised in the meeting a link to the following doc: JCTVC-J0128<http://phenix.int-evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J0128-v1.zip>
To summarize, using a single core of the iPad3's dual core processor, software decoding of HEVC (forthcoming H.265) at 720p30 resolution and 1.5 Mbit/s bitrate is possible.  A fully charged battery is empty after 8 hours.  This compares to 10 hours when decoding H.264 using hardware acceleration.
My take from this data point is that battery life is not all that much affected by hardware-based decoding, at least not for tablets and larger devices.  If your screen and battery are considerably smaller, but your processing demands similar, hardware decoding may become more beneficial, relatively speaking.  However, if you scale down video resolution with screen size, things ought to be approximately in the same ballpark.
While at this discussion, let me reiterate two other points made in the meeting.  First, AFAIK, there are no hardware-accelerated encoders in today's products that could meaningfully be used for conversational applications; encoders run software-only, and their complexity is necessarily considerably higher than that of a decoder (because an encoder includes all features of a decoder exept the entropy decoding, plus all the search/mode decision mechanics, forward transform/quantization, assorted filters i.e. for motion compensation, and the entropy encoder).  And second, today's hardware based decoding is not well suited for video conference decoding use, as it does not offer functionalities such as error control or concealment beyond re-sychronization after IDR pictures—and one should avoid IDR pictures in conversational applications because of their size and resulting delay.
Stephan