[MPlayer-dev-eng] Re: Real rtsp:// support

[LThaler]

Is there any reason there would be trouble playing some rm files, but not
others (they are all the same revision)

-----Original Message-----
From: mplayer-dev-eng-bounces at mplayerhq.hu
[mailto:mplayer-dev-eng-bounces at mplayerhq.hu]On Behalf Of Ross Finlayson
Sent: Friday, April 18, 2003 4:33 PM
To: mplayer-dev-eng at mplayerhq.hu
Subject: [MPlayer-dev-eng] Re: Real rtsp:// support



>.ra (old Realaudio format) is not supported at the moment (both streams
>and files), just like the old codecs 14.4 and 28.8 they usually use. If
>you have files with .ra extension but rm format, please tell me and
>i'll add them. Anyway, i think .ra files are streamed with pnm:// urls.
>Do you know any rtsp url that streams an ra file?

Here's one:
         rtsp://rmlivev8.bbc.net.uk/farm/*/ev7/live24/bbc7/live/dsatg2.ra
(Of course, because of the "*" in the URL, you'll need to quote it on the
command line before trying to play it with MPlayer.)

>What kind of files can be received with live.com libraries?

You mean what kind of *streams*?  You can see a list at the bottom of my
web page at <http://www.live.com/mplayer/>.  Currently:
audio: MPEG-1 or 2 elementary streams (including layer III - i.e., "MP3");
MPEG-4 (AAC) audio; PCM (u-law or a-law); GSM; AC3; QCELP
video: MPEG-1, 2 or 4 elementary streams; H.263+; motion-JPEG
Also, some QuickTime generic RTP streams.  (Even more codecs (RTP payload
formats) will be supported in the future.)

>Is it possible to stream .rm files with standard rtsp protocol?

No, because the server (RealNetworks) refuses to let the client use
standard RTP streaming to receive such streams.  It returns an "unsupported
transport" error if the client tries to do this.

>I'd also like to remove the extension detection system, but i don't
>like the idea of trying every protocol (Real, live.com, and maybe more
>if other companies will implement their own variation of rtsp) until
>one succedes. Is it possible to send a very simple query to a rtsp
>server (i mean: open a port, send a string and  get a short, simply
>parseable answer) to find out its manufacturer or other unique
>identification?

In principle, you could try sending a RTSP "OPTIONS" request, and look at
the headers in the response (e.g., for a "Server:" header), but, in
practice, this is even less reliable than just looking at the URL
extension, because not all RTSP servers include a "Server:" header (and
there's no reliable way of telling from a "Server:" header whether or not
the stream is RealMedia).

A better solution would be to have this detection occur inside the LIVE.COM
code, because it's there that I know for sure whether or not the stream is
RealAudio or RealVideo.  I.e. we could try opening the URL with the
LIVE.COM code *first*, and then, if that code reports that it can't do it
(because the stream is RealAudio/RealVideo), we could try using your Real
rtsp:// code instead.

I'll look into doing this (I'll need to modify "rtsp_streaming_start()" to
return an appropriate error code if it detects that the stream is RealAudio
or RealVideo), and get back to you.  In the meantime, I suggest just
leaving the extension-based check in place.

         Ross.

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng at mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng