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

[Ross Finlayson]

>.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.