Hi Ross,
I updated to code to latest version and now the crash problem is solved -
thanks for the quick response.
Now I'm left with a new problem:
1. open VLC connection to proxy Axis camera H264 stream that does not
implement RTSP "PAUSE" and sends RTSP "BYE" after a timeout.
2. stop the stream from VLC.
3. wait for the timeout.
4. play the proxy stream again from VLC. --- The stream won't start
and I get from the backend a 454 Session Not Found
After the stream is closed by the backend server it teardown the session that
we worked with.
If it try to request the stream again the proxy server is sending only play
command to the backend - cause it assumes that it is already setup by prior
call but actually I get a 454 Session Not Found - which is understandable
because the backend closed this session.
As I understand it from what you stated that the backend server does not
implement PAUSE and sends RTSP "BYE" the idea of keeping the
ProxyRTSPClient <---> Backend connection will not work and we need go back to
the point before we called the first DESCRIBE.
I modified the library code as follows in order to solved the problem, but it
is an HACK and I would appreciate a better solution if you have one:
void ProxyServerMediaSubsession::subsessionByeHandler() {
if (verbosityLevel() > 0) {
envir() << *this << ": received RTCP \"BYE\"\n";
}
//make the proxy client belive that there is a problem with the backend and
reset all connections and send DESCRIBE again.
ProxyServerMediaSession* const sms =
(ProxyServerMediaSession*)fParentSession;
ProxyRTSPClient* const proxyRTSPClient = sms->fProxyRTSPClient;
proxyRTSPClient->continueAfterLivenessCommand(-1,
proxyRTSPClient->fServerSupportsGetParameter);
//comment out this code.
//// This "BYE" signals that our input source has (effectively) closed, so
handle this accordingly:
//FramedSource::handleClosure(fClientMediaSubsession.readSource());
//// Then, close our input source for real:
//fClientMediaSubsession.deInitiate();
}
After this change the scenario works.
Thanks,
Yogev.
>> Please advise how to proceed, will there be a fix in future release?
>
> Yes, because you appear to have found a bug in the code.
>
> To help me debug this, could you please re-run the "LIVE555 Proxy Server"
> with the "-V" (upper-case V) option, to generate diagnostic output, and
> please send us the diagnostic output, up to the point of the crash.
Actually, you no longer need to do this, because I have now found (and fixed)
the bug. (It turns out that the problem occurred only when proxying a H.264
video stream, from a back-end server that (1) does not handle "PAUSE", and (2)
sends a RTCP "BYE" at the end of the stream.
I've now installed a new version (2013.09.18) that should fix the problem.
(I'll also take a look at the other problem that you reported, although that is
less serious.)
Thanks again for reporting this.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
