Hello Tim! Thanks for clearing up the detail about NEON, I'll read up on that. However, the thing that I'm trying to get at here is that as far as I know, the Windows Mobile platform doesn't have any form of hardware support for decoding XviD either, but still manages to play it back fine with processors that are far outclassed in terms of pure computational horsepower by a Cortex A8 or Snapdragon, even completely discounting the additional instruction sets and other features found in the newer processors.
Please correct me if I'm mistaken, but it seems to me that even without any specialized support for instruction sets or hardware support on either side, Android is just less efficient. Or am I just completely confused, and WinMo devices have had specialized instruction sets and/or even hardware support for this sort of thing all along? Kind regards, Simon By the way, here's the message Vedran sent, which did not get posted: Hi Simon, (I've put you in CC because for some reason my mails to android- developers are still not getting through.) I've also asked myself the same question. The thing is that Android API probably doesn't expose low level APIs for doing hardware accelerated surface scaling and color space ( YUV-> RGB ) conversion. These are two basic conditions for building efficient video decoders since they offload the CPU from doing "stupid work" where every byte of every frame must be processed individually by the CPU. This hardware is present in most 2D accelerators in mainstream hardware for at least 10 years now, so it should be in every android device also. This is probably the main reason for high CPU usage, since it destorys both the CPU cache and uses resources. Other than scaling and color, other things can be accelerated by using DSP hardware that could be different on different android devices. Also using VFP/NEON instructions can help, but for scaling and colorspace conversion, it's best to offload it to dedicated hardware. It is possible that hw scaling and colorspace conversion could work with OpenGL ES, but not all devices support that. I guess that even the devices without OpenGL ES hw acceleration still have sufficient 2D and video acceleration to support this. NDK r3 and r4 added some OpenGL ES and VFP/NEON support. It's unclear from the ChangeLog if this can be used on Android 2.2 only or if it works on older Androids. You can try your look by looking at Android platform source code and finding where is low level video implemented for the standard media player. And lets hope somebody from google has a better answer :) Vedran On Jul 6, 2:35 pm, Tim <tdh...@gmail.com> wrote: > On Jul 6, 10:25 am, Simon Broenner <simonbroen...@gmail.com> wrote: > > > RockPlayer > > because it uses CPU features that aren't even available on these older > > Qualcomm chips - probably needed because otherwise the performance > > wouldn't be up to par, even on a Cortex A8 or Snapdragon... > > True but it still doesn't use NEON > instructions:http://www.diffthink.com/forum/viewtopic.php?f=2&t=11 > > > So what exactly is the problem with Android? Why is it so difficult to > > develop efficient decoders for video formats that aren't natively > > supported? Are codecs usually written in a way that makes them > > impossible to implement with the tools available for Android > > (Assembly?)? > > It takes time to implement a codec using SIMD/DSP instructions. It's > nothing to do with the NDK. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
