>connect() in RTSPClient::openConnectionFromURL() is blocking.
Yes. Our RTSP client implementation needs to be reimplemented to do
non-blocking I/O. This is on our 'to do' list.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-
Dear Sir:
connect() in RTSPClient::openConnectionFromURL() is blocking. A practical
application may not accept such a behavior. The following functions provide
connect() with timeout setting on Windows(maybe work on Linux). Not very
elegant but work. Please take them into consideration.
Boolean m
>The problem is, deliverFrame returns the very first frame OK, then
>doGetNextFrame is called again before a new frame is captured, and I
>return immediately. Then, I don't know why, liveMedia never calls
>doGetNextFrame again. It just stays stuck and apparently does nothing.
>
>Why?
Because you a
>I was
>wondering if it was theoretically possible to design a custom Sink
>class, which instances could be attached to various sources.
The best way to do this would not be to define a new type of sink,
but instead define a new type of source - i.e., a subclass of
"FramedSource" - that would,
Hi to all,
In my custom FramedSource, documentation recommends that doGetNextFrame
should not call deliverFrame() if there is no frame ready.
So, I do something like that in doGetNextFrame.
isAwaitingData() functions checks if my real-time source has new encoded
data (It's crafted in a way that
Hello,
My name's Etienne Bömcke and I'm a PhD. student in a belgian
university. I'm working currently on a software using the liveMedia
streaming library, and I've been confronted to a problem I can't solve
by myself for now. So I thought I could post the problem here and ask
for your opin
