FYI, I've now installed a new version (2012.04.27) of the "LIVE555 Streaming
Media" code that should fix the issue that Guy Bonneau noted.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.
On 4/26/2012 10:03 PM, Ross Finlayson wrote:
The "RTSPClient" code
needs to be more careful about not accessing "RTSPClient" object state
after calling "handleRequestError()", because of the likelihood (which
in fact happens in "testRTSPClient") of the "RTSPClient" object being
deleted when the e
Guy Bonneau wrote:
> I took a fast look at your issue and I believe I might have found the cause
> of the corruption. Put a breakpoint at line 1263 of file RTSPClient.cpp. This
> line should be:
>
> client->connectionHandler1();
>
> Set testRTSPClient as the starting application of the sol
First, everyone who receives this mailing list as a 'Digest' should heed this
advice:
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of live-devel digest..."
> Attached is the testRTSPClient.cpp that will crash.
>
> If you use this as a source: rts
> If you attempt to receive a stream from an invalid source, (i.e.
> rtsp://non-existing_IP:554/main)
> then the testRTSPClient application will crash.
>
> It seems that calling Medium::close() is the culprit. Medium::close() works
> fine when connected to a valid stream, but will cause heap co
Hi;
If you attempt to receive a stream from an invalid source, (i.e.
rtsp://non-existing_IP:554/main)
then the testRTSPClient application will crash.
It seems that calling Medium::close() is the culprit. Medium::close() works
fine when connected to a valid stream, but will cause heap corruption
