On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Looking at the original patch, it's pretty clear that the author forgot to set the socket back to be blocking. But considering that this issue has been present for well over a year, I have to wonder whether or not the RTSPClient even needs to be run on a blocking socket. (Ross, you know the most about this, so I'd be interested to hear your take on things).<br>
</blockquote>
<br></div>
I'm not planning on doing much with the existing "RTSPClient" code, because this code will soon be significantly overhauled so that it does I/O asynchronously, using the event loop, rather than the current blocking-with-timeout model (which doesn't fit with the event-driven model of the rest of the library's code). This change will also eliminate the need for a "timeout" parameter (although the existing API will probably kept - as an option - for a while, for backwards compatibility).<br>
<br>
Fixing "RTSPClient" is high priority (second only to fixing the problems with RTP-over-TCP).</blockquote><div><br>I've had a chance to test this change, and everything still seems to work OK for me (I use the RTSPClient to pull directly from a Live555 on-demand server; I also use the darwin push code, which uses the RTSPClient internally). How do you want the patch?<br>
</div></div>