Kodi Community Forum

Full Version: Rockchip RK3288 SoC based Android media players and XBMC experience?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
(2014-09-27, 09:01)Willem55 Wrote: [ -> ]I don't care about these make a fast dollar companies that don't have a clue about the rules of open source or customer care, I do care for companies who have a long track record and commitment to mediaplayer users and seek out the xbmc community to work towards a compliant solution. I don't have a clue how well that is working out but maybe you have? I would be happy with a heads up on that.

All in all I'm a bit disappointed to see the ones who are willing to work with xbmc community get bashed for stating and defending their position.

As far as I know, Rockchip themselves, MiniX, and CloudMedia (Popcorn guys), are all working towards a positive relationship with either the XBMC foundation and/or working with individual Team Kodi developers. I do not believe they are the targets of bashing. Rather, it is the fly-by-night ebay/alli sellers and others like them who are being shunned.
Thanks for clearing that up.... and I hope that the other members in this thread will make that distinction also.

I have faith that the first kodi 14 public release will be sufficient for the RK3288 to support 99% of the content that users currently have and the HEVC 4K HW decoding will be there way before the 4K BluRay can be bought.

Or am I missing something here?
(2014-09-26, 14:39)Willem55 Wrote: [ -> ]Defending a platform against negativity does not make me a fanboy... it's never that simple Hedda.
I have been a media players user for 20 years on many platforms, build a few HTPC's on different OS and went through a few out of the box solutions..
I have no problem with anyone's choice of media player platform, I do have a problem with bashing the new kid on the block, just because you favor NUC, Pi or any other platform.
But I grant you that I limit my interest in discussions on what I know or am learning about.... I think that is not a bad thing...

My friendly observation is that this thread should not be encouraged to go off topic..


Hold on... Most of the people on here are bashing Cloud because of past experience with old hardware..
(2014-09-27, 09:16)Willem55 Wrote: [ -> ]What I really would like to know from users who have a modded xbmc on a RK3288 box what other hardware features are supported than HEVC 4K?


Or are there more features then just HEVC 4K? who can tell us?

Someone already asked before; the modded XBMC is distinguished only by the hardware accelerated HEVC feature.

Again, to be clear - hardware accelerated HEVC playback is the only thing different in the modded XBMC. Everything else in the 13 Alpha 12 they use as base is the same. As I said before, the modded XBMC is of little worth except as a viable proof of concept for said feature.

I'll look out for any changes and post here when the updated fork is released.
(2014-09-27, 13:30)BORIStheBLADE Wrote: [ -> ]
(2014-09-26, 14:39)Willem55 Wrote: [ -> ]Defending a platform against negativity does not make me a fanboy... it's never that simple Hedda.
I have been a media players user for 20 years on many platforms, build a few HTPC's on different OS and went through a few out of the box solutions..
I have no problem with anyone's choice of media player platform, I do have a problem with bashing the new kid on the block, just because you favor NUC, Pi or any other platform.
But I grant you that I limit my interest in discussions on what I know or am learning about.... I think that is not a bad thing...

My friendly observation is that this thread should not be encouraged to go off topic..


Hold on... Most of the people on here are bashing Cloud because of past experience with old hardware..

Thank you for clarifying this OT behaviour..Cool

(2014-09-27, 15:49)shomari Wrote: [ -> ]
(2014-09-27, 09:16)Willem55 Wrote: [ -> ]What I really would like to know from users who have a modded xbmc on a RK3288 box what other hardware features are supported than HEVC 4K?


Or are there more features then just HEVC 4K? who can tell us?

Someone already asked before; the modded XBMC is distinguished only by the hardware accelerated HEVC feature.

Again, to be clear - hardware accelerated HEVC playback is the only thing different in the modded XBMC. Everything else in the 13 Alpha 12 they use as base is the same. As I said before, the modded XBMC is of little worth except as a viable proof of concept for said feature.

I'll look out for any changes and post here when the updated fork is released.

And you showed that the kodi 14 nightly builds does OK on HEVC 4K in SW decoding @80% GPU vs the fork xbmc 13 in HW decoding @ 20% GPU load...
Interesting proof of concept but no need to use the forked one as from a user perspective you lose more than you gain..
(2014-09-19, 03:10)Bluesmanuk Wrote: [ -> ]I've been reading all about this and didn't quite get it at first but now have a handle on it I think.

Some of the suggestions talk of exposing.blacklists of these companies etc.

Unfortunately that is not likely to work.

As was alluded to earlier, the Chinese companies don't give a toss about GPL and the like because they operate within different commercial parameters.

I was talking to somebody that works at GCHQ and they were saying that terrorism isn't the top priority of surveillance.

The Chinese were because they are putting concerted effort into stealing as much intellectual property as possible in order to develop and distribute their products to the masses across the globe.

We have seen dirty tricks on many occasions and Rockchip has been part of the process.

So lets look at this from an end users viewpoint.

They want an immediate out of the box experience.

So far, with just about every chinese android device, this this just doesn't happen.

In come the devs like Bob etc at Greaktab to improve the ROMS.

Chinese companies are happy with this because it helps them improve the quality.

So, what is the one product that everybody wants working perfectly more than most?

XBMC.

So an end user isn't going to care about whether a modded version complies with the law, as most are already crossing their fingers that when they order a product from China, it will; have a devalued paperwork attached to reduce or eliminate VAT and Customs fees.

So by being willing to break the laws of their own country, they are hardly going to complain when they get what they want, however it comes.

It terms of getting take down notices in supply sites, good luck with that because Ebay for one is quite happy to sell fake junk (USB drives being a classic). It ain't going to happen.

Now we know from experience that getting sources and the like out of Rockchip can be like getting dung out of a rocking horse, so in general that can be seen as a given.

But, from a business perspective, it is not in Rockchips interest (or at least you would not think so) to sell their brand new product that doesn't live up to it's claims, especially with the number one app that will be used, XBMC.

Perhaps the modded version of an old 13 alpha is simply a prototype that is being supplied to users who will be happy because it may just work as they wish for most of the functionality that they will use.

We may well soon see a more mature Kodi release.

So, how do you get through to Rockchip?

You abandon support for their new baby en mass, especially devs.

Devs like Bob are still relied on to improve functionality.

Take that away altogether and suddenly the new baby might not seem so attractive.

However, as I have seen, being one of the early testers of the Tronsmart R28, it has been, on the whole a very stable release, which indicates that products coming out of the factories are, at last living up to more of the expectation.

Of all the comments that I have seen from fellow testers (setting aside the abysmal remote control) the greatest frustration is not having an XBMC that can play anything they throw at it.

If, tomorrow they all knew of a modded version that would make that happen, they would all jump on it and care less for the legal position.

We have to be realistic about the current situation right now and know that to just have hope to make a difference, you have to go back to the source, Rockchip.

In terms of the criticism that has been levelled at Freaktab devs such as Bob, to my knowledge (and I know that I may be wrong), in terms of general sources being made available, I've not yet encountered a real problem, so would like to see more evidence of that happening before even thinking about passing any real viewpoint. I have just seen that Bob has stated that he will not include such a modded build until the issue is resolved.

Having seen the images previously posted with the hardware acceleration featured shown in XBMC settings, and out of sheer curiosity I downloaded a couple of the supposed modded ROM's, one of which was called xbmc-rk3288-265.

Not only was there no hardware acceleration setting in either of them, there was nothing that listed DTS or Dolby support that I had seen in the Kodi Helix Alpha nightly builds.
Why not simply throw up a warning about GPL non-compliance on initial update check for the addons which causes the updates to fail? I'm sure the Chinese companies who are squatting on illegal code would love to bear the additional cost of hosting all addons themselves....
(2014-09-27, 18:45)bornagainpengui Wrote: [ -> ]
(2014-09-19, 03:10)Bluesmanuk Wrote: [ -> ]I've been reading all about this and didn't quite get it at first but now have a handle on it I think.

Some of the suggestions talk of exposing.blacklists of these companies etc.

Unfortunately that is not likely to work.

As was alluded to earlier, the Chinese companies don't give a toss about GPL and the like because they operate within different commercial parameters.

I was talking to somebody that works at GCHQ and they were saying that terrorism isn't the top priority of surveillance.

The Chinese were because they are putting concerted effort into stealing as much intellectual property as possible in order to develop and distribute their products to the masses across the globe.

We have seen dirty tricks on many occasions and Rockchip has been part of the process.

So lets look at this from an end users viewpoint.

They want an immediate out of the box experience.

So far, with just about every chinese android device, this this just doesn't happen.

In come the devs like Bob etc at Greaktab to improve the ROMS.

Chinese companies are happy with this because it helps them improve the quality.

So, what is the one product that everybody wants working perfectly more than most?

XBMC.

So an end user isn't going to care about whether a modded version complies with the law, as most are already crossing their fingers that when they order a product from China, it will; have a devalued paperwork attached to reduce or eliminate VAT and Customs fees.

So by being willing to break the laws of their own country, they are hardly going to complain when they get what they want, however it comes.

It terms of getting take down notices in supply sites, good luck with that because Ebay for one is quite happy to sell fake junk (USB drives being a classic). It ain't going to happen.

Now we know from experience that getting sources and the like out of Rockchip can be like getting dung out of a rocking horse, so in general that can be seen as a given.

But, from a business perspective, it is not in Rockchips interest (or at least you would not think so) to sell their brand new product that doesn't live up to it's claims, especially with the number one app that will be used, XBMC.

Perhaps the modded version of an old 13 alpha is simply a prototype that is being supplied to users who will be happy because it may just work as they wish for most of the functionality that they will use.

We may well soon see a more mature Kodi release.

So, how do you get through to Rockchip?

You abandon support for their new baby en mass, especially devs.

Devs like Bob are still relied on to improve functionality.

Take that away altogether and suddenly the new baby might not seem so attractive.

However, as I have seen, being one of the early testers of the Tronsmart R28, it has been, on the whole a very stable release, which indicates that products coming out of the factories are, at last living up to more of the expectation.

Of all the comments that I have seen from fellow testers (setting aside the abysmal remote control) the greatest frustration is not having an XBMC that can play anything they throw at it.

If, tomorrow they all knew of a modded version that would make that happen, they would all jump on it and care less for the legal position.

We have to be realistic about the current situation right now and know that to just have hope to make a difference, you have to go back to the source, Rockchip.

In terms of the criticism that has been levelled at Freaktab devs such as Bob, to my knowledge (and I know that I may be wrong), in terms of general sources being made available, I've not yet encountered a real problem, so would like to see more evidence of that happening before even thinking about passing any real viewpoint. I have just seen that Bob has stated that he will not include such a modded build until the issue is resolved.

Having seen the images previously posted with the hardware acceleration featured shown in XBMC settings, and out of sheer curiosity I downloaded a couple of the supposed modded ROM's, one of which was called xbmc-rk3288-265.

Not only was there no hardware acceleration setting in either of them, there was nothing that listed DTS or Dolby support that I had seen in the Kodi Helix Alpha nightly builds.
Why not simply throw up a warning about GPL non-compliance on initial update check for the addons which causes the updates to fail? I'm sure the Chinese companies who are squatting on illegal code would love to bear the additional cost of hosting all addons themselves....

Not a bad idea if the updates can be controlled in such a way.

Some come from outside sources.

I guess the manufacturers may just modify the coding to remove any restrictions.
I think the mod was done based on the Rockchip SDK by some developer hired by one of the manufactures.
SDK is also released to a xbmc developer(s) by Rockchip so it's only a short time before HW decoding of HEVC 4K becomes part of mainstream kodi 14.
And this will all blow over.. and the whole fork becomes vaporware..

Question: how do you upgrade xbmc on android... does it check on the xbmc sites?
Could someone check where the modded xbmc draws it's upgrade and post the link?.... if this is not xbmc then notice and takedown or if xbmc.. poof problems gone first upgrade...

RK3288 Users need the kodi 14 features a lot more than 4K HEVC..
(2014-09-27, 18:45)bornagainpengui Wrote: [ -> ]Why not simply throw up a warning about GPL non-compliance on initial update check for the addons which causes the updates to fail? I'm sure the Chinese companies who are squatting on illegal code would love to bear the additional cost of hosting all addons themselves....

how do you programmatically test for GPL compatibility? You can't.
(2014-09-26, 14:39)Willem55 Wrote: [ -> ]And you showed that the kodi 14 nightly builds does OK on HEVC 4K in SW decoding @80% GPU vs the fork xbmc 13 in HW decoding @ 20% GPU load...
Interesting proof of concept but no need to use the forked one as from a user perspective you lose more than you gain..

The comparison videos/screens I posted were actually of 720p HEVC, not 4K HEVC. 720p HEVC playback [with RK3288] in Kodi using ffmpeg seems strenuous but functional, as you noted. 4K, and even 1080p is a different story; I didn't post comparison videos showing cpu utilization yet but it's not as fluid, likely due to overhead. I did post one video of the modded build showing accelerated playback of 4K HEVC (and 1080p after it was requested).

Of course the modded build does very good with 4K/1080p/720p HEVC as it uses mediacodec. And you're 100% right about the modded build not being a viable replacement for current Kodi builds, for all the reasons you stated.

Also, let's not forget the firmware component. As we saw one poster with a common and highly supported RK3288 device was unable to play certain HEVC files with the modded build due to firmware limitations. Quite the mess for end users for sure.
(2014-09-27, 23:12)nickr Wrote: [ -> ]
(2014-09-27, 18:45)bornagainpengui Wrote: [ -> ]Why not simply throw up a warning about GPL non-compliance on initial update check for the addons which causes the updates to fail? I'm sure the Chinese companies who are squatting on illegal code would love to bear the additional cost of hosting all addons themselves....

how do you programmatically test for GPL compatibility? You can't.
Well I was assuming the forked nature of the application would leave traces which could be polled for and cross-referenced, but you make a valid point.
@shomari... so if I understand it correctly the HEVC HW decoding is achieved by changes to the mediacodec code... assumingly with the usage of the RK3288 SDK from Rockchip, but mediacodec is Android OS level and not the xbmc.apk so where does the whole xbmc fork come into play?
(2014-09-29, 03:10)bornagainpengui Wrote: [ -> ]
(2014-09-27, 23:12)nickr Wrote: [ -> ]
(2014-09-27, 18:45)bornagainpengui Wrote: [ -> ]Why not simply throw up a warning about GPL non-compliance on initial update check for the addons which causes the updates to fail? I'm sure the Chinese companies who are squatting on illegal code would love to bear the additional cost of hosting all addons themselves....

how do you programmatically test for GPL compatibility? You can't.
Well I was assuming the forked nature of the application would leave traces which could be polled for and cross-referenced, but you make a valid point.

There may be things you can search for in object code that may indicate whether or not a standard XBMC source has been used, but how would you the know whether the source code has been released - bearing in mind that the distributor only has to release the source to people it has distributed the object code to.

(2014-09-29, 07:54)Willem55 Wrote: [ -> ]@shomari... so if I understand it correctly the HEVC HW decoding is achieved by changes to the mediacodec code... assumingly with the usage of the RK3288 SDK from Rockchip, but mediacodec is Android OS level and not the xbmc.apk so where does the whole xbmc fork come into play?
If someone shows us the source, the answer will become obvious.
Obviously Big Grin
(2014-09-29, 07:54)Willem55 Wrote: [ -> ]so if I understand it correctly the HEVC HW decoding is achieved by changes to the mediacodec code... assumingly with the usage of the RK3288 SDK from Rockchip, but mediacodec is Android OS level and not the xbmc.apk so where does the whole xbmc fork come into play?
Sorry but your assumptions are wrong here, they have made code changes to XBMC/Kodi and then not shared their code changes, that is a fact and can not be disputed, as otherwise HEVC hardware decoding in XBMC/Kodi simply will not work today.


Support for HEVC in XBMC/Kodi will not happen by magic no matter what the box manufacturer/vendor do to the multiple underlying layers that XBMC/Kodi depends on. Code changes to XBMC/Kodi are still required for adding MediaCodec and Libstagefright support for HEVC, as I tried to explained here http://forum.xbmc.org/showthread.php?tid=204331

That is, changes are needed at many different levels to get it working initially, not only at one single level, but at firmware, codecs, middleware, and finally application (XBMC/Kodi) level. And then further workarounds, optimization and other improvements changes will be needed at all levels are needed to get it to work better over time.

Still the XBMC/Kodi level changes should really only be discussed in the existing thread dedicated to MediaCodec and Libstagefright on Android.


All you need to know right now is that https://github.com/xbmc/xbmc/pull/5374 is merged then users can begin using it XBMC/Kodi, read
(2014-09-17, 11:40)jjd-uk Wrote: [ -> ]There's already a PR pending to add H.265 support to both the Libstagefright and MediaCodec API's, see https://github.com/xbmc/xbmc/pull/5374, so RK3288 should be fully supported once that's in.
It is of course much more complicated than that, as that will only give XBMC/Kodi initial generic support for hardware video decoding of HEVC using MediaCodec and Libstagefright, and that initial generic support is guaranteed to be buggy.

Again, once that initial generic support is merged into XBMC/Kodi then it can be further debugged and optimized as specific issues appears on different platforms with different media containers and video encodings.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37