[vlc-devel] VLC RTSP Server Support for Keep-Alive Messages to Kill Orphaned Streams?

[Robert Krakora]

2009/7/16 Rémi Denis-Courmont <remi at remlab.net>:
>
> On Wed, 15 Jul 2009 17:21:52 -0400, Robert Krakora
> <rob.krakora at messagenetsystems.com> wrote:
>> When I build VLC I specify a path to the latest Live RTSP source that
>> I have on my system.  I was under the assumption that VLC would
>> utilize both Live's RTSP server and client instead of those resident
>> in the VLC source.  However, it looks like this is only true in the
>> case of the RTSP client.  The Live RTSP server already employs the
>> RTSP "keep-alive" implementation that you proposed via most recent
>> RTSP request and RTCP-RR.  How hard would it be to modify VLC to
>> utilize both the current RTSP server in the VLC source or the Live
>> RTSP server?
>
> Live555 is not thread-safe, provides no event handling, lacks IPv6, DCCP
> and a bunch of payload types that VLC supports.
> We should not even be using it on the client IMHO.
>
> --
> Rémi Denis-Courmont
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
>

Remi:

You are correct that the live555 RTSP server does not support DCCP and
possibly some other payload types that VLC's RTSP server does.
However, without trying to be argumentative ;-) may I point out that I
have used both the live555 RTSP Server and RTSP Client in the past in
a satellite IP gateway server for IP-based set-top boxes and I can
tell you that both are event driven and can be used in multi-threaded
applications if utilized as described below.  Also,the live555
developers are open to supporting additional payload types if the
demand is there.  The best thing about the live555 implementation is
that it is highly portable supporting many operating systems.

>From http://www.live555.com/liveMedia/faq.html:

Is this code 'thread safe'? I.e., can it be accessed by more than one
thread at the same time?
Short answer: No. As noted above, the code assumes a single thread of
execution, using an event loop - rather than multiple threads - for
concurrency. This generally makes the code much easier to debug, and
much easier to port across multiple operating systems, which may have
different thread APIs, or no thread support at all. (For even stronger
arguments along these same lines, see John Ousterhout's presentation.)

Longer answer: More than one thread can still use this code, if only
one thread runs the library code proper, and the other thread(s)
communicate with the library only by setting global 'flag' variables.
(For one possible use of this technique, see the answer to this
question.)

Another possible way to access the code from multiple threads is to
have each thread use its own "UsageEnvironment" and "TaskScheduler"
objects, and thus its own event loop. The objects created by each
thread (i.e., using its own "UsageEnvironment") must not interact
(except via global variables).

However, when using the "LIVE555 Streaming Media" code, you should be
familiar with event-driven programming, and understand that an
event-driven application can perform at least as well as one that uses
threads (unless you're actually running on a multiprocessor, in which
case it's usually simpler to have your application consist of multiple
processes (not just threads) - one running on each processor). Note,
in particular, that you do not need multiple threads in order to
transmit (or receive) multiple streams concurrently.

I tried to play a "rtsp://" URL (using VLC, MPlayer or openRTSP), or a
"sip:" URL (using playSIP), but I got an error message "RTP payload
format unknown or not supported". Why?
The problem here is that the "liveMedia" library does not support the
"RTP payload format" that is used to stream data with this particular
codec.

An "RTP payload format" for a codec is a set of rules that define how
the codec's media frames are packed within RTP packets. This is
usually defined by an IETF RFC, or - for newer payload formats - an
IETF Internet-Draft. However, a few RTP payload formats (usually those
whose MIME subtype begins with "X-") are proprietary, are not defined
in publically-available documents.

The "liveMedia" library supports many, but not all, RTP payload
formats. If you encounter a RTP payload format that is not supported,
but which is defined by a publically-available document, then we may
be able to add support for it, if there is sufficient interest.

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax