If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
What of this? Looks like a modded version of XBMC is floating around China capable of HEVC hardware decoding. Notice the video player shows amc-hevc, signaling the use of mediacodec.
In this shot the Kodi nightly videoplayer shows the same files being played using ff-hevc, or ffmpeg, with much higher CPU utilization. Eventually core utilization maxed out at 100% for all four cores and stayed there. (mostly)
For those wanting to follow, I shot this over to the Kodi team to look over. Discussion over in the official Kodi forums is ongoing.
This shows the chinese devs are at a much more advanced RK3288 development stage than anyone has previously speculated or even considered possible.
So much for the 'RK3288 is in alpha phase' generalities. I would have found this earlier if it wasn't for the fact I was influenced by everyone saying HEVC H.265 hardware decoding in XBMC & Kodi isn't possible. When the factory told me the built-in XBMC was capable of hardware decoding, I didn't believe them, and for two weeks I simply deleted the built-in XBMC everytime they sent an update.
If I was a guessing man (which I usually am not), my guess is this came from RockChip!
I don't think HPH or anyone else that builds a box from the RK ref board has the knowledge to do this!
Bob
"Pzebacz im, bo nie wiedzą, co czynią"
"Прости им, они не ведают, что творят"
"Perdona loro perché non sanno quello che fanno"
"Vergib ihnen, denn sie wissen nicht, was sie tun"
"Vergeef hen want ze weten niet wat ze doen"
"Pardonne-leur car ils ne savent pas ce qu'ils font"
"Perdónalos porque no saben que lo que hacen"
"Oprosti im, jer ne znaju što čine"
"Forgive them as they know not what they do"
If I was a guessing man (which I usually am not), my guess is this came from RockChip!
I don't think HPH or anyone else that builds a box from the RK ref board has the knowledge to do this!
Bob
Bluetimes factory reps laid all the blame on RK, and our dialogue about releasing sources ended there; but not before they told me a new updated build (of this non-compliant fork) will be released soon.
..and by the way, I was also saying this all along. Because it's damn near impossible for this to happen, especially at such an early stage, without rockchip being in on it.
According to something that I saw posted by Tronsmart when asked about whether they were planning to release a modded XBMC, they said that they are working on it.
According to something that I saw posted by Tronsmart when asked about whether they were planning to release a modded XBMC, they said that they are working on it.
They probably aren't working on it themselves. That would make two factories claiming to have distinct forks with features outpacing the entire Team XBMC - which is just about impossible. Factories don't go from literally zero code contributions to an open source project to leaping over the entire project timeline in one fell swoop. The one modded non-compliant XBMC in the wild is the same in all firmware packages.
Also, it's not a good thing for developmental progress or the end user, if properly understood. A factory (or factories) taking from an open source project, building on it, then refusing to contribute their code back into the project is detestable and stunts progress and improvement.
TL;DR: add Tronsmart to the shitlist of xbmc parasites.
They probably aren't working on it themselves. That would make two factories claiming to have distinct forks with features outpacing the entire Team XBMC - which is just about impossible. Factories don't go from literally zero code contributions to an open source project to leaping over the entire project timeline in one fell swoop. The one modded non-compliant XBMC in the wild is the same in all firmware packages.
Also, it's not a good thing for developmental progress or the end user, if properly understood. A factory (or factories) taking from an open source project, building on it, then refusing to contribute their code back into the project is detestable and stunts progress and improvement.
TL;DR: add Tronsmart to the shitlist of xbmc parasites.
Working on it could mean collaboration with Rockchip, who if we are to believe are behind the modding , could mean going from zero to distribution in very little time.
The one current modded non compliant release is as things may be today, but tomorrow we could see something updated.
Users that purchase the product that would see everything working out of the box would see it as a good thing because they are getting what they perceive that they have paid for and the reality is that right now, they would care very little for the longer term development process.
I'm not condoning what may be happening but there is a reality to how much an end user will care today in our throw away, something better will be along tomorrow world.
There is another side to all this that I was pondering last night.
Is it possible to stay within the GPL by taking an open source project and injecting what could be seen as a proprietary technology that adds to the functionality but if were not present, would not prevent the product working in it's core form, albeit without the external source that merely improves it's potential.
Therefore in that situation, would any proprietary sources be subject to the rules governing open release?
Before we add anybody to any list, we should also wait until any rules, legal or moral are actually broken rather than preempt something that may be something said simply to pacify prospective purchasers.
Before we add anybody to any list, we should also wait until any rules, legal or moral are actually broken rather than preempt something that may be something said simply to pacify prospective purchasers.
The rules pertaining to GPL violations and non-compliant XBMC distribution were, are, and continue to be broken. That is not in question.
The only thing in question is who understands what it really means, and who ultimately cares. I understand it, (I was the one who brought it to light) and I care.
And let's be clear, while some may attach a moral component to this argument, it's not an ambiguous moral question at all. It is a violation of the GPL agreement governing XBMC distribution, in black and white, not some esoteric concept. A license is a license, morality not withstanding.
When I first brought it up, the users who don't care about GPL/open source said I was lying.
As evidence mounted, those same users said wait until all details are gathered.
Now that the details I originally publicly offered, both here and in the XBMC forum have been confirmed, those same users now say 'well maybe it's not a problem after all' and engage in all sorts of mental gymnastics to justify the unjustifiable. Hilarious.
Just say you don't care about development (as this conduct hinders it), open source principles (it's OK to say **** you to open source projects in the name of short term gain) and community-oriented progress (why give your code back to Team XBMC, which built the base - **** them, right?) and be done with it. If that's your opinion, own it. It's OK to be honest.
But don't beat around the bush with suppositions and other nonsense.
edit: TL;DR: yeah, Tronsmart still goes on the shitlist. At least for me.
The rules pertaining to GPL violations and non-compliant XBMC distribution were, are, and continue to be broken. That is not in question.
The only thing in question is who understands what it really means, and who ultimately cares. I understand it, (I was the one who brought it to light) and I care.
And let's be clear, while some may attach a moral component to this argument, it's not an ambiguous moral question at all. It is a violation of the GPL agreement governing XBMC distribution, in black and white, not some esoteric concept. A license is a license, morality not withstanding.
When I first brought it up, the users who don't care about GPL/open source said I was lying.
As evidence mounted, those same users said wait until all details are gathered.
Now that the details I originally publicly offered, both here and in the XBMC forum have been confirmed, those same users now say 'well maybe it's not a problem after all' and engage in all sorts of mental gymnastics to justify the unjustifiable. Hilarious.
Just say you don't care about development (as this conduct hinders it), open source principles (it's OK to say **** you to open source projects in the name of short term gain) and community-oriented progress (why give your code back to Team XBMC, which built the base - **** them, right?) and be done with it. If that's your opinion, own it. It's OK to be honest.
But don't beat around the bush with suppositions and other nonsense.
edit: TL;DR: yeah, Tronsmart still goes on the shitlist. At least for me.
Could it be in question though?
Without being able to see the actual sources of the modded XBMC though, can a judgment be made as to whether the GPL is being broken in this particular case?
We all know that China does not play by the same rules as everybody else, but so many are happy to purchase their products, which is irony but reality.
I wonder if the legal teams that help to enforce the GPL have made appropriate legal moves to challenge such prospective non compliance and they would be in the best position to know what is and is not allowed.
Where there are inconclusive things that cannot yet be backed up by definitive facts then supposition becomes part of debate.
It only becomes nonsense in the face of irrefutable fact, which is not yet present.
Without being able to see the actual sources of the modded XBMC though, can a judgment be made as to whether the GPL is being broken in this particular case?
We all know that China does not play by the same rules as everybody else, but so many are happy to purchase their products, which is irony but reality.
I wonder if the legal teams that help to enforce the GPL have made appropriate legal moves to challenge such prospective non compliance and they would be in the best position to know what is and is not allowed.
Where there are inconclusive things that cannot yet be backed up by definitive facts then supposition becomes part of debate.
It only becomes nonsense in the face of irrefutable fact, which is not yet present.
Are you just trolling me, or what? The modded XBMC is capable of hardware accelerated HEVC playback. That is not possible without code amendments and that code is not part of the XBMC project and to date has not been submitted.
You do realize that apart from your constant exculpatory comments, you're the only one denying:
the xbmc is modded
the source code for the modded distro is required to be submitted for the release to be compliant
...you're trolling the shit out of us, there's no other explanation.
Are you just trolling me, or what? The modded XBMC is capable of hardware accelerated HEVC playback. That is not possible without code amendments and that code is not part of the XBMC project and to date has not been submitted.
You do realize that apart from your constant exculpatory comments, you're the only one denying:
the xbmc is modded
the source code for the modded distro is required to be submitted for the release to be compliant
...you're trolling the shit out of us, there's no other explanation.
I think that you need to take a step back and look at things from a less emotional perspective and look at things from all sides.
Taking the minority report approach, rather than the innocent until proven route is not a good one in my opinion.
You do not know for sure that such hardware accelerated playback is not possible without inner code amendment, other than reference to an external proprietary solution.
Therefore your demand that it has to be does not necessarily hold up.
You should not present as fact that which you cannot know for sure.
Tp put that into perspective, you said, 'you're the only one denying:
the xbmc is modded'
Fact 1 - No I didn't say anything of the type. I said that it's method of implementation that may have an appearance of being modded, has not been established as fact yet.
Then you said that you're the only one denying:
the source code for the modded distro is required to be submitted for the release to be compliant
Fact 2 - I never said that at all. Again, I repeat that at this moment in time, the facts have not been established as to how such an implementation has been made because the sources are NOT available for scrutiny in order to establish belief from fact.
Chill out, it's not the end of the world and hopefully it will all be resolved before the next oddity comes along.
Taking a bullish approach to something where there is no irrefutable fact to be presented is less likely to get you heard.
I am hoping that you are right and that it is all within the code and that some pressure can be bought to release it for the benefit of all.
If reasoning and a different perspective is classed as trolling then the definition requires an update.
Throwing irrelevant remarks around designed to inflame is the best way to become ignored, which you have, in my case, done perfectly and shall enter into no further debate with you.
I shall simply wait for more information to be provided in order to come to a more reasoned conclusion based on what I do know, rather than what I might think that i do.
..all the way to where we are now. There's no emotion in saying the code was amended and per the GPL the sources must now be released to make the amended code base compliant.
I'm not on team XBMC. I have no emotional or direct interest in this matter. Try something else to obfuscate your true position.
You do not know for sure that such hardware accelerated playback is not possible without inner code amendment, other than reference to an external proprietary solution.
...that's my favorite part of your post! Go tell that to the posters representing Team XBMC that have stated [the ridiculously obvious] fact that the code (in the modded release) is amended to allow this feature.
Again, you've got to be trollling. To the ignore list you go.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment