> Is the last line (handleRequestBytes() processing 3 new bytes) expected ?
No, this is another bug in the code; it'll be fixed in the next release of the
software (in a few hours). (Fortunately, it would cause a problem only if a
Base-64-encoded request were split into three or more network re
Hi Ross,
The new version has been running for over 3 hours and it successfully
combines split base 64 encoded GET_PARAMETER requests:
RTSPClientConnection[0x1de840]::handleRequestBytes() read 271 new
bytes:R0VUX1BBUkFNRVRFUiBydHNwOi8vMTAuMjYuNy4xMjA6ODU1NC9zdHJlYW05LyBSVFNQLzEuMA0KQ1NlcTogNzI
Excellent - thanks Ross,
I've downloaded and built the new version and started running it through
gdb. I will let you know if it runs for > 2 hours and look out for
requests that get split over more than one network read.
Many Thanks,
Piers
___
liv
FYI, I've just installed a new version - 2014.06.27 - of the code that, I
believe, will fix the RTP/RTCP-over-HTTP server error that you saw.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live55
Piers,
Thanks for the report. Using it, I was able to identify a bug in the RTSP
server code (when an incoming Base-64-encoded request is fragmented over
multiple reads, as in your case). A new version of the code - fixing this bug
- will be available shortly. (I'll send out another email wh
Hi Ross,
We have rebuilt with -g and without -o0 and get the same result (SIGABRT
in disassembled code, no stack trace).
We have tried the latest build of OpenRTSP with the -T flag. OpenRTSP
does not send GET_PARAMETER requests to the Live555 server, so it will
not call the code in base64Dec
Thanks Ross,
We are using an unmodified (save for the extra printf's) build of the latest
version of live555.
I will try a build without -O0 optimizations on Monday to see if I can get a
stack trace. I will also try using openRTSP as the client to see if that
affects the results.
Piers
--
Se
> We have been using live 555 reliably for a couple of years to provide the
> RTSP streams from a CCTV camera we have developed. When testing RTSP over
> HTTP streams (using VLC 2.1.3 as a client) we have found we get one of the
> following error messages after ~65-100 minutes:
>
> *** glibc de
Hi Ross,
We have been using live 555 reliably for a couple of years to provide
the RTSP streams from a CCTV camera we have developed. When testing RTSP
over HTTP streams (using VLC 2.1.3 as a client) we have found we get one
of the following error messages after ~65-100 minutes:
*** glibc de