• 1
  • 18
  • 19
  • 20(current)
  • 21
  • 22
  • 37
Rockchip RK3288 SoC based Android media players and XBMC experience?
I agree with what's been said. I never meant to indicate (and haven't) any course of action as I don't have a crystal ball. I don't know whether the sources will be released, or what entities will do the releasing.

I simply stated what I do know, and that is that the best and ideal outcome would be full disclosure of the amended sources.

Of course, that presumes a certain philosophical notion and I'm pretty sure that's where most of, if not all, of the beef comes in to play.
Reply
Actually do you mean a philosophical notion, or do you mean compliance with the law?
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
(2014-09-30, 22:15)nickr Wrote: Actually do you mean a philosophical notion, or do you mean compliance with the law?

...ha! Touche Big Grin
Reply
Question to the experts: could kodi be configured for HEVC and H264 4K to use an 3d party playback engine?
Is that a configuration or a hard coded change?
Reply
http://wiki.xbmc.org/?title=External_players

suggests that videocodec and videoresolution can be used as tests, but their examples are pretty limited (perhaps due to the wiki page not being updated for moderner times?)
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
Thanks for the link... which holds this link at the bottom http://wiki.xbmc.org/index.php?title=HOW...on_Android

That begins with:........... Normally, you only need to use an external player if your Android device doesn't have a version of XBMC that works with hardware video decoding.

So it's just configuring XML and no code change involved...

Nice.... now why all the fuss of modding the build in player what is the catch here?
Reply
(2014-09-30, 19:31)Willem55 Wrote: give people enough rope and see what they do with it...........Like hang themselves...
Love the machiavellian approach and you're right... assumption of guilt only serves the guilty.
Saying the manufacturers will certainly screw the xbmc community without really knowing their intentions is giving them the license to do what you've expected them to do.

No, we say these things because they have tried to screw us over in the past. History speaks for itself. Even Rockchip, which seems to be doing better now, has had their own fair share of violations in the past, including those involving XBMC.
Reply
(2014-10-01, 07:08)Willem55 Wrote: Question to the experts: could kodi be configured for HEVC and H264 4K to use an 3d party playback engine?
Is that a configuration or a hard coded change?

I'm not sure why anyone would bother considering we already have H.265 test builds available for Kodi.

(2014-10-01, 08:54)Willem55 Wrote: Thanks for the link... which holds this link at the bottom http://wiki.xbmc.org/index.php?title=HOW...on_Android

That begins with:........... Normally, you only need to use an external player if your Android device doesn't have a version of XBMC that works with hardware video decoding.

So it's just configuring XML and no code change involved...

Nice.... now why all the fuss of modding the build in player what is the catch here?

External players are a bandage. Far more often than not, it is a sub-par experience that feels hacky and tacked on with duct tape.
Reply
Well to me it looks a lot less a sub-par experience that feels hacky and tacked on with duct tape then this bloody xbmc hack that's been distributed right now..
As a temporary stopgap to me playercorefactory.xml appears rather chique.. but if you say the test build will make it all obsolete then I'm happy.
Reply
(2014-10-01, 13:00)Willem55 Wrote: Well to me it looks a lot less a sub-par experience that feels hacky and tacked on with duct tape then this bloody xbmc hack that's been distributed right now..
As a temporary stopgap to me playercorefactory.xml appears rather chique.. but if you say the test build will make it all obsolete then I'm happy.

If you are referring to my pull request https://github.com/xbmc/xbmc/pull/5374
It is not "hacky and tacked on with duct tape". It is integrated exactly the same way avc support was added. I've been investigating the one known problem with it (MediaCodec playback not working) and this is looking like an omission in the android MediaCodec implementation. I.e. not a problem with my patch.

I just checked the test build myself (http://forum.xbmc.org/showthread.php?tid...pid1803928) to be sure there are no differences between it and my private build. It is working well.

If you are interested in the details of the MediaCodec problem... I downloaded the android SDK source for the Tronsmart Orion R28 which is another rk3288 platform which has supplied the android SDK sources on mega. There is a call to a function setComponentRole in frameworks/av/media/libstagefright/ACodec.cpp where it will fail. This is called during MediaCodec::configure. It fails because there is a hard coded list of "roles" that does not include an hevc decoder. I'm currently downloading the android SDK sources for the firefly board to see if it has the same problem.
Reply
Oh no... the "hacky and tacked on with duct tape" was a quote from Ned Scott post #293 as to calling a external player using playercorefactory.xml, I just said I prefer that over the hacks currently done in Gotham 13 released by some vendors.
Keep up the good work and thanks for the heads up on development progress.
Reply
(2014-10-01, 08:54)Willem55 Wrote: Thanks for the link... which holds this link at the bottom http://wiki.xbmc.org/index.php?title=HOW...on_Android

That begins with:........... Normally, you only need to use an external player if your Android device doesn't have a version of XBMC that works with hardware video decoding.

So it's just configuring XML and no code change involved...

Nice.... now why all the fuss of modding the build in player what is the catch here?
Because quite frankly the XBMC experience when using external players suck!


External players are not integrated into XBMC at all, so when using them you really notice when it launcher an external player and it break the XBMC experience.

It is a not a small compromise but a huge sacrifice and a major annoyance, it is just a dirty workaround for temporary short term use only, not a permanent solution.

Users that have poor experience with external player can give XBMC a bad reputation, and bad reputation, which will be bad for the project as less people will use XBMC which in turn mean less developers!

Also remember and understand that as long as there is a workaround then less developers will be motivated to work on a proper solution.

So it would therefore also be bad idea to try to improve the experience with external player in XBMC as it would only indirect serve to make it a worse product in the long term.


To summarize, just say no to external players! And just say no to duct tape programmers and say no to duct tape solutions!

As the saying goes; duct tape programmers are sacrificing tomorrow's productivity, today!


What is Apple made their first iPad the duct tape programer way?

Image

Old related joke: https://www.cs.cmu.edu/~mihaib/humor/told.jokes
Quote:How can I disable the modem whirring when a client dials in to OSR5? My computer is rack-mounted and will be placed in Telehouse so it should attract as little attebtion as possible to avoid being used as a coffee stand/pen holder.

Preferred Solution: Read the modem manual, find the codes to turn off the speaker and set them in the modem's NVRAM.
Alternate Solution: Rip all of the pages out of the manual and wrap them around the modem.

Hardware Solution: Open the modem with a screwdriver or can opener. Cut one wire going to the loudspeaker. Reassemble modem with remaining screws or duct tape (whichever is more convenient).

Software Solution: RTFM the printed manual and select several pages of technobabble to sacrifice. Rip out these pages and shove into the modem speaker. Wrap with duct tape.

Hacker Solution: Find ice pick. Stab speaker until dead. Note: This may void your warranty.

MSDOS/Windows Solution: It's a feature, not a bug. The noise is there for your own good. We know what's good for you. This feature will be fixed in the next release.

Kid's Solution: Position modem with speaker facing upward. Pour pancake syrup into speaker. This will greatly reduce the high frequency response of the speaker thus attenuating the sound.

Programmers Solution: Download the complete Rockwell command set from the modem manufacturer's site and use the bit mapped register functions to disable the speaker. Be sure that the warranty is still active as one mistake may also disable the modem.

Fast Solution: Take two needles, two clip leads and a 12volt battery. Observe that the leads of the speaker coil are visible through the grill where they are glued to the cone. Puncture these points with the needles and apply 12volts. The speaker coil will fuse open.
Reply
I have no preference for external player use in xbmc... so why the rant?
My post was incase the xbmc player fails on certain video formats.. then I would rather see a call to a external player than get a hacked version of an older xbmc release and lose my ability to upgrade...

And Yes like everybody else I prefer the internal xbmc player to handle everything.

But what would you prefer...when the manufacturer's player plays perfectly what the xbmc player can not?
Reply
(2014-10-02, 10:36)Willem55 Wrote: I have no preference for external player use in xbmc... so why the rant?

My post was incase the xbmc player fails on certain video formats.. then I would rather see a call to a external player than get a hacked version of an older xbmc release and lose my ability to upgrade...

And Yes like everybody else I prefer the internal xbmc player to handle everything.

But what would you prefer...when the manufacturer's player plays perfectly what the xbmc player can not?
Because what I am saying is that using an external player in XBMC is also a hack!

Both hacks are almost equally as bad for the XBMC project, as they are both workarounds specifically design to not use proper open source solution, no matter if you realise that or not.

By using either you discourage the developers to come up with a proper solution!

I prefer neither of them and say no to both!
Reply
This is getting religious..
Reply
  • 1
  • 18
  • 19
  • 20(current)
  • 21
  • 22
  • 37

Logout Mark Read Team Forum Stats Members Help
Rockchip RK3288 SoC based Android media players and XBMC experience?4