[Live-devel] alternate RTSPOverHTTPServer implementation

[Dan DuFeu]

Hi Ross,

I've attached a patch file for my alternate RTSPOverHTTPServer for your
consideration.

The patch also includes a revision of mediaServer/ code that can be used
for testing. I've tested against VLC and Quicktime with a server
compiled in Windows (VS 9) and Linux.

I made 3 change areas to RTSPServer to support a cleaner implementation
of my subclass. Even if you don't accept my implementation of the
RTSPOverHTTPServer, you may want to consider the following that make
subclassing of the Server easier (IMO):

1. New virtual function to get a new sessionId. This allows subclasses
access to the counter (currently private).
> unsigned RTSPServer::getNewSessionId()
> {
>       return ++fSessionIdCounter;
> }

2. I broke up the incomingRequestHandler1 function into two parts. The
first part performs the read, and the second provides the RTSP parsing.
This allows subclasses to perform their own reading (in my case also
doing a Base64 decode) and re-use the parsing included in the RTSPServer
object. Both are virtual. Pseudocode:
void RTSPServer::RTSPClientSession::incomingRequestHandler1() {
	Read and exit on error
	...
	handleRequestData(bytesRead);
}
void RTSPServer::RTSPClientSession::handleRequestData(int bytesRead)
{
	Find end of RTSP request, parse and run
}

3. Added ";timeout=xxx" to the Session field. It is optional in the RFC,
but Quicktime was not respecting the 60 second default and currently if
(reclaiming is enabled) the sessions timeout with Quicktime unless this
is specified.

4. I only said I made 3 changes, but I snuck in another change that
allows the Date header generating function to be used in subclasses. Not
a big deal, I just dislike copied code.

Anyways, Let me know your thoughts...

Thanks,
Dan.

ps. I noticed that VLC seems to have trouble when running with
RTP/RTSP(TCP). After a minute, it sends a GET_PARAMETER request as a
keepalive and the video in the client freezes, though the streaming
still continues from the server. I'm assume VLC is waiting for a
response to the RTSP request (it never comes because RTSP is ignored
once the session starts streaming over TCP). This seems to occur
regardless of the "timeout" attribute I mention above. Anyways, I might
try to tackle this issue next... I'd like to come up with an approach
that allows multiple streams over the same TCP connection. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AltRTSPOverHTTP.patch
Type: application/octet-stream
Size: 71745 bytes
Desc: AltRTSPOverHTTP.patch
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090807/b399d2c9/attachment-0001.obj>