Kodi Community Forum
libstagefright - Experimental hardware video decoding builds - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: Android Development (https://forum.kodi.tv/forumdisplay.php?fid=184)
+---- Thread: libstagefright - Experimental hardware video decoding builds (/showthread.php?tid=152005)



RE: libstagefright - Experimental hardware video decoding builds - CruNcher - 2013-02-10

by default the encoder encodes it @ 1088 to stay mod16 though the bitstream has the flag to display it @ 1080, if the decoder shows 1088 he ignores the display flag, though the result of this shouldn't be crashs only 8 pixel to much in the output the renderer gets most of the times this results in a mirror line being displayed on the bottom.


RE: libstagefright - Experimental hardware video decoding builds - Koying - 2013-02-10

Thanks for the info. Might be that rockchip is handling this case badly. If you find a 1920x1080 without those extra 8 lines, it would be interesting to test...

Nevermind.

Tried a non-mod-16 SD and I got the "stride effect" and the info line gave me 416 instead of 406.
Definitely something fishy if the video height is not MOD16 (that explains the 1088 too, BTW).

Let's hope I could get some Rockchip support after the Chinese New Year holidays...


RE: libstagefright - Experimental hardware video decoding builds - CruNcher - 2013-02-10

as i said mod2 is definitely not working, i guess because of the H.264 macroblock nature only mod8/mod16 is safe for the vpu Smile
so the solution to get rid of the squished output is to padd the pixels that are missing up to mod8/16 that should work Smile

Though im not sure if that really is the reason for most of the crashing though would be the first time i see that as a cause, but never say never Wink

I wonder how this is being fixed on the other Players though those mostly use the Default SoftwareRenderer (like Googles Default Player Hardware Overlay, or embeded in the Browser non Hardware overlay except in Fullscreen) of Android (either with Hardware overlay or without) not a special GPU Renderer and as i said if i switch in MX Player to the GPU Renderer (HW+) i get the same "stride effect as in XBMC with your GPU renderer, so they suffer the same issue but maybe don't know it yet"

Thus why i said it would be nice to have a new Swrender build to test, the first one is definitely not working.

Thus also why i said i find it a good idea for testing purpose to implement as many options as possible, despite davilla who finds that a bad idea because he fears there might be unpredictable leftovers in the end if i understood his concerns right Smile


RE: libstagefright - Experimental hardware video decoding builds - Drakkim - 2013-02-11

Perhaps this is a bit naive, but could the decoder automatically pad those pixels no make any video mod8? That seems a better solution than recoding every video in my collection... that said, I can recode videos but I'd be COMPLETELY lost looking around in the XBMC/libstagefright code...


RE: libstagefright - Experimental hardware video decoding builds - CruNcher - 2013-02-11

@ Koying

I found a official firmware Kernel release for my tablet which plays the Zelda Medley even longer then any of the other i tested before it crashs (only tested the latest 2.02 build so far with this firmware release (kernel) ) , though im not sure if this uses a older vpu library Sad

Though if the Kernel can be responsible for this i think that's not good for adapting it to work for every RK 3066 Device Sad

So i guess that user that reported that it worked on the mk808 with finless his kernel could be correct


RE: libstagefright - Experimental hardware video decoding builds - bluepeter - 2013-02-11

I'm running the finless rom on both my rk3066 sticks (ug802 & mk802-III) they only differ from the mk808 by using a different wi fi chip. Libstagefright 2/2/2013, Zelda crashes both.

My rom: http://www.freaktab.com/showthread.php?2632-UG802-2dark4u-Finless-custom-ROM-version-1-7-true-1080-and-overclock-AND-best-performance-ever!

I'm using the 720p kernel with no overclock


RE: libstagefright - Experimental hardware video decoding builds - Koying - 2013-02-11

I'm pretty sure the mk808 user tried with MOD16 files, that's all. The build works quite fine on those...


RE: libstagefright - Experimental hardware video decoding builds - CruNcher - 2013-02-11

(2013-02-11, 20:13)bluepeter Wrote: I'm running the finless rom on both my rk3066 sticks (ug802 & mk802-III) they only differ from the mk808 by using a different wi fi chip. Libstagefright 2/2/2013, Zelda crashes both.

My rom: http://www.freaktab.com/showthread.php?2632-UG802-2dark4u-Finless-custom-ROM-version-1-7-true-1080-and-overclock-AND-best-performance-ever!

I'm using the 720p kernel with no overclock

Does the Zelda Medley i posted earlier plays for you without crashing ?


RE: libstagefright - Experimental hardware video decoding builds - bluepeter - 2013-02-11

No, I downloaded it to 8gig microsd, I've got a bunch of test files on the card I'm trying... your Zelda medley file crashed the ug802 within 2/3 seconds of play... the mk802-iii is I believe the better of the two...it crashed after 5 seconds...

By the way, the ug802 rebooted, the mk802-iii crashed xbmc to the android home screen.

I've pointed this out before, and it's important... make sure you have a decent PSU with the rk3066 sticks, otherwise they are very unstable.

I tried all iterations of libstagefright build none proved any better than the other, all fresh installs by the way having cleared cache.

(2013-02-11, 21:14)Koying Wrote: I'm pretty sure the mk808 user tried with MOD16 files, that's all. The build works quite fine on those...

It does Koying....throw CruNchers 'Zelda medley' file at the rk3066/xbmc and it totally gets it's knickers in a twist.


RE: libstagefright - Experimental hardware video decoding builds - CruNcher - 2013-02-12

i could hold it longer with this firmware then 5 seconds it's crazy, though crash or reboot seems also very random things
sometimes the sync option help in the Settings to get it more stable especially "Audio Clock "though with this randomness it's hard to say if that's really the case or random behavior also.
So each playback seems to endup different also it seems playing back something that works like 720p and then 1080p can make it more stable but again with this randomness it's also impossible to say if that's the case.

My test platform is a Tablet but it shouldn't be very different and your results acknowledge it thanks, so im not sure what the other mk808 user tested there Smile

I couldn't yet reproduce this result it's gone http://forum.xbmc.org/showthread.php?tid=152005&pid=1312883#pid1312883 must have hit the decoder in the right time to accept and error with only the decoding issues in that run Wink

Koying i hope you can get in contact with the RockChip Engineer to help out on this 1080p decoder crash issue, at least there seems the will to help from their side, getting VPU Playback working in as many scenarios as possible with their Hardware including Android XBMC Smile
It doesn't look as lost as with the Allwinner Engineer support disaster yet Wink

Herman Chen seems to be the right guy to get in contact with about this issue and improving RockChip XBMC support in general as getting VC-1 / Mpeg-2 and the VP6/7/8 Decoder working Smile


RE: libstagefright - Experimental hardware video decoding builds - hal1000 - 2013-02-14

13-Feb-2013 11:19 this build installed ok.on both my MK808 and MK802IIIS - but my 808 kept crashing and I had to pull the power out to reset it when running xbmc and although my 802iiis didn't crash - neither of them would play any video from the youtube plugin, didn't try any other plugins.

If my post's are not helpful then please let me know and I will stop, I just really want this to work Smile


RE: libstagefright - Experimental hardware video decoding builds - tomycris - 2013-02-14

The last one you have to use is the one provided on 2nd Feb 2013.
this one :
http://mirrors.xbmc.org/test-builds/android/xbmc-20130202-e7b2e92-android-hwaccel-armeabi-v7a.apk

look for hwaccel and that's the one. Or, look for the first page of this thread and you'll be advised when there's a new release.


RE: libstagefright - Experimental hardware video decoding builds - Koying - 2013-02-14

(2013-02-14, 09:53)hal1000 Wrote: 13-Feb-2013 11:19 this build installed ok.on both my MK808 and MK802IIIS
Would you have made a little effort to read the thread, you would have noticed that there are known issues regarding the rk3066 SoC used by your devices.
Only Rockchip can solve those...


RE: libstagefright - Experimental hardware video decoding builds - hal1000 - 2013-02-14

Sorry - I do know the issues, I just thought I would post some feedback seeing as how I have 2 Rockchip devices, the last nightly build seemed to have done something weird. Until now I have installed a few plugins and usually they work more or less.But now I have found out the issue with the youtube plugin, it's not that it can no longer play video, it can not actually find the URL's for streaming. So I apologize for my former post. I installed the TED plugin and a few more and everything is ok on them. Sorry if I caused any problems.

I really do wish you nothing but good luck and I am watching your work with interest.


RE: libstagefright - Experimental hardware video decoding builds - CruNcher - 2013-02-15

Koying i think i got a big step further solving this i can play the Zelda Medley exactly 1 time stable now (still partly random)

At least i found it for this 3.0.8+ Kernel it seems to be the SMP.

I can clearly reproduce this now

you have to turn of the 2nd CPU core

1. Set the governor on hotplug (wait till 1 core goes offline)
2. Set the governor to anything (the offline core wont come back)
3. Start XBMC start the Zelda Medley either playback will go through or come much deeper before it crashes

i have tested this it works for me to get more stable playback with the 1080p Zelda Medley in XMBC libstagefright on my RK 3066 Tablet with the Default 3.0.8+ Kernel.

hotplug/powersave (252 MHz) obviously cant really keep up with the rendering and stucks heavily in XBMC with this 1080p Youtube Video

rendering is flawless now and i come much further even entire run troughs are possible, some stucks happen still in the render pipeline but no big bugs anymore sometimes smaller render flaws, might be as this kernel runs only with a max of 1.27 GHz and with 1 core it's to low to keep everything running.

though the 2nd run doesn't have to be stable anymore if the first one was successful it can again crash (it's crazy)
also after the return to the GUI XBMC (the Kernel) might crash now even if you don't do anything @ all.

so it must be a problem with the multithreading of XBMC and the Rockchip Decoder somewhere, i guess Google uses multiple slices for encoding (which would make a lot of sense, with their multicore server infrastructure) thus means this also might affect Blu-Ray streams.

it's still not perfectly stable but i never could decode it that flawless and even get a whole playback cycle to run through (and that repeatedly and reproducible)

Image

Image


1 of the heaviest debugging i did so far with all this randomness around it Smile


As i guessed right the 2nd core stays offline (hotplug/performance)

Image

Image

Image

Gonna change firmware back again knowing this now