[MPlayer-dev-eng] about moving start= from rtsp://[...].r[ma] streaming to Range:

[Bernhard Kaindl]

On Sun, 3 Aug 2003, Roberto Togni wrote:
> On 2003.08.03 06:46, Bernhard Kaindl wrote:
> > Hi,
> >    I needed to start rtsp://-streamed realvideo&audio with some start
> > offset in the video clip like it's often used in .ram files like this
> ...
> > to start realplay playback at offset 51 min 02 sec into the
> > stream(e.g.)
...
> > So I think the patch should not have a problem to be included.
> >
> Looks good, but i think we should not remove the parameters from the
> url. Are you sure that the server never needs the parameters?

Oops, I didn't know that the servers are supposed to interpret this
query themselfes. The server from my test URL obviously had problems
with it.

I've added live-devel to the Cc list, Ross Finlayson from live.com
answered me there, I've added his reply below.

> Can you send an url where i can test it?

rtsp://elektra.mmmanager.org:554/sslug/BabyTux_020302083938_Masterfile01.rm?start="00:50:08"

My problem was that all my attempts to use mplayer with the start= query
sting this with this server failed.

If I passed the string with the quotes(") (just taken from an other example)
by quoting the string for the shell using (')-quotes, the server
apparently it failed to send any reply as response to all queries
this was constistent also with realplay failed, it ended up displaying
"Buffering..." virtually forever.

If I remove the (")-quotes, realplay worked, but with mplayer, the starttime
was ingored/not properly passed(maybe there are some problems with embedding
it with the other parameters which mplayer sends, no idea), at least the
server starts streaming at second 0 all the time.

Besides adding support for this simple xml file format, I could think that
the clip-begin value could be also passed using the -ss option to mplayer.

To support the start= URL even with such servers, and to have a quick and
easy means to set the start time I tried the initial patch, but as the
server should interpret the query strings, it seem to be not the right
thing to do.

I forwarded the last mail to live-devel:
> >   I sent the forwarded mail to mplayer-dev-eng, I guess it would
> >be handy to have similar URL/MRL parsing in LIVE.COM example programs
and Ross answered:
> No, because RTSP clients should not be parsing 'query' strings in "rtsp://"
> URLs.  Instead, it's left to the RTSP *server* to decide how to interpret
> these.  (See section 3.2 of the latest RTSP specification:
> <http://www.rtsp.org/2003/drafts/draft04/draft-ietf-mmusic-rfc2326bis-04.txt>)

Thanks, it says:
-----------------------------------------------------------------------------
rtsp_URL  =  ( "rtsp:" / "rtspu:" / "rtsps:" )
                "//" host [ ":" port ] [ abs_path [ "?" query ]]
   host      =  As defined by RFC 2732
   abs_path  =  As defined by RFC 2396
   port      =  *DIGIT
   query     =  As defined by RFC 2396 (Generic URI Syntax RFC(see ietf.org))

     Note that fragment and query identifiers do not have a well-
     defined meaning at this time, with the interpretation left to
     the RTSP server.
-----------------------------------------------------------------------------

I see. The whole query string should not be removed because it may contain
things which the server may want to interpret.

This change would only inside the realrtsp code and real.com describes
these query parameters:
http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm

There might be some, but I think one should be relatively save to only
move the start= and end= parameters from the query string to the "Range:"
parameter.

I think realplay would at least do something like this(to be
checked with tcpdump)

I also think using the standardized RTSP "Range:" parameter for the
begin- and end-time should be a safe bet which most servers should
provide, especially if the support repositioning of the stream playback.

I'm new to this, maybe I'm missing something more.

Bernhard