Subclassing RTSPServer events

[Alan Martinovic]

I have a streaming source that already provides me with a h264 RTP stream and would like to use live555 just as a RTSP server.
I require neither RTP packetization nor RTCP generation.
The ideal use case would be to be able to run custom scripts on events that represent RTSP commands, and be able to send a modified SDP.

Would the recommended approach be to subclass the RTSPServer, completely ignore the ServerMediaSession (and the source-sink mechanism) and reimplement the handleCmd* commands?

DISCLAIMER:
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

[Ross Finlayson]

Post by Alan Martinovic
I have a streaming source that already provides me with a h264 RTP stream and would like to use live555 just as a RTSP server.
I require neither RTP packetization nor RTCP generation.
The ideal use case would be to be able to run custom scripts on events that represent RTSP commands, and be able to send a modified SDP.
Would the recommended approach be to subclass the RTSPServer, completely ignore the ServerMediaSession (and the source-sink mechanism) and reimplement the handleCmd* commands?

I believe you can get what you want without subclassing "RTSPServer" at all. The trick is to add, to your "RTSPServer" object, a "PassiveServerMediaSubsession". A "PassiveServerMediaSubsession" is used when you want your "RTSPServer" to handle a stream that already exists, rather than one that is created, on demand, for each RTSP client. The stream (that already exists) is usually multicast, rather than unicast (although "PassiveServerMediaSubsession" might still work if the stream is unicast). In any case, I suggest that - if you're not already doing so - you change your RTP streaming source to transmit to an IP multicast address (unless you are going across a network that doesn't support IP multicast routing). By doing this, you will allow any client (rather than just one) to receive the stream, if is wishes.

Note that "PassiveServerMediaSubsession::createNew()" takes two parameters: A "RTPSink" object, and (optionally, if the stream also contains RTCP packets (which is should, if it wants to be fully standards-compliant)) a "RTCPInstance" object. Just create these objects beforehand (using the destination IP address (ideally, multicast) and port(s) for the stream), and pass them to "PassiveServerMediaSubsession::createNew()". Then add the "PassiveServerMediaSubsession" object as a 'subsession' to a "ServerMediaSession" object, and add the "ServerMediaSession" object to your "RTSPServer". For an illustration of how this is done, note the code for the "testH264VideoStreamer" demo application, in the "testProgs" directory.
(Of course, one big difference between your application and "testH264VideoStreamer" is that you *won't* be calling "startPlaying()" to start transmitting RTP packets, because your source is already doing that.)

One important note, however. Because your stream is H.264, your "RTPSink" object will actually be a "H264VideoRTPSink". Because this will not be fed by an input source, you *must* use one of the 'optional variants' of "H264VideoRTPSink::createNew()" that specify the stream's SPS and PPS NAL units.

Finally, I suggest that initially you use "openRTSP" as a RTSP client to test your server, before testing it with a media player client.


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