Hello Vedran! Thank you for your answer!
Do you know whether these low-level APIs are exposed on other platforms (Windows Mobile, iPhone and so on)? I always thought that DivX playback on Windows Mobile, for instance, was purely software decoded. The VFP instructions you referred to are actually being used in RockPlayer, and are what causes the current public beta version to only run on certain devices (MSM720x doesn't have the instruction set, AFAIK), but they don't seem to help all too much - smooth playback, even on the TI OMAP in the Milestone/Droid, seems to be very, very taxing, with significant performance improvements through overclocking (indicating that the processor is very much the bottleneck). I just have a hard time believing that even my old HTC Prophet (200MHz TI OMAP 850) had hardware support for DivX - and it still played back 480x360 DivX files flawlessly. I also find it a little puzzling that Android devices have trouble playing simple video files, while games such as Asphalt 5 or FIFA 10 (both games with incredibly detailed graphics) run smoothly... shouldn't these be far more taxing than playing back a measly standard definition video file? Don't get me wrong, Rockplayer is great, and it runs smoothly enough for daily use, but I just have the feeling that the processors in the Android devices aren't being used anywhere near their full potential. The CPU needs to be cranked to 100% for smooth playback, and that drains the battery like crazy... Thanks again for the explanation! Simon On Tue, Jul 6, 2010 at 2:13 PM, Vedran Rodic <vro...@gmail.com> wrote: > 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 Tue, Jul 6, 2010 at 11:25 AM, Simon Broenner > <simonbroen...@gmail.com>wrote: > >> Hello developers! >> >> I've been wondering lately, about the sad situation of media playback >> on Android - namely: Video that isn't supported in hardware and/ or >> natively supported by Android OS. >> >> Coming from Windows Mobile devices, I was suprised (and frankly, >> dismayed) to see that things like simple playback of an XviD-encoded >> AVI file were not possible, even with third party apps. Currently >> there is only one application available (RockPlayer, currently in >> beta), and it only runs well on high-end devices, due to the need for >> immense CPU power. >> >> The same videos that stutter using this only usable DivX/XviD player >> on Android (I need to overclock my Milestone's Cortex A8 to get it >> smooth) run perfectly well on older Windows Mobile devices such as the >> Touch Diamond/Touch Pro/Touch Pro 2 - all of which use far slower >> CPUs. Android devices with the same CPUs can't even run 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... >> >> >> 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?)? >> >> Or does the fact that "...the NDK does not enable you to develop >> native-only applications. Android's primary runtime remains the Dalvik >> virtual machine." limit the speed of the software so drastically that >> it makes implementation of highly efficient software such as a decent >> XviD decoder impossible? >> >> I look forward to hearing your input on this, and would be very >> thankful for links to resources concerned with the issue of >> performance and efficiency in Android applications. >> >> Thanks in advance! >> >> -- >> 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<android-developers%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en > > > -- Simon Broenner -- 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
