> I've found one more more similar issue, the new one is triggered by the
> following sequence:
> - Connection to back-end server is torn down
> - The torn down connection triggers a read error which causes the socket to
> be closed
> - If a client to the proxy at this point issues PLAY, the clos
> This error is always caused by a socket being closed without
> disableBackgroundHandling()
> or, equivalently
> turnOffBackgroundReadHandling()
> having been first called on it.
As I understand it, the socket is properly closed, but the (now closed)
socket number is incorrectly re
> I have now installed a new version (2017.01.26) of the “LIVE555 Streaming
> Media” code that incorporates your patch (mostly).
Thanks a lot Ross, this is great!
I've found one more more similar issue, the new one is triggered by the
following sequence:
- Connection to back-end server is torn dow
>> The problem frequently occurs in the following scenarios:
>> 1) ProxyRTSPClient::continueAfterLivenessCommand called from within
>> the stack frame of SocketDescriptor::tcpReadHandler.
>> 2) A client to the proxy server issues PLAY while the connection to the
>> 'back end' is being reestablished
> The problem frequently occurs in the following scenarios:
> 1) ProxyRTSPClient::continueAfterLivenessCommand called from within
> the stack frame of SocketDescriptor::tcpReadHandler.
> 2) A client to the proxy server issues PLAY while the connection to the
> 'back end' is being reestablished.
It
er TCP), thus preventing a client
from issuing a PLAY while connection to 'back-end' is being
reestablished?
(Log is available if it's of any use)
/Erik
2016-12-26 17:03 GMT+01:00 Erik Montnemery :
> Hi,
>
> Most of the time, the proxy server reconnects to the 'back-en
Hi,
Most of the time, the proxy server reconnects to the 'back-end' server
after an error or loss of connection, but every now and then the
following happens:
Error or connection loss is detected, and the reset sequence is performed.
However, after the new connection to the 'back end' server is
i
>>> 1) The proxyserver reconnects to the source, but no data frames are
>>> forwarded to the clients.
>>
>> If no data are forwarded to the (‘front-end’) clients, then that must mean
>> that the ‘back-end’ server was not sending any data to the proxy server. If
>> the ‘back-end’ server appears r
Thanks, Ross!
>
> our code here is conservative: If there’s another client using the session,
> then we send a “PAUSE” only on the particular subsession that’s being closed.
OK, so just so I understand:
In the case I described, the client was streaming only one track over
TCP. When the TCP connec
Hi,
I have a question about the PAUSE logic in
ProxyServerMediaSubsession::closeStreamSource.
Consider the following scenario:
Proxy server is proxying a stream with two subsessions:
- RTP/video/H264
- RTP/audio/MPEG4-GENERIC
Client A connects to the proxy and does a SETUP specifically for the
v
>>
>> To reproduce the issue:
>> - Restart 'back end' server
>> - RTSP proxy will reconnect, and reuse the previous SESSION identifier
>> for PLAY / PAUSE, assuming the session is still valid
>> - 'Back end' server incorrectly accepts this, although the SESSION has
>> not been setup
>
> I don’t und
>> 1) The proxyserver reconnects to the source, but no data frames are
>> forwarded to the clients.
>
> If no data are forwarded to the (‘front-end’) clients, then that must mean
> that the ‘back-end’ server was not sending any data to the proxy server. If
> the ‘back-end’ server appears respons
> Actually, all of the client’s ‘request queues’ should be reset by
> “RTSPClient::reset()”.
>
> I’ve now installed a new version (2016.09.08) of the “LIVE555 Streaming
> Media” code that fixes this.
Thanks a lot, Ross!
I did some extended testing by modifying one of the 'back-end' devices
to r
RTSPClient::sendRequest from:
if (!fRequestsAwaitingConnection.isEmpty()) {
To:
if (!fRequestsAwaitingConnection.isEmpty() && fInputSocketNum >= 0) {
/Erik
2016-09-05 21:28 GMT+02:00 Erik Montnemery :
> Thanks Ross,
>
> Regarding issue 1)
> You might be right, I'll try t
Thanks Ross,
Regarding issue 1)
You might be right, I'll try to reproduce while recording network traffic.
Regarding issue 2)
> the state for the stream has timed out, and the proxy server then attempts to
> re-open a RTSP connection to the ‘back-end’ server. However, this appears to
> be hangi
Hi,
Most of the time, the proxy server reconnects to the source after a
loss of connection to a source, but every now and then I observe one
of the following issues:
1) The proxyserver reconnects to the source, but no data frames are
forwarded to the clients.
An example log of scenario 1) is paste
>> By the way, I think there might be a bug in the handling of the
>> periodic liveness commands:
> No, the periodic ‘liveness’ commands are intended to test that the TCP
> connection is still alive, and also to compensate for a large number of
> servers that require these periodic commands in te
> OK, I still can’t quite figure out what’s going wrong here, but I think I’m
> getting closer. I’ve just installed a new version (2016.03.16) of the code
> that adds some extra checking, and some more ‘internal error’ debugging
> fprintf()s. > Please run this new version, and let me know if yo
> OK, I still can’t quite figure out what’s going wrong here, but I think I’m
> getting closer. I’ve just installed a new version (2016.03.16) of the code
> that adds some extra checking,
> and some more ‘internal error’ debugging fprintf()s. Please run this new
> version, and let me know if y
2016-01-24 22:22 GMT+01:00 Ross Finlayson :
>> On Jan 12, 2016, at 1:48 PM, Erik Montnemery wrote:
>>
>> I'm using the live555ProxyServer to be able to reliably record and view
>> streams from four cheap cameras concurrently.
>> Recording is done in 15 minut
Hi,
I'm using the live555ProxyServer to be able to record and view streams from
four cheap cameras concurrently.
Version of live555ProxyServer is 2015.12.22
There seems to be something strange going on when an additional client
connects a stream which is already being played by another client.
Re
As mentioned earlier, I'm using the live555ProxyServer to be able to record
and view streams from four cheap cameras concurrently.
There seems to be something strange going on when an additonal client
connects to an already active proxied stream.
The stream is h264+aac.
After some testing it seem
I'm using the live555ProxyServer to be able to reliably record and view
streams from four cheap cameras concurrently.
Recording is done in 15 minute chunks with 15 seconds of overlap, meaning
there will normally be between 4-8 active clients for the 4 proxied streams.
The live 555 version is 2015.1
23 matches
Mail list logo
