<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 24/06/15 03:15, Ross Finlayson wrote:<br>
<blockquote
cite="mid:6C1950CF-5BE8-46A7-9B90-627898681F25@live555.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
FYI, I have just run a test using the LIVE555 RTSP client library
- both with VLC, and our own RTSP client application - against our
RTSP server, and have concluded that the problem that you describe
does not seem to be a problem with the LIVE555 library.</blockquote>
<br>
Hi Ross,<br>
<br>
I didn't want to suggest it was... After more investigation
yesterday I think I now know what the problem is and it's
fundamentally a VLC issue, but I think it's triggering an abstruse
problem in LIVE555 which I'll get back to you on when I've got a fix
for it.<br>
<br>
<blockquote
cite="mid:6C1950CF-5BE8-46A7-9B90-627898681F25@live555.com"
type="cite">
<div class="">It’s possible that the problem lies with VLC’s
LIVE555 interface code (“live555.cpp”), but (given that I also
tested VLC as a client) it’s much more likely, IMHO, that the
problem is with your own RTSP server - in particular, the way in
which it implements the RTSP “PAUSE” command.</div>
<div class=""><br class="">
</div>
<div class="">Based on the RTSP protocol trace that you included
in your message, it seems that after your server gets (and
responds to) the “PAUSE” command, it does not handle the
subsequent “GET_PARAMETER” commands. Instead, these commands
get pipelined (somewhere), and your server does not end up
handling them until after it receives the subsequent “PLAY”
command.</div>
</blockquote>
<br>
Did you distinguish between VLC's log (actually your RTSPClient log)
of the RTSP conversation and the later Wireshark one? The VLC one
shows a delay of GET_PARAMETER responses but the Wireshark shows the
server returned them instantly.<br>
<br>
The fundamental problem actually appears to be that VLC is not
calling your doEventLoop() while it is paused, even though it's
sending GET_PARAMETER requests, so the GP response data is never
processed until VLC sends the PLAY command and starts calling
doEventLoop() again. Hence the apparent delay in receiving the
responses.<br>
<br>
More detail in comments on
<a class="moz-txt-link-freetext" href="https://trac.videolan.org/vlc/ticket/14939">https://trac.videolan.org/vlc/ticket/14939</a><br>
<br>
The loss of the PLAY response which then causes VLC to lock up I
think may be due to a problem in your buffering of response data if
there are more than two responses buffered - but I'm still
instrumenting and investigating and will get back to you on live555
list with a report/patch later if so. But that's a pretty abstruse
problem which the VLC issue is revealing... Fixing it would hide
the fundamental problem for a while, but only until the response
data buffer ran out.<br>
<br>
<blockquote
cite="mid:6C1950CF-5BE8-46A7-9B90-627898681F25@live555.com"
type="cite">
<div class="">It wasn’t clear from your message whether your
stream was RTP-over-UDP, or RTP-over-TCP, but if it was
RTP-over-TCP, then I could easily imagine how your server could
have a bug that causes it to have problems handling RTSP
commands that follow a “PAUSE”. (FYI, when I did my own testing
with the LIVE555 RTSP client code to try (unsuccessfully) to
reproduce this problem, I tested with both RTP-over-UDP and
RTP-over-TCP.)</div>
<br>
</blockquote>
<br>
FWIW, RAW/RAW/UDP but I don't think that's significant.<br>
<br>
One thing doesn't add up though, which is if you aren't seeing this
problem in VLC against Live555 server. That could be the dog that
didn't bark in the night...<br>
<br>
Best regards<br>
<br>
Paul<br>
</body>
</html>