[Live-devel] Trick play based pause interacts badly with Enseo STBs

[Warren Young]

If you use live555MediaServer to stream MPEG-2 in a TS to an Enseo 
HD2000 STB, pause and resume works fine as long as you haven't used the 
indexer to build .tsx files, or you disable trick play handling in 
MPEG2TransportFileServerMediaSubsession::pauseStream():

> void MPEG2TransportFileServerMediaSubsession
> ::pauseStream(unsigned clientSessionId, void* streamToken) {
>   if (fIndexFile != NULL) { // we support 'trick play'
>     ClientTrickPlayState* client = lookupClient(clientSessionId);
>     if (client != NULL) {
>       client->updateStateOnPlayChange(False);
>     }
>   }
>
>   // Call the original, default version of this routine:
>   OnDemandServerMediaSubsession::pauseStream(clientSessionId, streamToken);
> }

That is to say, the STB will resume a paused RTSP stream for an indexed 
MPEG-2 TS correctly if you remove everything but the last line, causing 
the server to behave as if the TS file doesn't have an index purely for 
the purposes of pause handling.

With the .tsx file and problem code present, resuming causes the 
displayed video to look like digital satellite TV when there's snow on 
the dish.  Jerky playback, occasional pauses, macroblocks decoding in 
the wrong place/time...ugly stuff.  Additionally, it looks like the STB 
is giving up and trying to restart the stream at some point.

While debugging this, we noticed that VLC doesn't send RTSP PAUSE when 
you press its Pause button.  We assume it's working like a DVR in this 
instance, just buffering the streamed data to use when you unpause.  I 
mention this that's the only other RTSP clients we have on hand.  We 
lack another client that does send RTSP PAUSE, so as far as we can see, 
there's nothing wrong with disabling trick play support for pause.

We assume there *is* some bad consequence, since the code probably 
wasn't written for no reason.  Which client does this hack break?

We have a solution to our problem, hacky though it is, but we'd be 
happier if the server just did the right thing with Enseo STBs out of 
the box, so we're willing to help you look into this, Ross.  We can send 
you one of these STBs, plus tools and information that will help you 
debug the issue.

I've attached a transcript of the RTSP conversation between an Enseo 
HD2000 and live555MediaServer.  You see it start the stream, then pause 
and attempt to resume it.

One of the things you'll notice in the transcript is that the STB sends 
a GET_PARAMETER request for "position" on pause.  I couldn't find any 
documentation online saying what the client is supposed to get in 
response, only the RTSP RFC saying this is an open extension mechanism. 
  We don't know which RTSP server implements this parameter (Kasenna or 
SeaChange, probably), but we assume the purpose is to let the STB tell 
the server where to resume from.

We considered trying to modify the server to send a real reply for this 
parameter by looking at the trick play index, but then stumbled across 
our current hacky fix.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: enseo-play-pause-resume.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110803/6c38766c/attachment-0001.txt>