[vlc-devel] Q: handling an experimental version

[Rémi Denis-Courmont]

   Hello,

On Tue, 05 Oct 2010 11:23:15 +0200, Riccardo Bernardini
<riccardo.bernardini at uniud.it> wrote:
> The first pre-release of our software is almost ready and we would
> like to interface it with VLC.  We would do this both for testing our
> software (and this would not be a problem), but also we would like to
> make available our "experimental" version, so to have some feedback
> about it.  Since we do not want to pollute the VLC source with our
> experimental code, I would like to ask you suggestions on how to
> handle this "experimental branch."  We would like, if possible, to
> keep it synchronized with the main development branch.

There are basically only two ways to keep compiled code in sync with the
VLC master tree:
 - provide separate plug-ins, or
 - maintain your own fork of VLC.

Either way, you're going to need to replicate the build infrastructure for
each host platforms that you are interested in.

> I know that VLC has modules, but I do not think that our code could be
> included by adding a new module.   Let me briefly explain the changes
> we plan to apply
> 
>    * The first change will be in the SDP parsing part.  SDP will be
> adapted to our protocol by defining a new transport protocol (we are
> working to have this published by IETF).  Say that instead of having
> "RTP/AVP" on the media (m=) line you have something like
> "RTP/AVP/Coolest-protocol-ever" :-).
> 
>    * The SDP parser will recognize the new transport protocol and will
> call a suitable function to open the connection.

There are currently two independent paths whereby SDP are parsed within
VLC:
SDP with a single RTP session (only one m-line) and a static RTP payload
format are parsed by the SAP plugin. This simply converts the SDP into a
VLC media location, typically "rtp://SRC_IP@DST_IP:DST_PORT". SDP with more
than one m-line or dynamic RTP payload formats are parsed by the live555
library through the RTSP/live555 plugin.

>    * The called function will do a lot of works internally and it will
> return an integer value that represents an UDP socket.

> Maybe the part that opens the connection and returns an UDP socket
> could be coded as a module, but I am afraid that the new transport
> protocol could not be added to the SDP parser with an additional
> module and that we will need to modify directly the SDP module.  Maybe
> a second, alternative SDP module?  I do not know...

You can write your own SDP parser, so long as it falls back to live555 by
default. Unfortunately, you would need to parse the whole SDP, including
any would-be codec parameter. You would also need to re-implement (or copy)
the RTP profile and any relevant RTP payload format.

> Any suggestions?

I wish VLC would have a nicely layered RTP/SDP stack, but it does not. I
realistically won't have time to write one in the foreseeable future, and I
cannot promise it on behalf of someone else.

> Thank you
> 
> Riccardo
> 
> PS: By the way, if you want to "absorb" our code in the main branch,
> we have no objection to it; however, I think that it would be better
> to wait for a more stable version of our software.

Agreeably so.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis