Kodi Community Forum

As Comparison

Mx Player (Hardware Overlay ok)



MX Player (GPU Renderer H/W+ fail)



They suffer also with this sliced streams and their Non Hardware Overlay Renderer (GPU?) though they don't crash
though in their case it doesn't help to disable the 2nd Core @ all

Good news for Huawei Mediapad 7" owners: It works like charm! I am using the CleanICE v1.5 ROM

Sorry I cannot post stats and logs now, but will try doing it in few weeks!

Great work! Looking Forward to having it working on Android TV sticks one day too!

(2013-02-15, 08:43)catatau Wrote: [ -> ]Good news for Huawei Mediapad 7" owners: It works like charm! I am using the CleanICE v1.5 ROM

Cool. I assume it's the dual-core Snapdragon version?
Please, when you have time, try the reference videos referenced in the OP and publish the logs, so that we can confirm the good news.

(2013-02-15, 08:36)CruNcher Wrote: [ -> ]MX Player (GPU Renderer H/W+ fail)

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...

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)

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

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.








Though MX Player is not 100% stable on this newest Firmware calling the GUI can either freeze or crash the Kernel again

having some issues with the latest build on nexus 10 (4.2.2)
anything that i try to play with srt subtitles
just before the subtitle is about to appear the video and audio stops for like 1-2 sec the subtitle appears and playback continues
everything is still in sync, however playback pauses/freezes every time a subtitle is supposed to appear
not sure when this issue started or whether its due to 4.2.2 update, however I have played 720/1080p films + subs on previous libstagefright builds with no issues

please find my debug log of an example file w/ subs here

also perhaps on an unrelated note my audio seems to crackle (produce static output) at regular intervals irrespective of encoding or channel configuration (tried dts, aac, ac3 2.0-5.1), i tried video in other apps bsplayer/youtube and there is no crackle

i also occasionally get artefacts but they are very few and far between (after hours of playback) and usually only affect a small fragment of the visible image

thanks for the work done so far koying, i'm very happy with hardware accelerated xbmc on my android device

Stay with the build that works for you in it's current state the most stable im not sure but i think koying updates with the main branch and so it is problematic to keep issues apart, i don't want to sound rude but subtitle issues shouldn't be given high priority first normal playback should be getting stable on as many devices as possible with as many bitstreams as possible.

Koying

My 1 core workarround still works and stable on this official 22 Dec Kernel and Firmware


hotplug (conservative/performance)





though overlay 1080p gui playback seems not doable (to slow) with only this 1 core +vpu decoding/rendering/scaling



until you and chen optimized it working fully multithreaded it's better then crashing

though i wonder what causes this extreme cpu spike in the menu rendering ?

PS: I could improve the background playback performance @ 1080p even on only 1 core im continuing on this path for now, no crashs so far i reach up to 70 fps @ GUI rendering so far.

Found a way now to directly disable 1 Core, testing.

Is it still possible to try the software rendering version mentioned in the first post? When I try the link it says the file is not available.

Thanks CruNcher about offlining cpu. It works as described with other findings in PM (to not to be OT here)
Can you be more specific how to easily directly disable CPU cores?
Big thanks goes also to xmbc devs,mainly Koying!!!

(2013-02-17, 07:17)CruNcher Wrote: [ -> ]Found a way now to directly disable 1 Core, testing.

Kind of lol to have to disable a cpu core to get proper HD decoding

Koying are you in touch with Alok of the Picuntu project? he makes an ubuntu version for the RK3066. He is also in direct contact with Rockchip. Another guy on that project is AndrewDB a Dutch guy. You might be able to share ideas.

//edit

http://www.slatedroid.com/topic/51938-pi...r-testing/

The thing is Hardware acceleration is the most valuable proprietary thing in a embedded system and getting it through reverse engineering can take a long time, it's better to make Rockchip aware of the fact that their competition is already using it and successfully sharing with their clients
Amlogics sponsered XBMC implementation im sure Rockchip will free up some resources if they aware that their clients demand the same and the more users demand it in minix and co's forums the more they are under the pressure to deliver to their clients
They already showed interest in picunto as well as chrome os and im sure they will in the future engage into Android XBMC
The hardware these days is pretty uniform there almost no differentiators anymore vs the competition in this low cost segment it's the Software that counts and XBMC support sells perfectly

Allwinner seems to not want to understand this , they will see what they get from it once Rockchip is supported

i would also say XBMC is a great Benchmark itself that is yet not cheated on also it's great for testing overall system kernel stability

i like it already much more then Antutu for example especially Antutu cant push everything to it's limits in the SOC and around neither any Game can do that XBMC can do it easily , though not everywhere fully multithreaded yet

Having Picuntu on Tablets or any other linux Arm Distro working with the RK3066 directly with XBMC natively and without any Android overhead would be a blast for sure