[Live-devel] [vlc] RTSP client in vlc 2.1

[Gilles Chanteperdrix]

On 12/14/2013 11:43 AM, Ross Finlayson wrote:
>> Problem 1: sub-titles streaming.
>> 
>> When playing the following URL: 
>> rtsp://xenomai.org:8554/video-tests/hd-fast.mp4
>> 
>> The playback works nicely, but when enabling a sub-title track,
>> the playback suddenly stops. After inspection of the RTSP dialog,
>> here is what happens. When starting playback, vlc sends a SETUP for
>> every track, then sends a global PLAY. When the user selects a
>> sub-title track, it sends a TEARDOWN for every sub-title track,
>> then a SETUP only for the selected track. At this point live555
>> (which is what I use for the RTSP server) refuses to setup the
>> track and returns a 404 error, which causes vlc to stop playback.
> 
> Gilles,
> 
> The real problem here seems to be that the LIVE555 code (which you're
> using as your server) is behaving unexpectedly.  Because of this, the
> best place to discuss this problem is the
> "live-devel at lists.live555.com" mailing list (see
> <http://www.live555.com/liveMedia/faq.html#mailing-list-address> for
> more information) - rather than a VLC mailing list.
> 
> If there's a problem with the LIVE555 server code, then the proper
> solution would be for us (Live Networks, Inc. - the developer of that
> code) to fix that code, rather than asking VLC to change its
> behavior.

Ok, following up on live555 mailing list.

Well, I know how to "fix" this in live555 code:
diff --git a/liveMedia/RTSPServer.cpp b/liveMedia/RTSPServer.cpp
index 693df25..5cebc04 100644
--- a/liveMedia/RTSPServer.cpp
+++ b/liveMedia/RTSPServer.cpp
@@ -1796,7 +1796,6 @@ void RTSPServer::RTSPClientSession
        || subsession == fStreamStates[i].subsession) {
       if (fStreamStates[i].subsession != NULL) {
        fStreamStates[i].subsession->deleteStream(fOurSessionId, fStreamStates[i].streamToken);
-       fStreamStates[i].subsession = NULL;
       }
     }
   }

What I have doubts about, is what vlc does: after the SETUP, it sends a PLAY
starting from NPT 0.0, but with a recorded stream, it does not make sense,
the server then has no reason to send the sub-titles track synchronized
with the other tracks, it only happens to work (in my case), because the
tracks all retrieve frames from the same demuxer, so basically, the sub-titles
do not really start from NPT 0.0. But this looks fragile to me.

Let me seize this opportunity to explain a bit on what I am working:
a server based on live555 for RTSP streaming, but on ffmpeg for demuxing, which
allows to stream about any media file and have uniform functionalities, for 
instance seeking for any type of files, like .ts without index, weird .avi
and so on. Following live555 FAQ, I have used live555 as a library as much as
possible, however I have done some modifications to live555 which could be 
submitted as patches to this list if you are interested:
- Groupsock: when a receiving interface address is defined, bind all sockets
to it, and skip the "send to ourself a multicast packet" trick; this is to
accomodate the situation of an RTSP server running on a machine with multiple
interface with internet connectivity but where we want to use only one interface;
- RTP/RTCP use the "feedface"/first receiver report to fix the client ports
if NAT is running without "conntrack_rtsp";
- MultiFrameRTPSink: implement bitrate limiting, in order to allow streaming 
from a machine with high-speed connectivity to another machine with high-speed
connectivity going through a path with a "weak-link" with slow connectivity
(typically, from an internet address to my personal PC through a DSL line)
- H264VideoRTPSink: apply frame duration to the last RTP packet instead of the
first;
- VorbisAudioRTPSink: fix memory corruption error (detected by valgrind);
- Theora: implement RTPSink based on RFC draft (found in ffmpeg sources).

I would also like to say that live555 is really a great project to work with,
not being a C++ fan myself, I appreciate the minimalist approach live555 took.

Regards.

-- 
                                                                Gilles.