(2016-01-05, 17:55)hdmkv Wrote: [ -> ]Hmm, an external player w/Kodi controls overlayed on it should be regarded as an internal player? Deceitful to users it may be argued, but internal, doesn't seem so. As Zidoo and HiMedia are doing the same thing w/their RK3368 boxes, are they violating GPL by this line of reasoning as well? Not trying to argue here; just trying to find clarification.
No - an external player that looks like Kodi would not be violating GPL (though if it uses trademarked elements that might be a separate discussion to have). But it would have to be a properly external player, called by the hooks in Kodi to allow for external players AIUI.
If the player is incorporated into the Kodi app, and distributed within it, and not separate and external, then it isn't by definition, external.
I don't have a Vidon set-up - which is it? Separate player app - analogous to MPC-HC (*EDIT - previously mentioned DSPlayer which I hadn't realised was internal*) being called by Kodi under Windows, or a player internal to the Kodi app, but separate to the current Kodi code base and replacing the current Kodi player. If it is that, then as GPL it should be open sourced AIUI.
(2016-01-05, 18:12)noggin Wrote: [ -> ]If the player is incorporated into the Kodi app, and distributed within it, and not separate and external, then it isn't by definition, external.
You've hit on the key question... within the VidOn APK, is there an embedded video player (making it an internal solution), or is the VidOn app calling the AML player via an API (external solution)? I think Wolly was saying it was the latter.
(2016-01-05, 18:22)hdmkv Wrote: [ -> ] (2016-01-05, 18:12)noggin Wrote: [ -> ]If the player is incorporated into the Kodi app, and distributed within it, and not separate and external, then it isn't by definition, external.
You've hit on the key question... within the VidOn APK, is there an embedded video player (making it an internal solution), or is the VidOn app calling the AML player via an API (external solution)? I think Wolly was saying it was the latter.
If the latter then that should be clear from the source code within Kodi that they will presumably have to modify to access via the API rather than by running an external app per se ? If that is the case that source code mod should be released as it is within Kodi?
If it's being done via an external player application (as is the case with some Windows solutions - like 3D Blu-ray playback) shouldn't the details for that be in advancedsettings.xml or similar within the APK?
Is the AML Player a separate Android app ?
Or am I missing something?
Yes, I believe so as when I just use a file manager and play videos on a S812 and S905 box I have, they play in a generic-looking video player app. But don't know if this type of native video player app is what VidOn is actually calling into their Kodi fork.
when i open vidon xbmc on a s8xx box there is an option in the menu Vidon and in that menu there is an option to use Vidon Player core or something in those words. when playing a video its is seamlessly integrated when you hit "o" it brings up codec information but in a different font so you know its not the default internal player.. there is no seperate apk and if i bring up the quick app switch thingy in android theres only kodi open no other apps, now obviously this doesnt mean much i guess but i can do any tests you want if you tell me what to do.
This is the VidOn 14.2.1 Playercorefactory.xml
Quote:<?xml version="1.0" encoding="UTF-8"?>
<playercorefactory>
<players>
<!-- These are compiled-in as re-ordering them would break scripts
The following aliases may also be used:
audiodefaultplayer, videodefaultplayer, videodefaultdvdplayer
<player name="DVDPlayer" audio="true" video="true" />
<player name="DVDPlayer" /> placeholder for MPlayer
<player name="PAPlayer" audio="true" />
-->
</players>
<rules name="system rules">
<rule name="rtv" protocols="rtv" player="DVDPlayer" />
<rule name="hdhomerun/myth/mms/udp" protocols="hdhomerun|myth|cmyth|mms|mmsh|udp" player="DVDPlayer" />
<rule name="lastfm/shout" protocols="lastfm|shout" player="PAPlayer" />
<rule name="rtmp" protocols="rtmp" player="videodefaultplayer" />
<!-- dvdplayer can play standard rtsp streams -->
<rule name="rtsp" protocols="rtsp" filetypes="!(rm|ra)" player="PAPlayer" />
<!-- Internet streams -->
<rule name="streams" internetstream="true">
<rule name="aacp/sdp" mimetypes="audio/aacp|application/sdp" player="DVDPlayer" />
<rule name="mp2" mimetypes="application/octet-stream" filetypes="mp2" player="PAPlayer" />
</rule>
<!-- DVDs -->
<rule name="dvd" dvd="true" player="DVDPlayer" />
<rule name="dvdimage" dvdimage="true" player="DVDPlayer" />
<!-- Only dvdplayer can handle these normally -->
<rule name="sdp/asf" filetypes="sdp|asf" player="DVDPlayer" />
<!-- Pass these to dvdplayer as we do not know if they are audio or video -->
<rule name="nsv" filetypes="nsv" player="DVDPlayer" />
<!-- pvr radio channels should be played by dvdplayer because they need buffering -->
<rule name="radio" filetypes="pvr" filename=".*/radio/.*" player="DVDPlayer" />
</rules>
</playercorefactory>
(2016-01-05, 18:12)noggin Wrote: [ -> ]Separate player app - analogous to DSPlayer being called by Kodi under Windows, or a player internal to the Kodi app, but separate to the current Kodi code base and replacing the current Kodi player. If it is that, then as GPL it should be open sourced AIUI.
If you by DSPlayer is referring to this
http://forum.kodi.tv/showthread.php?tid=223175 then that is a very bad example because that DSPlayer is actually an "internal player" for Kodi, as DSPlayer is as native Kodi player core as DVDPlayer or PAPlayer. See
https://github.com/aracnoz/xbmc/tree/mas...s/DSPlayer
Better "external player" examples are MPC-HC on PC or MXPlayer on Android. See
http://kodi.wiki/view/External_players and
http://kodi.wiki/view/HOW-TO:Use_externa...on_Android
As per these examples the full source code of DSPlayer must be released under a GPL compatible license but MPC-HC and MXPlayer can be closed source.
(2016-01-05, 18:38)dukester Wrote: [ -> ]when i open vidon xbmc on a s8xx box there is an option in the menu Vidon and in that menu there is an option to use Vidon Player core or something in those words. when playing a video its is seamlessly integrated when you hit "o" it brings up codec information but in a different font so you know its not the default internal player.. there is no seperate apk and if i bring up the quick app switch thingy in android theres only kodi open no other apps, now obviously this doesnt mean much i guess but i can do any tests you want if you tell me what to do.
That and the playercorefactory file shows an native "internal player" runs inside Kodi so by definition not an "external player" running as an separate process.
Quote:<rule name="dvdimage" dvdimage="true" player="DVDPlayer" />
I believe this applies to a Blu-ray image file (ISO) as well, so is it using a re-engineered DVDPlayer (vs. Kodi's) or is it calling the Kodi dvdplayer only to use it as a wrapper & 3D playback is actually being done by another player being called into the wrapper? We may never find out how VidOn is really doing it as it may be in their secret API. Maybe doesn't matter as results seem so spotty (sometime full 3D output, other times top/bottom, can't have HD audio + 23.976 at the same time, AVR/display compatibility issues, etc.).
(2016-01-05, 19:00)hdmkv Wrote: [ -> ]Quote:<rule name="dvdimage" dvdimage="true" player="DVDPlayer" />
I believe this applies to a Blu-ray image file (ISO) as well, so is it using a re-engineered DVDPlayer (vs. Kodi's) or is it calling the Kodi dvdplayer only to use it as a wrapper & 3D playback is actually being done by another player being called into the wrapper? We may never find out how VidOn is really doing it as it may be in their secret API.
It doesn't matter if they use re-engineered DVDPlayer code or if they have written every single line of code in their own player core.
Because they run it as a native "internal player" core inside Kodi it makes makes it combined work based on the GPL covered work.
Please read the GPL FAQ highlighted points like
http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic and
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL as well as open source philosophical points like
http://www.gnu.org/licenses/gpl-faq.html#SwitchToLGPL
(2016-01-05, 19:00)hdmkv Wrote: [ -> ]We may never find out how VidOn is really doing it as it may be in their secret API. Maybe doesn't matter as results seem so spotty (sometime full 3D output, other times top/bottom, can't have HD audio + 23.976 at the same time, AVR/display compatibility issues, etc.).
I was always under the mistaken impression that combo was a 32bit S8xx limitation this HD Audio + 23.976fps.
Now I'm not so sure this is the case at all.
So you are saying this limitation still occurs when using VidOn XBMC on a new 64bit S905 ?
If we leave the legalities aside for one moment ultimately this boils down to an issue of trust, do you trust VidOn to deliver on the features stated in their marketing material without being crippled by major limitations or are they just another Asian seller that is all hot air with no substance ?
From what hdmkv is telling us there appears to be some major limitations.
And if that is the case even on the new AMLogic S9xx hardware, I would trust a 23.976fps 3D and HD Audio solution coming from Kodi Open Source code from Koying and Popcornmix and others than a convoluted closed shop VidOn XBMC environment.
I've been neck deep in this Open Source Kodi AMLogic 3D code all day now.
(2016-01-05, 19:11)RockerC Wrote: [ -> ] (2016-01-05, 19:00)hdmkv Wrote: [ -> ]Quote:<rule name="dvdimage" dvdimage="true" player="DVDPlayer" />
I believe this applies to a Blu-ray image file (ISO) as well, so is it using a re-engineered DVDPlayer (vs. Kodi's) or is it calling the Kodi dvdplayer only to use it as a wrapper & 3D playback is actually being done by another player being called into the wrapper? We may never find out how VidOn is really doing it as it may be in their secret API.
It doesn't matter if they use re-engineered DVDPlayer code or if they have written every single line of code in their own player core.
Because they run it as a native "internal player" core inside Kodi it makes makes it combined work based on the GPL covered work.
Please read the GPL FAQ highlighted points like http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic and http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL as well as open source philosophical points like http://www.gnu.org/licenses/gpl-faq.html#SwitchToLGPL
I've registered here to support your statement.
This morning i read all this thread and i was surprised to see that no ones posted about how GPL works in this case.
I've not tried VidOn yet but as long as the things i read here are true i'm pretty sure they can't call this an external player.
We have:
- A single APK with Kodi and their "external" player
- A single process with Kodi and they "external" player
- You cannot see the "external" player in the task manager
etc..etc..etc..
If these are true things this is an "INTERNAL" player and they MUST share its source code.
(Even if they wrote it from scratch..)
This is the Kodi license. If they want to use Kodi in this way the must follow the license.
I'm not an expert of licenses but it isn't difficult to understand basic principles of GPL.
(2016-01-05, 18:51)RockerC Wrote: [ -> ] (2016-01-05, 18:12)noggin Wrote: [ -> ]Separate player app - analogous to DSPlayer being called by Kodi under Windows, or a player internal to the Kodi app, but separate to the current Kodi code base and replacing the current Kodi player. If it is that, then as GPL it should be open sourced AIUI.
If you by DSPlayer is referring to this http://forum.kodi.tv/showthread.php?tid=223175 then that is a very bad example because that DSPlayer is actually an "internal player" for Kodi, as DSPlayer is as native Kodi player core as DVDPlayer or PAPlayer. See https://github.com/aracnoz/xbmc/tree/mas...s/DSPlayer
Better "external player" examples are MPC-HC on PC or MXPlayer on Android. See http://kodi.wiki/view/External_players and http://kodi.wiki/view/HOW-TO:Use_externa...on_Android
As per these examples the full source code of DSPlayer must be released under a GPL compatible license but MPC-HC and MXPlayer can be closed source.
Yep - my bad. Edited my original post (with an acknowledgement) For some reason I thought DSPlayer was like MPC-HC.
Quote: (2016-01-05, 18:38)dukester Wrote: [ -> ]when i open vidon xbmc on a s8xx box there is an option in the menu Vidon and in that menu there is an option to use Vidon Player core or something in those words. when playing a video its is seamlessly integrated when you hit "o" it brings up codec information but in a different font so you know its not the default internal player.. there is no seperate apk and if i bring up the quick app switch thingy in android theres only kodi open no other apps, now obviously this doesnt mean much i guess but i can do any tests you want if you tell me what to do.
That and the playercorefactory file shows an native "internal player" runs inside Kodi so by definition not an "external player" running as an separate process.
Just thinking out loud - could the Vidon player be implemented as a binary add-on? Or do we just think they've forked the Kodi player, and are tweaking the OSD for the forked codec support so it 'looks' like an external player when it isn't?
VidOn's solution worked best under their own Allwinner A31s box... first to provide 3D output & HD audio via Kodi. Support for 23.976 never came, and other lingering issues unresolved, with one sort of issue or another with their different XBMC builds. Box is no longer sold and there's barely any support. VidOn moved to a software only provider for Minix, Tronsmart, etc. Reading posts @ Minix, Tronsmart and VidOn's forums, 3D and HD audio functionality appears to vary by device and builds, and some of those original VidOn box issues persist.
So, trust? No. But, is what they're doing (or trying to) interesting? Yes. Maybe VidOn should focus more narrowly on Minix or maybe develop their own next-gen box, and focus on key issues on a particular build before spreading themselves too thinly. Or like you said wrxtasy, forget this convoluted/closed API solution, and go open so there's development contribution from everyone and better chance of success.
From VidOn log, it appeared to me that it is calling some external libraries *.so for playback. This is how it is done on Xidoo X6. It calls some rk library. I will post the log when I get a chance to remote to my home PC.
