Kodi Community Forum

Full Version: GSoC Proposal : Wireless Media Stream Functionality
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

The realm of public media sharing is a domain which is still in its infancy, and the landscape of which can be set for future developments by the implementation of
this application. Public joints nowadays, usually tend to have their own wireless networks having an open key. In most cases, the system handling the wireless network of the place, is also used to broadcast media content over the speakers and TV screens installed in the joint.

This project aims at exploiting such wireless networks present at the public joints to allow the users to share their media content over the public system , which
shall be handled by the XBMC software running on the server system.
The application will allow media streaming both ways (Server to Client and Client to Server). Multiple clients trying to connect to the server shall be placed on a queue chronologically. Users will be required to have the XBMC client app on their handheld device to be able to utilise this feature.

The development of this application as a separate module of the XBMC application will allow specialized upgrades for this module to be developed in a much cleaner and efficient fashion.

How will I achieve this -

Being accustomed to .NET technologies, I will be using the Visual Studio 2012 Professional IDE with C# language for programming the server side and the Windows phone client application. Also, I have previously worked on Microsoft Expression Blend, which I shall be utilising to enhance the UI of the application.
The main server side application will be composed of a front-end Windows Forms App and a back-end Console-based shell application. Also, I will be utilising the Eclipse IDE for developing the client application for the Android platform. I have experience working on Android and Java application development as I have made a message encrypter/decrypter android application last year and a MySQL interfaced Java based Library Database Management application as my High School Practical Project.

The Console based shell will be handling the backend communications with the XBMC software and shall be communicating with the front-end Windows forms application. This shall provide abstraction to the front-end design from the back-end technicalities, allowing a more modular, clean design.

For the interfacing part, I will be exploiting the JSON-RPC API to make the application communicate with the XBMC software.


The goals involve the following modules-
2.Back-end shell development to handle communications with the XBMC software and the front-end application
3.Development of necessary APIs to be used to interface the front-end application with the Back-end shell. It has to be ensured that the API design is not specialized
to this front-end application.
4.Development of Windows-Phone XBMC streaming client application.
5.Development of Android XBMC streaming client application.

I would really appreciate feedback from team XBMC members about this project, especially about the following things-
1.) Will JSON API be the best choice for my application, or is there any better method?
2.)Is the idea of designing a shell for handling the backend and a separate Application for front-end a good idea?

Any mentors viewing this application may please contact me!!
email - [email protected]
I'd stick to one client for the project for example android.
In general we, as a team, don't want to pursue non-cross platform solutions. The remotes are an obvious contradiction to this rule though. But for a server part to ever be accepted it would need to be cross platform, atleast to get my vote.

C# is somewhat cross platform but I'd stay real clear from forms, as thats far from cross platform. They work somewhat in mono afaik but could be removed at any time.

Besides, I don't see the benefit of adding this as an external daemon, why not add the server parts within xbmc?

And define streaming, what is it xbmc cannot do which you want to amend. Because xbmc can perfectly well serve streamable formats, and this merge window will, afaik, pull in streamable and seekable serve for the http server. And xbmc excels in stream playback.
I thought of integrating the server functionality into the XBMC directly earlier. But wouldn't that compromise the realm for further developments involving live-time streaming of data elements to XBMC?

Moreover, if this is developed separately, users not owning a wireless network will have the option not to install this external tool.

Okay, so I think building the back-end shell functionality into the XBMC software will be a good idea?
So then, different front-end apps can easily be developed for different platforms, while preserving the abstraction from the back-end technicalities.

Streaming basically refers to serial transmission of raw bitstreams, which if coming from a video or audio file(determined by the server back-end) will be played back accordingly. Moreover, this application can further be developed to handle the streaming of not only media content but other things like documents too, as the input stream handler will be dealing with raw data.