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

[Ross Finlayson]

> 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;
>       }
>     }
>   }

Unfortunately we can't do this, because it breaks the subsequent 'optimization' - at the end of the "handleCmd_TEARDOWN()" function.  I.e., in the normal case, when an *entire* stream is torn down (using either a single aggregate "TEARDOWN" command, or via individual "TEARDOWN"s for each track), we immediately reclaim the "RTSPClientSession" structure.  (I don't want to rely upon the 'client liveness timeout' mechanism for this, because some people have disabled this mechanism, to allow for (broken) RTSP clients that don't send RTCP "RR" packets.)

But, more generally, the server code assumes, in several places, that a stream - once 'torn down' - cannot be resurrected via another "SETUP" within the same session (i.e., using the same session id).  This seems reasonable  - and consistent with the wording in the RTSP specification, which describes the "TEARDOWN" command as being one that ends a RTSP session.  So I don't want to change this behavior in our server code.

So this means, that - upon reflection - what VLC is doing is wrong.  Rather than sending a "TEARDOWN" for all subtitle tracks, and then doing a subsequent "SETUP" for the subtitle track that the user wants, it should instead just send a "TEARDOWN" for all subtitle tracks *except* the one that the user wants (and then not send another "SETUP").  (I'll follow up on the VLC developers' mailing list about this.)


> I have done some modifications to live555 which could be 
> submitted as patches to this list if you are interested:

> - VorbisAudioRTPSink: fix memory corruption error (detected by valgrind);

Yes please - I'm very much interested in this!

> - Theora: implement RTPSink based on RFC draft (found in ffmpeg sources).

This might also be useful.  Thanks.

> - H264VideoRTPSink: apply frame duration to the last RTP packet instead of the
> first;

Are you referring to the "H264FUAFragmenter" code (that automatically fragments large NAL units into smaller NAL fragments, for transmission)?  Yes, lets see what you've done here; it might be fixing a bug.


However, I don't think I can make the other changes that you mentioned:

> - 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;

Unfortunately I don't want to remove the 'send ourself a multicast packet' trick, because it's often the only reliable way that a host can figure out its own IP address.  Note, though, that if you have multiple interfaces, and want to use one in particular, then you can do so simply by ensuring that the interface that you want is the one on which IP multicast routing is enabled - i.e., it has a route for 224/8

> - RTP/RTCP use the "feedface"/first receiver report to fix the client ports
> if NAT is running without "conntrack_rtsp";

This seems like a security risk - i.e., it would allow an attacker to send the server a bogus initial packet, in order to 'hijack' the stream's traffic.

> - 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)

How are you figuring out that 'bitrate limiting' is needed?  By using feedback in RTCP "RR" reports (i.e., using the "RTPTransmissionStats" database)?  In any case, I don't see how this can be done in "MultiFramedRTPSink" as a general mechanism, because the choice of which outgoing packets to skip should really be codec dependent.  I.e., some frames (especially 'key' frames) are more important to send than others, and the "MultiFramedRTPSink" code - being codec independent - can't know this.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131215/ed621f1d/attachment.html>