On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson <[email protected]>wrote:
> 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). >> > > 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). > > Fixing "RTSPClient" is high priority (second only to fixing the problems > with RTP-over-TCP). 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?
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
