[vlc-devel] Q: handling an experimental version

[Rémi Denis-Courmont]

Le lundi 11 octobre 2010 17:53:29 Riccardo Bernardini, vous avez écrit :
> Thank you for your replies.  Let me ask a couple of more questions.
> 
> Quoting Rémi Denis-Courmont <remi at remlab.net>:
> 
> 
> (skipped)
> 
> > 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.
> 
> This is just a curiosity: why this "two paths" structure?

First, I believe the native path predates the live555 plugin, so it's just 
there. Second, live555 comes with quite many problems of its own, so if we can 
avoid using it, we do.

> > 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.
> 
> This question is related to the previous one: why must I fall back to
> the live555 if I rewrite my own parser?

Otherwise you will break existing use cases that your plugin does not handle. 
I assume your plugin would only handle your specific RTP profile as specified 
in the m-lines.

> Could deriving from the SDP
> parser in live555 be easier?

I don't know if live555 supports parsing SDP in a generic manner without 
automatically starting the stream. I also doubt that live555 accepts unknown 
tokens in the SDP.

> Hmmm... What kind of "interface" should this stack have?

Ideally, we'd have a generic SDP parser that would be able to connect 
arbitrary combination of SDP media transports, RTP profiles and RTP payload 
formats - each implement with a different plugin type and set of plugins.

That's a lot of work though.

> What kind of
> "services" is expected to provide?  I'm not promising anything, but if
> the additional work is not excessive, we could try to write a new
> RTP/SDP stack (reusing as much as possible [but not more] the existing
> code, of course).  Maybe the new stack could make our work easier, if
> we can find a way to add our experimental code as a pluggable module.
> Where can we find more information about this or, at least, what are
> the source files involved?
> 
> Thank you for your help.
> 
> Riccardo


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