My dev board is a Beagle Board with an A8 at the moment, so I can't
say how it would run on the A9. Best bet would be to grab the library
and run a test on sample hardware.
> Any performance comparison with H.264 codec will also help.
Sorry, I don't have any.
--
- johann koenig
google
http://bloggingthemonkey.blogspot.com/2010/08/ffpv8-neon-720p24.html
720p on an A9 so far using ffvp8 and neon. libvpx on an A8 is far from
reaching 720p.
> Any performance comparison with H.264 codec will also help. Appreciate
> your help!!!
Since h264 and vp8 are somewhat *cough* similar, I'd expect similar
performance running on an ARM CPU. For SOCs with dedicated HW units
(e.g. OMAP3/OMAP4) the differences between VP8 and H264 might make not
all HW units be usable and therefore H264 would perform better than VP8.
Hi! libvpx suffers a bit, esp on ARM SoC sort of devices, because of
some extra memcpy's (whenever one of the reference frames is updated),
and more passes over the data, so a bit less efficiency when it comes
to cache utilization. At this point, there are a couple more
functions that can be converted to neon for ffvp8. (And lack of
multi-thread support in ffvp8.) And the neon code could be tuned to
save a few cycles here and there. And a few other misc things. So
still some room for improvement. But as it is it is just a bit over
720p24 avg at the display and dips below that on complex scenes at
1ghz on an A9. But 1080p is a whole lot more than 720p!! I think for
1080p you need to hw accelerate it or have a lot of ghz and memory
bandwidth to keep up ;-)
Really, from a power and performance standpoint, you can't beat asic!
BR,
-R
>
>> Any performance comparison with H.264 codec will also help. Appreciate
>> your help!!!
>
> Since h264 and vp8 are somewhat *cough* similar, I'd expect similar
> performance running on an ARM CPU. For SOCs with dedicated HW units
> (e.g. OMAP3/OMAP4) the differences between VP8 and H264 might make not
> all HW units be usable and therefore H264 would perform better than VP8.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Codec Developers" group.
> To post to this group, send email to codec...@webmproject.org.
> To unsubscribe from this group, send email to
> codec-devel...@webmproject.org.
> For more options, visit this group at
> http://groups.google.com/a/webmproject.org/group/codec-devel/?hl=en.
>
>
>> > Any performance comparison with H.264 codec will also help. Appreciate
>> > your help!!!
>>
>> Since h264 and vp8 are somewhat *cough* similar, I'd expect similar
>> performance running on an ARM CPU. For SOCs with dedicated HW units
>> (e.g. OMAP3/OMAP4) the differences between VP8 and H264 might make not
>> all HW units be usable and therefore H264 would perform better than VP8.
>
> [Rupesh] So far everyone has achieved any HD decode using HW
> accelerators, and I believe thats the way you can conserve power on
> the portable devices. No point in going for SW solution when the
> standard is almost carved in stones.
"almost" is not good enough. HW accelerator design in e.g. omap3 and omap4
predates the public release of VP8 by years...
Only chips that are in the design stage currently will have (full) VP8
hw acceleration...