[vlc-devel] GSoC application (UPnP A/V integration)

Rafaël Carré funman at videolan.org
Tue Mar 18 18:48:56 CET 2008


On Tue, 2008-03-18 at 02:57 +0100, Mirsal Ennaime wrote:
> Hello,

Hi

> I would like to apply as a student for this year's summer of code.

Don't we all (would like) ? :)

> I picked up the "UPnP media service" idea, as it's the most appealing
> one regarding my skills and knowledge. However, the wiki paragraph is
> quite vague, so I'll try to precise my project a bit more:
> 
> VLC, as a quite featureful application, could take multiple roles in a
> UPnP network:
> As a media server, it could expose its playlist / media-library to UPnP
> devices that are present on the network and send media on demand.
> As a media renderer, it could play media exposed by other UPnP media
> servers and be remote-controlled over the network.
> And finally, as a control point, it could control playback happening on
> remote devices.

VLC has already some UPnP capabilities, more or less broken, since more
or less time.

Did you check these features already ?
Did you check the code ?
If yes, did you estimate the time for updating these plugins instead of
writing a brand new plugin ?

> For this to work VLC needs to implement a stack of "UPnP-standard"
> protocols that permit device and service discovery, remote control and
> media "streaming"
> 
> There are two possible ways to achieve this:
> 
> - Using the coherence framework [1] (Like the GNOME music player
> rhythmbox did) so VLC can have a full working UPnP stack rather quickly 
> (Pros: No wheel reinvention. Much easier to write and maintain. Cons:
> It's yet another dependency. It's python, not C)

There is yet another concern : speed.
I know python is a mature language, but it still is a script language.
Do you plan to do any measurement against a C version of some
functionality ?

> - Implementing all the protocols inside VLC, so they can be used outside
> the scope of UPnP A/V. However, this would be much harder and only a
> subset of the above-mentioned features would be ready at the end of the
> SoC.
> (Pros: Reusable code inside VLC. Could be done in C. Cons: Much more
> work to write and maintain the code)
> 
> I can handle both approaches and I'm beginning to become familiar with
> the VLC codebase thanks to my work on the dbus control module.

Do you have a personal preference for one of these options ?

> [1] https://coherence.beebits.net/
> 
> Regards,

Thanks

-- 
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080318/09d0d7c6/attachment.sig>


More information about the vlc-devel mailing list