[vlc-devel] RTSP: Failure to recover from long PAUSE

[Paul Clark]

On 24/06/15 03:15, Ross Finlayson wrote:
> 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.

Hi Ross,

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.

> 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.
>
> 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.

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.

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.

More detail in comments on https://trac.videolan.org/vlc/ticket/14939

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.

> 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.)
>

FWIW, RAW/RAW/UDP but I don't think that's significant.

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...

Best regards

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150624/7787bc32/attachment.html>