[vlc-devel] RTSP client 'trick play' support. When will it ever work??

[Ross Finlayson]

After reading on http://www.videolan.org/ that one of the features
of VLC v1.0.0 is "RTSP Trickplay support", I excitedly downloaded and
installed it, but found - to my dismay - that this still does not
work at all.

(I tested this against a MPEG-2 Transport Stream file streamed by the
"LIVE555 Media Server" <http://www.live555.com/mediaServer/>, with
the file indexed to support trick play.)

I found that 'trick play' operations do not work at all. In
particular, the 'faster' and 'slower' controls have no effect (other
than displaying "faster" and "slower" in VLC's display). No new RTSP
"PLAY" commands are sent at all.

Similarly, I could not seek within the stream at all (by trying to
drag the playback diamond).

And pausing works at the GUI, but doesn't actually cause a RTSP
"PAUSE" command to be sent, so it's not actually pausing the network
stream.

What's going on here? Why was "RTSP Trickplay support" promoted as a
feature of VLC 1.0.0, when it doesn't work at all?

(Sorry for the harsh criticism, but it's only because - in most other
respects - I love VLC so much :-)

[Glen Gray]

I have to agree with Ross here.

I'm pretty disappointed to see this too. After working hard on the
original patch sets for vlc and live555 with ross, thedj, jpsaman and
blackjack from 2004 onwards and getting no traction on releases, I was
really looking forward to this being finally activated and enabled in
the 1.0 release.

There's absolutely no reason why this can't work, we've tens of
thousands of vlc installations that are patched for this and are out
at our customer sites doing rtsp trickplay against live555MediaServer
and Espial (Kasenna) MediaBase servers.

We'll be porting our platforms to VLC 1.x releases shortly, so
hopefully I'll be able to get patches out again for fixing the support
for this.

Post by Ross Finlayson
After reading on http://www.videolan.org/ that one of the features
of VLC v1.0.0 is "RTSP Trickplay support", I excitedly downloaded
and installed it, but found - to my dismay - that this still does
not work at all.
(I tested this against a MPEG-2 Transport Stream file streamed by
the "LIVE555 Media Server" <http://www.live555.com/mediaServer/>,
with the file indexed to support trick play.)
I found that 'trick play' operations do not work at all. In
particular, the 'faster' and 'slower' controls have no effect (other
than displaying "faster" and "slower" in VLC's display). No new
RTSP "PLAY" commands are sent at all.
Similarly, I could not seek within the stream at all (by trying to
drag the playback diamond).
And pausing works at the GUI, but doesn't actually cause a RTSP
"PAUSE" command to be sent, so it's not actually pausing the network
stream.
What's going on here? Why was "RTSP Trickplay support" promoted as
a feature of VLC 1.0.0, when it doesn't work at all?
(Sorry for the harsh criticism, but it's only because - in most
other respects - I love VLC so much :-)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
vlc-devel mailing list
http://mailman.videolan.org/listinfo/vlc-devel

--
Glen Gray
slaine at slaine.org

[Laurent Aimar]

Hi,

After reading on http://www.videolan.org/ that one of the features of
VLC v1.0.0 is "RTSP Trickplay support", I excitedly downloaded and
installed it, but found - to my dismay - that this still does not work at
all.
(I tested this against a MPEG-2 Transport Stream file streamed by the
"LIVE555 Media Server" <http://www.live555.com/mediaServer/>, with the
file indexed to support trick play.)
I found that 'trick play' operations do not work at all. In particular,
the 'faster' and 'slower' controls have no effect (other than displaying
"faster" and "slower" in VLC's display). No new RTSP "PLAY" commands are
sent at all.
Similarly, I could not seek within the stream at all (by trying to drag
the playback diamond).
And pausing works at the GUI, but doesn't actually cause a RTSP "PAUSE"
command to be sent, so it's not actually pausing the network stream.
What's going on here? Why was "RTSP Trickplay support" promoted as a
feature of VLC 1.0.0, when it doesn't work at all?

It is simple:
in VLC we enable trickplay support for rtsp (pause/seek/fast forward/backward)
if and only if the play time is known, that is if p_sys->ms->playEndTime()
returns a non zero values. It's the only pseudo reliable way to detect VOD
that I know of).

Unfortunatly, using live555MediaServer and the live555 library (even
with the ts index), it is not the case. It is non zero at first (I think
after the initial setup), but is reset to zero latter. Probably because
all PLAY request returns:
Range: npt=0.000-
whereas the DESCRIBE request returns
a=range:npt=0-162.816
(on my test samples).


On rtsp from youtube, the server behaviour is different (it always return a complete
Range:) but then seek fails with:

Sending request: PLAY <url> RTSP/1.0
CSeq: 7
Session: 26fb8e9c
Range: npt=41.820-
User-Agent: VLC media player (LIVE555 Streaming Media v2008.07.24)


Received PLAY response: RTSP/1.0 457 Invalid Range
CSeq: 7
Session: 26fb8e9c
Server: Google RTSP 1.0

for that one, I am not sure why (maybe a complete Range: is needed in the
request ?), but it's definitly not VLC fault here (The whole range is
npt=0.000-197.266).


With a darwin rtsp server, the few public URLs I have found where working.

Regards,

[Ross Finlayson]

Post by Laurent Aimar
in VLC we enable trickplay support for rtsp (pause/seek/fast
forward/backward)
if and only if the play time is known, that is if p_sys->ms->playEndTime()
returns a non zero values. It's the only pseudo reliable way to detect VOD
that I know of).
Unfortunatly, using live555MediaServer and the live555 library (even
with the ts index), it is not the case. It is non zero at first (I think
after the initial setup), but is reset to zero latter.

Ahh... Here's what's actually happening (with VLC 1.0.0 and the
"LIVE555 Media Server") in this case:

1/ The RTSP server returns a SDP description (in response to VLC's
RTSP "DESCRIBE" command), which contains a "a=range:" attribute
*with* an end time - e.g.

v=0
o=- 1247115776948082 1 IN IP4 192.168.0.4
s=MPEG Transport Stream, streamed by the LIVE555 Media Server
i=osbournes.ts
t=0 0
a=tool:LIVE555 Streaming Media v2009.06.02
a=type:broadcast
a=control:*
a=range:npt=0-45.277
a=x-qt-text-nam:MPEG Transport Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:osbournes.ts
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=control:track1


2/ VLC, in response, is sending a "PLAY" command *without* an end time:

PLAY rtsp://192.168.0.4:8554/osbournes.ts/ RTSP/1.0
CSeq: 12
Session: 1
Range: npt=0.000-
User-Agent: VLC media player (LIVE555 Streaming Media v2009.06.02)


3/ The RTSP server then sends back a "PLAY" response without an end time:

RTSP/1.0 200 OK
CSeq: 12
Date: Thu, Jul 09 2009 05:02:56 GMT
Range: npt=0.000-
Session: 1
RTP-Info:
url=rtsp://192.168.0.4:8554/osbournes.ts/track1;seq=4083;rtptime=4253405358


So, the real problem is that VLC - in step 2 - is sending a "PLAY"
command without an end time, despite the fact that the SDP
description (returned in response to "DESCRIBE") had a range end
time. "ms->playEndTime()" *should* be non-zero (because "*ms" was
created using the SDP description). Could you please check this??

(BTW, I believe that the server's action in step 3 is correct,
because it's just mirroring what the client asked. In any case,
that's not the problem - the problem is the lack of a range end time
in the client's "PLAY" request.)

[Rémi Denis-Courmont]

Post by Ross Finlayson
So, the real problem is that VLC - in step 2 - is sending a "PLAY"
command without an end time, despite the fact that the SDP
description (returned in response to "DESCRIBE") had a range end
time. "ms->playEndTime()" *should* be non-zero (because "*ms" was
created using the SDP description). Could you please check this??

If you want to play from beginning to the end, you should send 0-, not 0-end.

I think the problem is that we are not distinguishing the timespan of the
underlying media, obtained from the description from the timespan of the
current play request. I dunno if it is a VLC bug, live555 misdesign, or both.

Post by Ross Finlayson
(BTW, I believe that the server's action in step 3 is correct,
because it's just mirroring what the client asked. In any case,
that's not the problem - the problem is the lack of a range end time
in the client's "PLAY" request.)

Step 3 is correct indeed - but step 2 is correct as well.

[Ross Finlayson]

Post by Rémi Denis-Courmont

Post by Ross Finlayson
So, the real problem is that VLC - in step 2 - is sending a "PLAY"
command without an end time, despite the fact that the SDP
description (returned in response to "DESCRIBE") had a range end
time. "ms->playEndTime()" *should* be non-zero (because "*ms" was
created using the SDP description). Could you please check this??

If you want to play from beginning to the end, you should send 0-, not 0-end.

In this sentence, who do you mean by "you"?

If you mean that the client (VLC) is incorrect in
how it's sending the "PLAY" request, then that

Post by Rémi Denis-Courmont
Step 3 is correct indeed - but step 2 is correct as well.
I think the problem is that we are not distinguishing the timespan of the
underlying media, obtained from the description from the timespan of the
current play request. I dunno if it is a VLC bug, live555 misdesign, or both.

I don't really understand what you're saying
here. But, once again - to try to clarify -
here's what's currently going on (at both the
client and server ends).

0/ Client (VLC) -> Server
RTSP "DESCRIBE"

1/ Server -> Client (VLC):
RTSP "DESCRIBE" response, with (in SDP):
a=range:npt=0-45.277

2/ Client (VLC) -> Server
RTSP "PLAY" with:
Range: npt=0.000-


3/ Server -> Client (VLC)
RTSP "PLAY" response with:
Range: npt=0.000-


The problem seems to be that - in step 2/ - VLC
is not including a range end in its "PLAY"
request, despite the fact that
"ms->playEndTime()" *should* be non-zero (because
"*ms" was created using the SDP description).

Could someone please check:
- Whether VLC is getting a correct value
when it calls "ms->playEndTime()"?
- and, if so, Why it's not including this
in the subsequent "PLAY" request (and why it's
not doing 'trick play' properly.

[Rémi Denis-Courmont]

Post by Ross Finlayson

Post by Rémi Denis-Courmont

Post by Ross Finlayson
So, the real problem is that VLC - in step 2 - is sending a "PLAY"
command without an end time, despite the fact that the SDP
description (returned in response to "DESCRIBE") had a range end
time. "ms->playEndTime()" *should* be non-zero (because "*ms" was
created using the SDP description). Could you please check this??

If you want to play from beginning to the end, you should send 0-, not 0-end.

In this sentence, who do you mean by "you"?

I mean a given RTSP User Agent.

Post by Ross Finlayson
If you mean that the client (VLC) is incorrect in
how it's sending the "PLAY" request, then that

Post by Rémi Denis-Courmont
Step 3 is correct indeed - but step 2 is correct as well.

Uh? No. I am saying that sending "0-" is the correct way to play from
beginning to the end. Sending "0-xxx" means play from beginning to offset xxx,
which is semantically different. See also RFC2326 ?10.5:

(...) the server will first play (...) seconds 30 through the end. (...)

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-

So at step 2, VLC is behaving correctly. And then at step 3, the server has no
obligation to specify what the end is either:

For a on-demand stream, the server replies with the actual range that
will be played back. (...)

C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z

S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z

So if client requests 0-, I understand the server should reply 0- as well.

Hence, I infer VLC/live555 should not rely on the PLAY response to determine
the timespan of a media. That leaves the result of DESCRIBE as the only
option.

(Ideally, VLC would have some implement some kind of progress bar, even when
it does not know the length of a _seekable_ media. Currently, it will show the
length as 00:00 and the UIs will prevent seeking completely.)

[Laurent Aimar]

Hi,

Post by Rémi Denis-Courmont
(Ideally, VLC would have some implement some kind of progress bar, even when
it does not know the length of a _seekable_ media.

That's a bit difficult without knowing the length and/or the current
position. How to you translate the user clicking somewhere into a position ?
Beside, with rtsp you never know when you can seek or not (unless I missed
something in that wonderfull RTSP RFC).

[Rémi Denis-Courmont]

Post by Laurent Aimar
Hi,

Post by Rémi Denis-Courmont
(Ideally, VLC would have some implement some kind of progress bar, even
when it does not know the length of a _seekable_ media.

That's a bit difficult without knowing the length and/or the current
position. How to you translate the user clicking somewhere into a position
? Beside, with rtsp you never know when you can seek or not (unless I
missed something in that wonderfull RTSP RFC).

There are two completely separate problems. The scale/UI design is one issue.
Of course, it will be clumsy and RTSP servers should really specify the media
length in the description.

Handling the failure to seek is another one. But I think that we can already
cope with as the demux can do whatever it wants with the seek point, no?

[Laurent Aimar]

Post by Rémi Denis-Courmont

Post by Laurent Aimar
Hi,

Post by Rémi Denis-Courmont
(Ideally, VLC would have some implement some kind of progress bar, even
when it does not know the length of a _seekable_ media.

That's a bit difficult without knowing the length and/or the current
position. How to you translate the user clicking somewhere into a position
? Beside, with rtsp you never know when you can seek or not (unless I
missed something in that wonderfull RTSP RFC).

There are two completely separate problems. The scale/UI design is one issue.
Of course, it will be clumsy and RTSP servers should really specify the media
length in the description.
Handling the failure to seek is another one. But I think that we can already
cope with as the demux can do whatever it wants with the seek point, no?

With "Playback->Jump to specific time", the request will go up to the demuxer
even if the length is zero. So the core and the gui already have a way to seek
without length.

The problem is only a GUI problem. Without a way to convert from a slider
position to an absolute time (for RTSP) I don't see how we can seek.
Beside, for a better interface usage, detecting when we can seek is a plus,
we actually use the fact that a length is returned to detect that for rtsp.

Now, I have commited something that should fix most of the problem: VLC now
ignores the end time in PLAY requests if it is 0 (and so we fall back to the
one retreive in SETUP).

[Glen Gray]

Post by Laurent Aimar

Post by Rémi Denis-Courmont

Post by Laurent Aimar
Hi,

Post by Rémi Denis-Courmont
(Ideally, VLC would have some implement some kind of progress bar, even
when it does not know the length of a _seekable_ media.

That's a bit difficult without knowing the length and/or the current
position. How to you translate the user clicking somewhere into a position
? Beside, with rtsp you never know when you can seek or not
(unless I
missed something in that wonderfull RTSP RFC).

There are two completely separate problems. The scale/UI design is one issue.
Of course, it will be clumsy and RTSP servers should really specify the media
length in the description.
Handling the failure to seek is another one. But I think that we can already
cope with as the demux can do whatever it wants with the seek
point, no?

With "Playback->Jump to specific time", the request will go up to the demuxer
even if the length is zero. So the core and the gui already have a way to seek
without length.
The problem is only a GUI problem. Without a way to convert from a slider
position to an absolute time (for RTSP) I don't see how we can seek.
Beside, for a better interface usage, detecting when we can seek is a plus,
we actually use the fact that a length is returned to detect that for rtsp.
Now, I have commited something that should fix most of the problem: VLC now
ignores the end time in PLAY requests if it is 0 (and so we fall back to the
one retreive in SETUP).

That's great fenrir, thanks.

Any comments on my earlier question with regards to the set rate in
the demux explicitly excluding kasenna servers ?

--
Glen Gray
<slaine at slaine.org>

[Laurent Aimar]

Any comments on my earlier question with regards to the set rate in the
demux explicitly excluding kasenna servers ?

I have no idea, I have never worked with kasenna server.

[Glen Gray]

Post by Laurent Aimar

Any comments on my earlier question with regards to the set rate in the
demux explicitly excluding kasenna servers ?

I have no idea, I have never worked with kasenna server.

Seems it's been there since you're original reworking of my trickplay
patch set

http://git.videolan.org/gitweb.cgi?p=vlc.git;a=commit;h=328b47a8955037be12efcac4d063af6c67875df8

I'll build up a new version of my 1.0 rpm and do some further testing
tomorrow.

Thanks everyone involved for taking the time to discuss and
investigate these issues.

Cheers,
--
Glen Gray
<slaine at slaine.org>

[Glen Gray]

Post by Rémi Denis-Courmont
Hence, I infer VLC/live555 should not rely on the PLAY response to determine
the timespan of a media. That leaves the result of DESCRIBE as the only
option.
(Ideally, VLC would have some implement some kind of progress bar, even when
it does not know the length of a _seekable_ media. Currently, it will show the
length as 00:00 and the UIs will prevent seeking completely.)

Unfortunately this puts us right back at the same impasse
--
Glen Gray
<slaine at slaine.org>

[Rémi Denis-Courmont]

Post by Glen Gray

Post by Rémi Denis-Courmont
Hence, I infer VLC/live555 should not rely on the PLAY response to determine
the timespan of a media. That leaves the result of DESCRIBE as the only
option.
(Ideally, VLC would have some implement some kind of progress bar,
even when it does not know the length of a _seekable_ media.
Currently, it will show the length as 00:00 and the UIs will
prevent seeking completely.)

Unfortunately this puts us right back at the same impasse

If the server does not specify the media duration in the SDP, I think it's
acceptable for VLC not to seek.

Doing a PLAY "0-end" instead of "0-" would screw up live timeshiftable medias,
so I am really against that change.

[Glen Gray]

Post by Rémi Denis-Courmont
Hence, I infer VLC/live555 should not rely on the PLAY response to determine
the timespan of a media. That leaves the result of DESCRIBE as the only
option.
(Ideally, VLC would have some implement some kind of progress bar, even when
it does not know the length of a _seekable_ media. Currently, it will show the
length as 00:00 and the UIs will prevent seeking completely.)

Unfortunately this puts us right back at the same impasse
--
Glen Gray
<slaine at slaine.org>

[Glen Gray]

Post by Ross Finlayson

Post by Laurent Aimar
in VLC we enable trickplay support for rtsp (pause/seek/fast
forward/backward)
if and only if the play time is known, that is if p_sys->ms-

Post by Laurent Aimar
playEndTime()

returns a non zero values. It's the only pseudo reliable way to detect VOD
that I know of).
Unfortunatly, using live555MediaServer and the live555 library (even
with the ts index), it is not the case. It is non zero at first (I think
after the initial setup), but is reset to zero latter.

Ahh... Here's what's actually happening (with VLC 1.0.0 and the
1/ The RTSP server returns a SDP description (in response to VLC's
RTSP "DESCRIBE" command), which contains a "a=range:" attribute
*with* an end time - e.g.
v=0
o=- 1247115776948082 1 IN IP4 192.168.0.4
s=MPEG Transport Stream, streamed by the LIVE555 Media Server
i=osbournes.ts
t=0 0
a=tool:LIVE555 Streaming Media v2009.06.02
a=type:broadcast
a=control:*
a=range:npt=0-45.277
a=x-qt-text-nam:MPEG Transport Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:osbournes.ts
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=control:track1
PLAY rtsp://192.168.0.4:8554/osbournes.ts/ RTSP/1.0
CSeq: 12
Session: 1
Range: npt=0.000-
User-Agent: VLC media player (LIVE555 Streaming Media v2009.06.02)
RTSP/1.0 200 OK
CSeq: 12
Date: Thu, Jul 09 2009 05:02:56 GMT
Range: npt=0.000-
Session: 1
RTP-Info: url=rtsp://192.168.0.4:8554/osbournes.ts/
track1;seq=4083;rtptime=4253405358
So, the real problem is that VLC - in step 2 - is sending a "PLAY"
command without an end time, despite the fact that the SDP
description (returned in response to "DESCRIBE") had a range end
time. "ms->playEndTime()" *should* be non-zero (because "*ms" was
created using the SDP description). Could you please check this??

I was working on this area the other day actually, to enable support
for Anevia VOD servers on our dated version of VLC. What's happening
is that the live555 RTSP libraries are re-parsing the end time from
the Range: header from the Play response. This is needed for the case
of an Anevia VOD server as for some reason, their SDP data is missing
the range attribute "a=range:npt=.....". They only send a Range:
header in the Play response.

So perhaps the answer is to patch live555 so that it only parses the
Range: header if it's subession's playEndTime is 0 ? If so, patch
attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playEndTime.patch
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090709/4ceb018b/attachment.obj>
-------------- next part --------------

--
Glen Gray
slaine at slaine.org

[Ross Finlayson]

First, Glen, *please* trim your responses!

Post by Glen Gray
So perhaps the answer is to patch live555 so that it only parses the
Range: header if it's subession's playEndTime is 0 ?

No, because the server might have decided - for whatever reason - to
stream only a subset of the range that the client requested. The
client needs to respect the range that the server specified in its
"PLAY" response, even if the client already thinks it knows the range.

But, as I noted earlier, the problem is occurring earlier, before VLC
sends "PLAY", when it is apparently not paying attention to the range
end that was specified in the SDP description.

[Laurent Aimar]

Post by Ross Finlayson
First, Glen, *please* trim your responses!

Post by Glen Gray
So perhaps the answer is to patch live555 so that it only parses the
Range: header if it's subession's playEndTime is 0 ?

No, because the server might have decided - for whatever reason - to
stream only a subset of the range that the client requested. The client
needs to respect the range that the server specified in its "PLAY"
response, even if the client already thinks it knows the range.
But, as I noted earlier, the problem is occurring earlier, before VLC
sends "PLAY", when it is apparently not paying attention to the range
end that was specified in the SDP description.

Actually, VLC never specify the range 'end' for PLAY requests. We can if it's
needed (I will check if it fixes youtube rtsp).

But, I am not sure it will fix the issue for every servers anyway. For example,
it seems valid to me for a server to answer Range: 'begin'- when
requested Range: 'begin'-'end' with 'end' equal to the media length.

[Glen Gray]

Been looking over the code in git and I think I see where I feel down
with my testing of this feature

1) I tested with liveMedia server which was already known not to work
2) I tested with Kasenna which seems to be explicitly disabled in
DEMUX_CAN_CONTROL_RATE
Any ideas why this was set like this ? Kasenna servers do support
the Scale feature ??

I've also tested against an Anevia server and it seems to work ok in
the faster mode but I can't seem to get it to go into rewind, slower
obviously doesn't seem right at a UI level and it does choose a < 1
value but not < 0 which is needed, i.e. Scale: -2.0. How does one
change to rewind ?

Cheers,
--
Glen Gray
slaine at slaine.org

[Laurent Aimar]

I've also tested against an Anevia server and it seems to work ok in the
faster mode but I can't seem to get it to go into rewind, slower
obviously doesn't seem right at a UI level and it does choose a < 1
value but not < 0 which is needed, i.e. Scale: -2.0. How does one change
to rewind ?

There is a dedicated button to switch betwen forward and backpard. You
probably need to add it using "Customize Interface" if it does not appears
by itself (it is called "Trickplay reverse").
Becarful, it will show up only when trickplay support is "detected" ie
when the length is > 0 (same condition than for seeking).

I have tested it with my lastest commit and it works with live555 server
at least.

[Glen Gray]

Post by Laurent Aimar

I've also tested against an Anevia server and it seems to work ok in the
faster mode but I can't seem to get it to go into rewind, slower
obviously doesn't seem right at a UI level and it does choose a < 1
value but not < 0 which is needed, i.e. Scale: -2.0. How does one change
to rewind ?

There is a dedicated button to switch betwen forward and backpard. You
probably need to add it using "Customize Interface" if it does not appears
by itself (it is called "Trickplay reverse").
Becarful, it will show up only when trickplay support is "detected" ie
when the length is > 0 (same condition than for seeking).
I have tested it with my lastest commit and it works with live555 server
at least.

Cool, thanks again.
--
Glen Gray
<slaine at slaine.org>

[Ross Finlayson]

Post by Rémi Denis-Courmont

Post by Ross Finlayson
So, the real problem is that VLC - in step 2 - is sending a "PLAY"
command without an end time, despite the fact that the SDP
description (returned in response to "DESCRIBE") had a range end
time. "ms->playEndTime()" *should* be non-zero (because "*ms" was
created using the SDP description). Could you please check this??

If you want to play from beginning to the end, you should send 0-, not 0-end.

Ah, OK - I think I see what you're saying now.
You're saying that you think that the client
(VLC) is *correct* in sending "0-" in its "PLAY"
request, even though the SDP in the "DESCRIBE"
response specified a range??

Mumble... I'm not sure about this. But, in the
spirit of "be conservative in what you send",
I'll go ahead and try changing our RTSP server
implementation to send back "0-<range-end-time>"
in its RTSP "PLAY" response, even in this case.
I'll see if this then makes VLC happy. Stay
tuned...

[Ross Finlayson]

Ah, OK - I think I see what you're saying now. You're saying that
you think that the client (VLC) is *correct* in sending "0-" in its
"PLAY" request, even though the SDP in the "DESCRIBE" response
specified a range??
Mumble... I'm not sure about this. But, in the spirit of "be
conservative in what you send", I'll go ahead and try changing our
RTSP server implementation to send back "0-<range-end-time>" in its
RTSP "PLAY" response, even in this case. I'll see if this then makes
VLC happy. Stay tuned...

OK, I've now modified the LIVE555 RTSP server implementation
(including the "live555MediaServer" application binaries) to be more
"liberal in what it accepts, and conservative in what it sends". In
particular, it now includes the complete range in its response to a
"PLAY" request, even if the client did not specify an end time.

VLC 'trick play' now works OK (pause, seek, fast-forward) when
streaming from a "LIVE555 Media Server". However:

1/ VLC never requests slower-than-normal play (i.e., 0<scale<1), no
matter how many times the user enters the 'slowet' command. I don't
know whether or not VLC is supposed to implement slower-than-normal
play.

2/ There doesn't seem to be any way in the VLC GUI to request reverse
play (scale<0). Again, I don't know whether or not VLC is supposed
to implement reverse play.

3/ There's definitely a remaining bug in the way VLC moves its
'diamond' cursor during fast-forward play. Note that the LIVE555
library has a function "getNormalPlayTime()" that returns a time that
could be used to set the cursor position. (This function returns a
correct play time, regardless of the value of 'scale'.) I see that
"modules_demux_live555.cpp" calls this function, but I don't know
whether or not it gets used to set the GUI cursor position.)