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 - djvdgalien - 2013-04-04

(2013-04-04, 16:07)Koying Wrote: rk3066 is lagging on 1080p, even with the updated libstagefright.so.

That won't be solved ever unless rockchip solve this on their side, which seem not so probable as they would be working on a ffmpeg based framework, whatever that actually is...

Koying, I think you really did a very good job.
But I'm afraid the latest gotham alpha built is the best it will get, which is pretty good but still quite far from perfect. If Rockchip isn't developing libstagefright.so any further......
Future will tell.


RE: libstagefright - Experimental hardware video decoding builds - PiSToLBR - 2013-04-04

I tested latest build from Koying. Worked fine with 720p and 1080p videos on my Odroid-U2 with CyanogenMod 10.1.

Only found the skip, forward / backwards bug. Going back to the 19/02 build.


RE: libstagefright - Experimental hardware video decoding builds - RedPenguin - 2013-04-04

This build seems to replace librtmp.so on boot yet my buddy's Nexus 7 needs to replace the librtmp.so with one that supports KSV's redirects which we currently have a replacement file but every single reboot it's replaced with the original.

Is there anyway to either disable or "hack" this replacement process?


RE: libstagefright - Experimental hardware video decoding builds - Koying - 2013-04-05

(2013-04-04, 23:28)RedPenguin Wrote: Is there anyway to either disable or "hack" this replacement process?
Nope, you'll have to overwrite the default one each time you install a xbmc apk.
Or build your own apk, of course...


RE: libstagefright - Experimental hardware video decoding builds - LtDan - 2013-04-05

(2013-04-04, 08:20)Koying Wrote: Well, not having a 12.1 + libstagefright is a release management decision from the Team, not a technical one.

Although, with the recent build system change, I'm not even sure we can still automatically build a < 13 version without backporting Jenkins stuff...

OK to help me understand where this threads development life cycle is at. Is the above post stating all of the libstagefright work is a dead end and dies with version 12? I had always been under the assumption that if successful, this work would be incorporated into the baseline xbmc code base? Don't misunderstand i truly appreciate all of the hard work over the past several months but if h/w acceleration for android devices will not be supported going forward, team-xbmc needs to look at enabling support for launching other video players to perform playback and streaming in android. Otherwise I would think xbmc for android will die without ongoing hw accelerated playback support or is there some other approach the team foresees as meeting user video performance needs on the android platform?


RE: libstagefright - Experimental hardware video decoding builds - RedPenguin - 2013-04-05

(2013-04-05, 00:09)Koying Wrote:
(2013-04-04, 23:28)RedPenguin Wrote: Is there anyway to either disable or "hack" this replacement process?
Nope, you'll have to overwrite the default one each time you install a xbmc apk.
Or build your own apk, of course...

no we are not trying to keep the librtmp.so file between XBMC installs but with the same XBMC install the file is replaced every boot.


RE: libstagefright - Experimental hardware video decoding builds - JamesWong - 2013-04-05

I work with a oem company that manufacturers devices based on RK3066/3188 among others. For one we would like to become a sponsor to XBMC and secondly we would like to work on the hardware decoding.

Is part of the problem that Rockchip hasn't (or won't) released the source to the their Java player? If they did it, we would need to port the code to be used as a player in XBMC, correct?

I also spoke to Allwinner about this and their reply is that they had release code here: https://github.com/goland/xbmc/tree/master/xbmc/cores/a10


RE: libstagefright - Experimental hardware video decoding builds - Mafarricos - 2013-04-05

The Gotham release on my Minix Neo G4 doesn't works well with all plugins. Youtube plugin doesn't play videos. Some plugin's doesn't show page X/Y, etc.

About the HW decoding it seems equal to the 02/19 release, for now I'm going back to that release.


RE: libstagefright - Experimental hardware video decoding builds - stepir - 2013-04-05

(2013-04-05, 04:10)JamesWong Wrote: I work with a oem company that manufacturers devices based on RK3066/3188 among others. For one we would like to become a sponsor to XBMC and secondly we would like to work on the hardware decoding.

Is part of the problem that Rockchip hasn't (or won't) released the source to the their Java player? If they did it, we would need to port the code to be used as a player in XBMC, correct?

I also spoke to Allwinner about this and their reply is that they had release code here: https://github.com/goland/xbmc/tree/master/xbmc/cores/a10


+1

All those droid stick manufacturer and oem should really start looking at very actively support the XBMC team.

99% of the purchase are just to build media centers!


RE: libstagefright - Experimental hardware video decoding builds - Memphiz - 2013-04-05

(2013-04-05, 04:10)JamesWong Wrote: I work with a oem company that manufacturers devices based on RK3066/3188 among others. For one we would like to become a sponsor to XBMC and secondly we would like to work on the hardware decoding.

Is part of the problem that Rockchip hasn't (or won't) released the source to the their Java player? If they did it, we would need to port the code to be used as a player in XBMC, correct?

I also spoke to Allwinner about this and their reply is that they had release code here: https://github.com/goland/xbmc/tree/master/xbmc/cores/a10

Please read and follow http://xbmc.org/about/contact/ for info on sponsoring and stuff.


RE: libstagefright - Experimental hardware video decoding builds - StealthOne - 2013-04-05

I tested the recent build posted (Gotham + libstagefright) on my ODroid U2 running CM10.1. Works like a charm. I only tested 720p streamed over the network, but that used to be a bit choppy with software decoding and now it looks great. Keep up the good work!

My tests weren't extensive so I haven't encountered any bugs yet.


RE: libstagefright - Experimental hardware video decoding builds - nachopavon - 2013-04-05

In the minix forums (http://minixforums.com/threads/libstagefright-hw-accelerated-xbmc.411/page-6) rock chip claims they have developed a new libstagefright.so... Do you know anything about this?


RE: libstagefright - Experimental hardware video decoding builds - Maverick5269 - 2013-04-06

(2013-04-05, 22:31)nachopavon Wrote: In the minix forums (http://minixforums.com/threads/libstagefright-hw-accelerated-xbmc.411/page-6) rock chip claims they have developed a new libstagefright.so... Do you know anything about this?

Yes. I saw that to. The MINIX team says it will be on their 4.2.2. But can we have only the lib? were we can find this?


RE: libstagefright - Experimental hardware video decoding builds - Koying - 2013-04-06

Never heard of this "improved" libstagefright.so for rk3066, supposedly working for 1080p, before MINIX announcement.

Very hard to figure out what Rockchip's moves are...


RE: libstagefright - Experimental hardware video decoding builds - mirobaka - 2013-04-06

Latest gotham build plays back great on Asus Transformer Prime TF201. I tested local playback with 1080p and 720p. I was unable to test network playback at all since any network location I gave to xbmc would say "unable to access network".