Thread Closed
libstagefright - Experimental hardware video decoding builds
Koying the newer firmware is different with the governor

and MX Player isn't showing any problems with it and their HW+ renderer so something changed maybe the decoder

XBMC governor results

default interactive = crashes
hotplug/conservative (rendering issues)
hotplug/performance (works)

i get the same errors as with the previous firmware and MX Players HW+ Decoder on XBMC now (the strange line on top + all the white cloud decoding issues with hotplug/conservative)

So the XBMC workaround behavior will be firmware dependent also (i guess this is the pretty newest Rockchip decoder the Kernel firmware is from 22 Dec) Sad

The Previous Kernel (firmware) was from Dec 1

Quote:Not sure, but I think MX's H/W+ is actually using libstagefright, too.
Which makes me wonder what their "plain" H/W is... Did they implement a specific module per SoC? Seems a hell of work to maintain...

Hmm i don't understand android video decoding buildup yet but couldn't it be that the difference is just the renderer ?

Though we need to test this thus i beg you for a working swrenderer build all the time Wink

it would make no sense to implement anything special if you have the decoders directly implemented as OMX components you just throw your data @ them and wait for the output (in this case from the vpu_service.o) the main difference would be only the Renderer where it endsup.

And since Jelly Bean their isn't surely for nothing the MediaCodec Info API

For me it looks just like your GPU renderer has problems with the input and that by using the default Swrenderer best with Hardware Overlay might solve all problems.

The Default swrenderer used by Android itself works all the time with Rockchips Decoder and pretty every other plarform no matter which firmware as this is what RockChip and everyone else are testing in the CTS process to make sure it works, doesn't they ?

Also Rockchips default Player uses this Hardware Overlay

I mean how else you could get a consistency into this practically without this it would mean everyone does their own Android implementation specifically for their Decoder ?

Though still the easiest way to get XBMC working with RK 3066 flawless with multihreading and maybe independent of the firmware version :

Copyright © 2010 ROCKCHIP, Inc.
* author: chenhengming [email protected]


PS: The firmware 22 Dec i tested was modded by someone and he definitely broke it, why can't moders test their firmwares completely ?


Archos implemented it almost perfectly it broke on the modded firmware (except no Hardware Overlay), they are also only one of two implementations who can correctly disable the nav bar.

Image

Image

Image


Though MX Player is not 100% stable on this newest Firmware calling the GUI can either freeze or crash the Kernel again
  Thread Closed
 
Thread Rating:
  • 10 Vote(s) - 4.5 Average


Messages In This Thread
RE: libstagefright - Experimental hardware video decoding builds - by CruNcher - 2013-02-15, 23:05
libstagefright - by mo123 - 2013-05-14, 14:29
RE: libstagefright - by Koying - 2013-05-14, 14:30
RE: libstagefright - by Maverick5269 - 2013-05-16, 23:04
RE: libstagefright - by matander - 2013-05-19, 18:26
RE: libstagefright - by FreeFrag - 2013-05-22, 13:02


Logout Mark Read Team Forum Stats Members Help
libstagefright - Experimental hardware video decoding builds4.510
This forum uses Lukasz Tkacz MyBB addons.