Kodi Community Forum

Full Version: Project discussion: "NVIDIA Gamestream in Kodi"
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hello!

I'm intrested in this project, and I compiled XBMC and works like a charm.
Right now I am trying to get familiar with the code.

In the meantime, can you give me some more details about the project?
What are your thoughts about this feature?

For example, this would be an addon, or this will be a core feature?


Gazben
(2015-03-05, 17:51)gazben Wrote: [ -> ]For example, this would be an addon, or this will be a core feature?
Limelight or a other implementations for game streaming could maybe be made as a "game addon" for RetroPlayer with Garbear as mentor?

http://forum.kodi.tv/showthread.php?tid=164725
(2013-02-14, 19:48)garbear Wrote: [ -> ]
  • RetroPlayer: Player core that plays games using game add-ons. Despite its name, it can play all types of games, not just retro ones. Games can be paused, fast-forwarded, and rewound in realtime. Save states are created similar to bookmarks, allowing for quick browsing of the game's play history. 3D support (for N64, etc) is being worked on.
  • Game Add-ons: Standalone games, emulators, NVidia GameStream via Limelight. and WINE capture are possible through the Game API. The Game API has 1:1 compatibility with the libretro API, so all libretro cores are valid game add-ons.
More about the RetroPlayer concept here: http://forum.kodi.tv/forumdisplay.php?fid=194

Source code for Kodi game addons (and game peripheral addons): https://github.com/kodi-game

I don't know, there might be other open source alternatives to Limelight out there?: http://forum.kodi.tv/showthread.php?tid=211150
Hi gazben,

PVR add-ons are probably the closest analogy to a GameStream add-on. It bridges the gap between a GameStream backend and Kodi, interfacing with the new Game API I created for games in my RetroPlayer branch of xbmc at https://github.com/garbear/xbmc . The add-on will eventually be hosted at https://github.com/kodi-game and probably distributed with the app like PVR add-ons.

The project itself won't be too hard, as there's already an implementation of GameStream in Java. However, some changes in RetroPlayer might be necessary, so you'd be working with parts of Kpodi as well.

I'd recommend compiling the RetroPlayer branch and giving that a try, but it still needs some bug fixes before it's fully functional. The build system for binary add-ons was redone and I've been working on adapting Game add-ons to the new system, but I'm not quite done yet.
Limelight and steam both end up duplicating some of retro players work with input. While lime light is open source and fantastic (and I already use, love, and rep the crap out of it to all my gamer friends) . . . it's definitely the friendly choice

In the long run Steam might be the better project since there is a quasi-multi-platform java implementation of steam as well, and I'm not really sure whether or not binary addons help this or not. The drawback to steam is the check for update at each launch and passing along login info as well as the extras it wants to install if you run it standalone (letting it install games). However as a steam-client it's big benefit is that both Nvidia's NVENC and AMDs similar hardware encoder are supported on the server side whereas lime light only supports nvidia and windows as a server

Since I run a windows server with an nvidia graphics card, either way works for me and either one would be awesome

I think limelight progresses a little faster at adding any nvenc optimizations since it runs right over the nvidia geforce experience software which requires itself to be up to date for it to work
Limelight client code is Java (not a good match for Kodi), and its code is all licensed under GPLv3, doesn't that cause a license compatibility issue with binary PVR/Game addons for Kodi?
https://github.com/limelight-stream/limelight-pc

There are several other C/C++ open source projects that are alternatives to Limelight which have similar compatible game streaming clients, not sure if any of their core concepts or even source code could be reused for this though? Anyway, other examples of free and open source open source projects that I found which offer Cloud Gaming / Game Streaming OBS (Open Broadcaster Software) and GamingAnywhere. And I'm guessing that these would probably make a better reference game addon for streaming in Kodi if your looking to go the way of PVR binary addons for this project.

OBS (Open Broadcaster Software) is a GPLv2 project written in C++, offer GPU-based game capture for high performance game streaming to video, compatible with both Intel Quick Sync Video (QSV) and NVENC hardware encoding from the server-side.
https://obsproject.com
https://github.com/jp9000/OBS

GamingAnywhere also looks very promising at first glance, though I understand that it focus mainly on internet cloud streaming rather than local network streaming, and I don't think that it's compatible with Nvidia's GameStream protocol. GamingAnywhere it's otherwise written in C++ too and its client is BSD three-clause form licensed which I believe is compatible with GPL? If so it might still be interesting for those with AMD graphics.
http://gaminganywhere.org
https://github.com/chunying/gaminganywhere

Again, for those who don't know, the basic idea here regardless of client type is that you have a much more powerful computer on your local network (on possibly even on the internet) with very fast CPU/GPU which acts as the server-side which actually does all or most of grunt work which is to run the game engine and render the graphics, and then you basically just try to do low-latency streaming over the network as a captured video stream with quick hardware encoding on the server-side and a low-latency decoder/player on the client-side. Alternatively you can go a other way and just do partial pre-processing on the server-side and then actually stream the game data and finish part of the rendering on the target machine, the latter one obviously if much harder to achieve.
gpl v3 is compatible with v2, but not the other way around. it just makes the whole thing gplv3 (which it should have been in the first place imo!)
(2015-03-06, 13:06)ironic_monkey Wrote: [ -> ]gpl v3 is compatible with v2, but not the other way around. it just makes the whole thing gplv3 (which it should have been in the first place imo!)
Does that mean that if they add a GPLv3 licensed binary addon for a PVR/Game client to Kodi's official repository it makes the whole application with that addon to be bound by GPLv3?

Sorry if too off-topic, don't mean to highjack thread thread, was trying to understand if an API for binary client addons also abstract the license similar to using external MySQL database. These license limitations to binary addon would be interesting to know in regards to using binary client addons that have different propitiatory licenses or are maybe even closed sourced.
So many links, and alternatives. Thanks Smile

@garbear: I compiled the retroplayer branch and it stars up. So I have to download an emulator for the right system, and then I can play? Can we contact some emulator developers for auto download?
Do you have a bug tracker for this project? I would like to fix a bug or two, just to get familiar with the code.

@Hedda: I haven't thought about the licence of the tools, and to be honest I don't have experience with them.
To me, Limelight is the best choice, becouse it can do everithing we need.
GamingAnywhere: It has a different approach to the "problem" but looks very promising.
OBS: I don't think it's the tool we need, but if can can come up with a solution to send the controller/keyboard data to the server it could work really well.
ironic_monkey is right that if any part of GPL2 code has a GPL3 library in it, the entire GPL2 code is treated like GPL3. It isn't relicensed though. XBMC has used GPL3 libraries in the past, but we shifted away from that with the XBMC for Android port specifically because hardware vendors really hate GPL3. ironic_monkey is honestly correct that GPL3 is better and, frankly, hardware providers shouldn't be too worried about using it unless they're planning on doing with Kodi code what the Boxee Box did, but that's a separate discussion.

With that said, because the aim of this project is a binary addon, that somewhat doesn't matter. Hardware vendors really set on locking down Kodi so that users can't change the code (aka tivo-izing it), can simply not offer this binary addon. Users could still sideload it if they wanted, but vendors aren't obligated to abide by a GPL3 license for software that they didn't offer themselves.

Whether simply including the addon in a repo counts as offering the GPL3 software to the point where it taints the GPL2 software is a really interesting legal question that I certainly don't know the answer to. I'd guess no, but the second the user installed the GPL3 software from the vendor's repo, the GPL2 software would be tainted.

This is all probably pretty unlikely to ever be an issue again though. Since the Boxee Box, tivo-ization of the entire XBMC/Kodi codebase hasn't happened. It's way easier to lock down Android or similar set-top box software, and then simply install regular Kodi on top of that.

I'm still hesitant to include any GPL3 code inside the codebase itself, but offering a binary addon seems like a pretty reasonable middle ground.
(2015-03-06, 17:08)natethomas Wrote: [ -> ]Whether simply including the addon in a repo counts as offering the GPL3 software to the point where it taints the GPL2 software is a really interesting legal question that I certainly don't know the answer to. I'd guess no, but the second the user installed the GPL3 software from the vendor's repo, the GPL2 software would be tainted.

There are a bit of a discussion on if this is true, I haven't' really read the verdict on it (or if there exist one) but personally it feels weird if it would cross the border if its dynamically linked. Some even argue that gpl servers taint clients, i.e. taints cross network Smile

I have a hard time believing that would be an issue, but would love it if someone know of a verdict which clearly states if it is an issue.
Limelight client code iswritten in Java?! Uck! Suggest to stay away from that if its going to be for Kodi and instead try to find an alternative client code written in C++ or C.

Does Kodi even support binary addons written in Java right now? Again, there must be other GameStream client alternatives or Limelight ports out there that are not written in Java?

Quick search and it looks like Limelight at least have a C implementation of the actual GameStream protocol

https://github.com/limelight-stream/limelight-common-c

Otherwise you could have a whole project that might end up being mostly porting the Limelight client code to C++ or C.
(2015-03-06, 13:06)ironic_monkey Wrote: [ -> ]gpl v3 is compatible with v2, but not the other way around. it just makes the whole thing gplv3 (which it should have been in the first place imo!)

only if GPLv2+(or any later version), which kodi is in all license headers I checked, but strangely not in the main https://github.com/xbmc/xbmc/blob/master/LICENSE.GPL#L2
gazben, as we start thinking about possible projects, do you think you could give a brief background of your coding history? Assuming this project is done as a binary addon, that may require some skill in c++, java, and python.
I was also interested in this project and have been taking a look at this in the last week. The language of the official Limelight client doesn't matter too much, since all the code would have to be ported over to use Kodi's interfaces anyways. The actual GameStream protocol has an implementation in C for their iOS and Windows phone projects as mentioned by RockerC, so I believe the majority of the work will be creating the client addon for Kodi.
@natethomas: Of course Smile
I started programming 3 years ago when I started the university (Budapest University of Technology and Economics - http://www.bme.hu/?language=en).

I studied C/C++/Java, I started Python recently. My favourite language is C++ especially the new '11 standard.
I worked for Unify Communications Inc. as a part of the Xpert project, as a C++ developer, but I quit about a month ago, because I wanted to focus on my studies. I also teach C++ to students in the university.
My Github account: https://github.com/gazben

My favourite project is TraceDemon, a ray tracer engine I wrote for a student programming conference: https://github.com/gazben/TraceDemon

I can get more reference from my professors and my former employer.

@RockerC: I think my project would be: Study the Limelight C implementation. Port the Java code to C++ (if I can contact the developer of the project, I don't think this will be an issue). the porting has to be done in Kodi's framework to not add more overhead. Add the code to the retroplayer as an addon.
This idea misses all of the licence problems above, of course if we come up with another solution, and we have to add it as a binary addon. The binary addon solution would be much slower because of Java I think.
Pages: 1 2