[Live-devel] Defintion of the ServerMediaSession and SeverMediaSubsession classed and their usage in relation with doGetNextFrame()

[Ross Finlayson]

>Additionally, I implemented lookupServerMediaSession() virtual 
>method in  myOnDyanmicRTSPServer. Now in lookupServerMediaSession() 
>I checked to see if the channel name in the URI passed to this 
>method does not exist then I created a ServerMediaSession and added 
>addSubsession()

If you haven't already done so, I suggest that you take a look at the 
code for "DynamicRTSPServer" (a "RTSPServer" subclass) in the 
"mediaServer" directory (the code for the "LIVE555 Media Server" 
product).  It does very much the same thing.


>My Questions are:
>
>1) What is the relationship between the ServerMediaSession and 
>SeverMediaSubsession?

Together, these two classes provide the server's implementation of a 
particular type of stream.  "ServerMediaSession" is just a container; 
it contains one or more "ServerMediaSubsession" objects.  For 
example, for a stream that consists of an audio substream and a video 
substream, the "ServerMediaSession" object will contain two 
"ServerMediaSubsession" objects - one for the audio substream; the 
other for the video substream.

You will usually need to subclass only "ServerMediaSubsession". 
Specifically, because you are streaming via unicast, you should 
subclass "OnDemandServerMediaSubsession" (once for your video 
substream, and again for an audio substream, if you have one).  You 
will need to provide your own implementations of the 
"createNewStreamSource()" and "createNewRTPSink()" pure virtual 
functions.  (Note the several examples of this already in the code.)

Also, because you are streaming from a live encoder, rather than from 
a file, be sure to set the "reuseFirstSource" parameter to True (so 
that your encoder object is read from only once, regardless of how 
many clients are accessing the stream).


>2) I need to know when to start/stop my video encoder. Currently, I 
>do this by sub-classing RTSPServer::RTSPClientSession and handling 
>the handlCmd_PLAY and handleCmd_TEARDOWN. Is this the correct place

No.  In most situations you should not need to modify the 
"RTSPServer" code's existing implementation of RTSP commands. 
Instead, special-case handling for RTSP commands can be done in the 
"ServerMediaSubsession" subclasses.


>  or should I sub-class the ServerMediaSubsession class and handle 
>startStream() and deleteStream() virtual methods?

You could do this, but I don't recommend it.  Instead, I suggest just 
doing this in your implementation of your encoder class's 
"doGetNextFrame()" virtual function, and its destructor.  In 
particular, your encoder class's "doGetNextFrame()" implementation 
could start the encoder when it's called for the first time.  Your 
encoder class's destructor can stop the encoder.


>3) How does clientSessionId that is passed to various xxxStream() 
>methods (i,e, startStream(), deleteStream()) relates to a particular 
>URI associated to a ServerMediaSession?

This is handled automatically by the RTSP server implementation.  You 
should not need to care about this.


>4) Lastly, how do I relate doGetNextFrame(), that is called by the 
>framer to get the next video frame, to the channel name as it was 
>specified in the RTSP URI command Play?

Your "ServerMediaSubsession" subclass should have a "encoder name" 
parameter in its "createNew()" function.  That way, when you create a 
new "ServerMediaSubsession" (subclass) object (in your 
reimplementation of "lookupServerMediaSubsession()", you can pass it 
this parameter, which it will remember (as a field).  Then, your 
implementation of the "createNewStreamSource()" virtual function can 
map this "encoder name" field to a particular encoder, when it 
creates source object(s) for the stream.

Look, for example, at the implementation of the 
"MP3AudioFileServerMediaSubsession" class (which implements streaming 
from a particular named MP3 file), and how this is used in the 
"testOnDemandRTSPServer" and "live555MediaServer" applications.

By the time your encoder class's "doGetNextFrame()" implementation 
gets called, the encoder object should already know which encoder 
it's going to use.  As I noted above, when "doGetNextFrame()" gets 
called for the first time, it can start the encoder.
-- 

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