[Live-devel] I have some problems about using liveMedia to develop a rtsp server

[Ross Finlayson]

At 09:34 PM 6/15/04, you wrote:
>It seems that the example "testOnDemandRTSPServer" does not support "PAUSE"
>,and "PLAY" from a special time point?
>When a RTSP Client send a "PAUSE" command to the server,the server still
>continues to send stream data

No, the RTSP "PAUSE" command is working OK in 
"testOnDemandRTSPServer".  However, the "MPlayer" and "VLC" media player 
clients currently do not send this command - even when the 'pause' button 
is clicked.  (QuickTime Player does the right thing, however.)

>  also the client
>send a "PLAY" command with an option "a=range:npt=120.000-180.000",the
>stream is always played from the beginning(npt=0).

That's correct.  Seeking within a stream (file) is not currently implemented.

>So I want to implement these functions, where should I begin?

You may find this message from last April useful: 
<http://lists.live.com/pipermail/live-devel/2004-April/000661.html>

>  And How can I get the play time range of a stream(For example a mp3 file)?

There's no general way to do this, because it depends on the type of 
file.  Even for MP3 files this can be difficult to figure out, if the file 
is VBR (variable bit rate), because for VBR files you can't figure out the 
file's duration just from its size.

This, by the way, illustrates why RTSP 'trick mode' operations (seeking, 
fast-forward, rewind) are difficult to implement.  The protocol part of 
this is relatively easy.  What's difficult is indexing into the input file 
to actually perform the operations (at the server end).  There's no general 
way to do this.  That's why any implementation of this is not going to 
automatically work for all media types.  There is going to have to be at 
least some special, media-specific support for each media type.

FYI, I am currently talking with a potential customer about possibly 
implementing basic support for RTSP 'trick mode' operations (with specific 
support for a few media types) sometime in the near future.  (But it's not 
certain yet that this will happen.)


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>