Ross Finlayson writes:
>
> How were you intending to use the "client data" value?
Since my application has a number of concurrent RTSP sessions, I
need to be able to tie responses back to their context. Without
a user data pointer, I can think of two options. The first is to
keep a global map
Ross Finlayson writes:
>
> I have installed a new version (2010.05.29) of the "LIVE555
> Streaming Media" code that adds the long-promised new
> 'asynchronous' (i.e., non-blocking) interface to the
> "RTSPClient" class.
Thank you for publishing this new interface; I've been looking
forward to it
It seems that RTSP over HTTP support was broken in the May 29
release. This patch fixes it:
diff -Naur live.orig/liveMedia/RTSPClient.cpp live/liveMedia/RTSPClient.cpp
--- live.orig/liveMedia/RTSPClient.cpp 2010-05-29 22:20:31.0 +
+++ live/liveMedia/RTSPClient.cpp 2010-06-01
Jeremy Noring writes:
>
> Actually, on second glance, the only realistic option is to
> shorten length, because only a single byte is allotted to the
> size field in fData[1]. (note that length is cast to unsigned
> char). So in RTCP.cpp, I'd change this line:
>
> if (length > 251) length = 25
Jeremy Noring writes:
>
> In RTPSink.cpp,
>
> unsigned lastReceivedTimeNTP
> = (unsigned)((lastReceivedTimeNTP_high<<16) + fractionalPart + 0.5);
>
> A 32-bit value is shifted, then cast to 64-bit value (this is
> because of the parenthesis); I'm not sure if
> lastReceivedTimeNTP_high get
