<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi guys,<br>
<br>
We've come across a problem around handling of PAUSE and
GET_PARAMETER keepalives against our RTSP server. The user symptom
is that a pause of more than a minute or so cannot be resumed and
VLC appears to lock up if you try.<br>
<u><br>
Version:<br>
<br>
</u>Revision 2.2.0-rc1-118-g22fda39 (built from 2.2.0 branch today,
default config) on Debian Jessie.<br>
Same symptom in 2.1.x (which is where we first noticed it)<br>
<br>
<u>To reproduce:</u><br>
<br>
- Start an RTSP stream against a server which supports GET_PARAMETER
for keepalives (e.g. Packet Ship, ask me for an eval copy)<br>
- Pause it (PAUSE command)<br>
- Wait for at least two GET_PARAMETER keepalives to be sent while
paused (max 2 minutes with standard session timeout)<br>
- Unpause it (PLAY command)<br>
<br>
The video does not restart and VLC will not close.<br>
<u><br>
</u><u>VLC log (RTSP only):</u><br>
<br>
(normal OPTIONS/DESCRIBE/SETUP and PLAY all fine, removed)<br>
<br>
First GET_PARAMETER while playing normally - notice response is
logged:<br>
<pre>Sending request: GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021</pre>
<pre>Received 156 new bytes of response data.
Received a complete GET_PARAMETER response:
RTSP/1.0 200 OK
Content-Length: 0
CSeq: 6
Server: Packet Ship RTSP Server v3.1.10
Date: Tue, Jun 23 2015 10:22:38 GMT
Content-type: text/parameters</pre>
<br>
PAUSE request:<br>
<pre>Sending request: PAUSE <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 7
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021</pre>
<pre>Received 153 new bytes of response data.
Received a complete PAUSE response:
RTSP/1.0 200 OK
Content-Length: 0
CSeq: 7
Server: Packet Ship RTSP Server v3.1.10
Date: Tue, Jun 23 2015 10:22:43 GMT
Range: npt=4.73564-596.182</pre>
<br>
GET_PARAMETER requests while paused - note no response logged:<br>
<pre>Sending request: GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 8
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021</pre>
<pre>Sending request: GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 9
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021</pre>
<br>
PLAY request on pressing <play>. Note responses to
GET_PARAMETERs above are now logged but not the response to PLAY
(which was sent, see wireshark log below):<br>
<pre>Sending request: PLAY <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 10
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021</pre>
<pre>Received 312 new bytes of response data.
Received a complete GET_PARAMETER response:
RTSP/1.0 200 OK
Content-Length: 0
CSeq: 8
Server: Packet Ship RTSP Server v3.1.10
Date: Tue, Jun 23 2015 10:23:26 GMT
Content-type: text/parameters
(plus 156 additional bytes)</pre>
<pre>Received 154 new bytes of response data.
Received a complete GET_PARAMETER response:
RTSP/1.0 200 OK
Content-Length: 0
CSeq: 9
Server: Packet Ship RTSP Server v3.1.10
Date: Tue, Jun 23 2015 10:24:14 GMT
Content-type: text/parameters</pre>
<br>
Then after a further timeout period another GET_PARAMETER is sent,
and Live555 complains (wrongly) about CSeq error:<br>
<pre>Sending request: GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 11
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021</pre>
<pre>Received 157 new bytes of response data.
WARNING: The server did not respond to our "PLAY" request (CSeq: 10). The server appears to be buggy (perhaps not handling pipelined requests properly).
Received a complete GET_PARAMETER response:
RTSP/1.0 200 OK
Content-Length: 0
CSeq: 11
Server: Packet Ship RTSP Server v3.1.10
Date: Tue, Jun 23 2015 10:25:02 GMT
Content-type: text/parameters</pre>
<br>
<u>Wireshark log</u><br>
<br>
Note all commands have responses with correct CSeq. This doesn't
show the timing but the responses are instant in every case.<br>
<br>
<pre>GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021
<i>RTSP/1.0 200 OK
</i><i>
</i><i>Content-Length: 0
</i><i>
</i><i>CSeq: 6
</i><i>
</i><i>Server: Packet Ship RTSP Server v3.1.10
</i><i>
</i><i>Date: Tue, Jun 23 2015 10:22:38 GMT
</i><i>
</i><i>Content-type: text/parameters</i>
</pre>
<pre>
PAUSE <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 7
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021
<i>RTSP/1.0 200 OK
</i><i>
</i><i>Content-Length: 0
</i><i>
</i><i>CSeq: 7
</i><i>
</i><i>Server: Packet Ship RTSP Server v3.1.10
</i><i>
</i><i>Date: Tue, Jun 23 2015 10:22:43 GMT
</i><i>
</i><i>Range: npt=4.73564-596.182
</i>
GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 8
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021
<i>RTSP/1.0 200 OK
</i><i>
</i><i>Content-Length: 0
</i><i>
</i><i>CSeq: 8
</i><i>
</i><i>Server: Packet Ship RTSP Server v3.1.10
</i><i>
</i><i>Date: Tue, Jun 23 2015 10:23:26 GMT
</i><i>
</i><i>Content-type: text/parameters
</i>
GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 9
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021
<i>RTSP/1.0 200 OK
</i><i>
</i><i>Content-Length: 0
</i><i>
</i><i>CSeq: 9
</i><i>
</i><i>Server: Packet Ship RTSP Server v3.1.10
</i><i>
</i><i>Date: Tue, Jun 23 2015 10:24:14 GMT
</i><i>
</i><i>Content-type: text/parameters
</i><i>
</i>
PLAY <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 10
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021
<i>RTSP/1.0 200 OK
</i><i>
</i><i>Content-Length: 0
</i><i>
</i><i>CSeq: 10
</i><i>
</i><i>Server: Packet Ship RTSP Server v3.1.10
</i><i>
</i><i>Date: Tue, Jun 23 2015 10:24:20 GMT
</i><i>
</i><i>Range: npt=4.73564-596.182
</i>
GET_PARAMETER <a class="moz-txt-link-freetext" href="rtsp://127.0.0.1/media/bunny-mid.ts">rtsp://127.0.0.1/media/bunny-mid.ts</a> RTSP/1.0
CSeq: 11
User-Agent: LibVLC/2.2.0-rc2 (LIVE555 Streaming Media v2014.01.13)
Session: 2ab2f048bdd50021
<i>RTSP/1.0 200 OK
</i><i>
</i><i>Content-Length: 0
</i><i>
</i><i>CSeq: 11
</i><i>
</i><i>Server: Packet Ship RTSP Server v3.1.10
</i><i>
</i><i>Date: Tue, Jun 23 2015 10:25:02 GMT
</i><i>
</i><i>Content-type: text/parameters
</i></pre>
<br>
<u>Analysis</u><br>
<br>
I've only just started looking at the code
(modules/access/live555.cpp) but there have obviously been some
problems in this area before :-)<br>
<pre> /* Voodoo (= no) thread safety here! *Ahem* */</pre>
Normally the GET_PARAMETER keepalives are sent by Demux()
(live555.cpp:1280) based on a signal (b_timeout_call) from the
TimeoutPrevention thread, but obviously Demux() isn't being called
while paused. Hence on pause the TimeoutPrevention thread
(live555.cpp:2105) is told to do it itself (via b_handle_keepalive)
instead.<br>
<br>
Comment (:1643) confirms this:<br>
<pre> /* When we Pause, we'll need the TimeoutPrevention thread to
* handle sending the "Keep Alive" message to the server.
* Unfortunately Live555 isn't thread safe and so can't
* do this normally while the main Demux thread is handling
* a live stream. We end up with the Timeout thread blocking
* waiting for a response from the server. So when we PAUSE
* we set a flag that the TimeoutPrevention function will check
* and if it's set, it will trigger the GET_PARAMETER message */</pre>
What I can't figure out is how the response from GET_PARAMETER is
logged and handled normally - maybe inside Live555? Every other
RTSP command is followed by a call to wait_Live555_response(), but
the GET_PARAMETER calls are not, in either case. I'm guessing that
this is why the responses are not logged and it then loses the PLAY
response.<br>
<br>
That's as far as I've got... Any pointers? I'm happy to try to fix
it (it is causing us some mild pain) but there's a certain feeling
of 'where angels fear to tread' in this stuff and I could use some
help :-)<br>
<br>
Many thanks<br>
<br>
Paul<br>
<br>
<br>
<br>
</body>
</html>