(Remember everyone - if you're responding to a message in a mailing list
digest, make sure to fix the "Subject:" line in your response. (I've done it
for you here.))
On Feb 27, 2014, at 8:29 PM, Martínez Contador, Daniel [ELIMCO] (CA)
wrote:
>> Remember, You Have Complete Source Code. Rath
>> The "RTSPClientConnection" object gets deleted if the call to
>> "readSocket()" in
>> "RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786
>> of "RTSPServer.cpp) returns a value < 0 - which should happen when the
>> remote (i.e., client) end of the TCP connection gets closed
>
On 2/25/2014 14:33, Ross Finlayson wrote:
The "RTSPClientConnection" object gets deleted if the call to
"readSocket()" in
"RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786
of "RTSPServer.cpp) returns a value < 0 - which should happen when the
remote (i.e., client) end of th
> This is an educated guess.
Remember, You Have Complete Source Code. Rather than making "an educated
guess", you should be able to figure out exactly what's going on.
> In Cygwin the RTSPClientConnection
> socket doesn't close explicitly after a TEAR. The read bitmask
> in the call to select
On 2/25/2014 09:17, Warren Young wrote:
because it wants you to call recv() one last time and get -1, which is
how BSD sockets (and Winsock) signal that condition.
I meant 0, of course.
___
live-devel mailing list
live-devel@lists.live555.com
http://l
On 2/24/2014 06:36, Martínez Contador, Daniel [ELIMCO] (CA) wrote:
This is an educated guess. In Cygwin the RTSPClientConnection
socket doesn't close explicitly after a TEAR. The read bitmask
in the call to select in BasicTaskScheduler remains active
and the call returns immediately by some reas
Re: Overuse of CPU in binaries of CYGWIN
>> Cygwin tries very hard to be as minimal a layer between
>> your program and the Windows kernel as it can be, but in
>> certain places, it has to be thicker than we'd like to
>> emulate the POSIX semantics programs built on Cygwin
>> expect, in terms of t
> It is possible that Live555 is using the POSIX layer in a way that
> particularly annoys Cygwin, but I'd say the burden is on you to prove that,
> given that the library performs well on every other POSIXy OS.
>
> Cygwin tries very hard to be as minimal a layer between your program and the
>
On 2/19/2014 05:12, Martínez Contador, Daniel [ELIMCO] (CA) wrote:
The overuse happens with binaries from CYGWIN, but not with MINGW.
So you changed the development platform, but you blame Live555?
Science says that if you change one variable and the behavior changes,
chances are that the thi
> testMPEG4VideoStreamer.exe starts overusing the CPU when a player tears
> the session.
> The overuse happens with binaries from CYGWIN, but not with MINGW.
I wasn't able to reproduce this on either MacOS X or FreeBSD.
If you find a bug, please let us know.
Ross Finlayson
Live Networks, Inc.
ht
testMPEG4VideoStreamer.exe starts overusing the CPU when a player tears
the session.
The overuse happens with binaries from CYGWIN, but not with MINGW.
In my setup, testMPEG4VideoStreamer, just launched, uses <1% from CPU.
When a client connects (I'm using VLC) the CPU consumption remains
stable.
11 matches
Mail list logo
