Forums - Performance data for SW vs. HW decoding

The short answer is, you can probably cut your CPU utilization in half by using hardware decoding and OpenMAX AL is the API you need.  Here's the long answer:

For those who might not know, MPEG DASH (Dynamic Adaptive Streaming over HTTP) is a streaming protocol.  DASH can be used to transmit video in a variety of codecs and encryption schemes.  See http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=79041

If you are streaming H.264 to Snapdragon-based devices, you have a couple of options.  You can decode the video stream using a software implementation of an H.264 decoder or you can directly access the H.264 decoder embedded in the hardware of the Snapdragon processor.  Most software implementations are limited to simplified H.264 streams such as Baseline or Constrained Baseline Profile.  In contrast, Snapdragon can decode High Profile H.264 similar to Blu-Ray discs.  So setting aside the issue of CPU utilization, there is still some significant benefit to use the hardware.  You will get better compression/quality ratios simply based on the sophistication of the profiles supported.

Having said that, the CPU and battery savings can be very significant and probably the biggest reason you'd want to switch.  It's hard to say what kind of savings you can expect.  It will vary significantly between Snapdragon S1, S2, S3 and S4 processors.  It will also depend a lot on the profile and average bitrate of your video stream.  It's also worth noting that video encoding is much more tasking than decoding.  If you are only decoding on the mobile device then your savings won't be as significant.  I recently measured the CPU usage of an app running on S2 which switched from software encoding to hardware encoding and found the CPU dropped from about 80% to 12%.  I would expect a decoding-only app to be something more like 40% utilization for software.  See https://developer.qualcomm.com/blog/bambuser-streams-live-video-better-s...

You can access the hardware decoder using OpenMAX AL on Ice Cream Sandwich devices.  For Gingerbread and Honeycomb devices, you can use iOMX.  For an example, see https://developer.qualcomm.com/develop/mobile-technologies/multimedia-op...

hi William_Frantz ,

i have test OMX.qcom.video.decoder.avc component,and i found that it cannot decode H264 stream realtimely,it may be delayed 800~1000ms,so i cannot use it in my realtime usecase.

Are you using DECODE_ORDER or DISPLAY_ORDER?  See method setPictureOrder(int pictureOrder) in QcomOmxDecoder.cpp.

Try using QOMX_VIDEO_DECODE_ORDER for more efficient results.  Hopefully this is your bottleneck

thank you very much for you help,I have solve this  bottleneck using QOMX_VIDEO_DECODE_ORDER .

now I have another problem:

when in the msm8660, the decoded yuv format is :QOMX_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka, but I need to
convert it to I420,i use _Z7convertN7android18ColorConvertParamsES0_Ph can only conver to RGB565 successed,when convert to YCbCr420SP, the program crashed! why?

is there any details about the data storage format of QOMX_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka, thanks

Unfortunately YCbCr420SP conversion is not supported on all devices.  We recommend RGB565 as that is a known supported format for the converter.  We are not able to release the details for QOMX_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka at this time.

thank you for help!

now I want to set OMX_VIDEO_PARAM_AVCTYPE to avc encoder,

but in the msm7k platform,it can only support profile baseline?

in msm8xx platform it can support more, it's there any datasheets describe this? 

Expecting more CPU data for MSM8976 and MSM8996,

if we are playing Youtube 3840x2160 cardboard VR video