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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
