[MPlayer-dev-eng] Re: RTSP/RTP streaming

[Ross Finlayson]

> > > > >To solve this issue the RFC 2326 specify in section 10.12 the
> > > > >"Embedded (interleaved) Binary Data".
> > > > >I'm was wondering if the LIVE library implement this part of the RFC?
> > > >
> > > > Not yet (the code currently has the ability to send RTP packets over
> > > > the TCP connection, but not yet receive such packets).  However, this
> > > > is on my "to do" list, and when I've implemented this, I'll add it to
> > > > the "mplayer" RTSP support.
> > >
> > >Do you have a ETA for that? (approximatly...)
> >
> > No not yet.  The updates to the LIVE.COM libraries that are the highest
> > priority (apart from serious bug fixes) are those that are requested by
> > paying clients.  (So, if your organization is interested in providing
> > funding for this work, please let me know :-)
>
>Eheh, unfortunatly not.
>But if you need help when you do the interleaved implementation,
>especially the QT one, I can give you some info.
>Anyway, you don't have any idea on the ETA, like >1month
>or <6months, something like that?

Probably closer to 1 month than 6 months.

> > > > >Another questions:
> > > > >How do you easily add some field in the RTSP requests?
> > > > >like adding the User-Agent and other Pragma fields?

FYI, I have now updated the RTSP client code to include "User-Agent:" lines 
in RTSP requests, and have submitted a mplayer patch that passes the 
application name ("mplayer" in this case) to this code.

>See the attach, that should give you a good idea on what Real and the new MS
>stuff do. Unfortunatly I don't have a QT session under my hand, but I'm
>guessing they have some extra field too. If you are interesting, I will try
>to make a QT RTSP UDP/TCP session so you can see the extra fields and
>the wierd way QT do the RTP/TCP.

Here, FYI, is some more information about how each of these use RTSP and RTP:

To begin, you should note that "mplayer" is far from the first use of this 
RTSP client code.  For instance, it has also been used in the "openRTSP" 
command-line RTSP client application, and in a RTP/RTSP input plugin (MP3 
streaming only) for "Winamp".  (I am also working on using it in the 
"videoLAN" media player, just as I did for "mplayer".)  So, any proposed 
changes to the RTSP client code would applicable to more than just 
"mplayer", and should best be discussed on the "live-devel" mailing list - 
see <http://lists.sourceforge.net/lists/listinfo/live-devel> to join this list.

Also, if you're testing out the capabilities of a RTSP server 
implementation, then you may find it more useful to use the "openRTSP" 
application <http://www.live.com/openRTSP/> for this, rather than "mplayer".

Apple (QuickTime):
==========
Fortunately, Apple's QuickTime Streaming Server (aka. Darwin Streaming 
Server) uses IETF standard RTSP, and no changes to the RTSP client code 
(such as new headers) are needed to access a stream from such a 
server.  However, as with all RTSP servers, it is possible for the 
resulting RTP streams - sent by the server - to use a *codec* (and 
associated RTP payload format) - that the RTSP client doesn't 
understand.  For example, if the stream is encoded using Sorenson Video, 
and/or the corresponding proprietary audio format (I forget, "QDM"?), then 
even though we can receive this data (in RTP packets), we can't do much 
with it.

RealNetworks:
==========
RealNetworks' RTSP servers can also be accessed by the existing RTSP client 
code, *provided that* the streams do not use their proprietary RealAudio 
and/or RealVideo codecs.  For example, the URL 
"rtsp://media.schreiner.edu/realmp3.mp3" - which can be played by "mplayer" 
- streams from a RealNetworks server, but using MP3 rather than RealAudio.

If, however, the stream uses the RealAudio and/or RealVideo codecs, then 
there are two incompatibilities.  First, such streams are usually not sent 
using the (IETF standard) RTP protocol, but, instead, using RealNetworks' 
proprietary "RDT" protocol.

Second, and more importantly, even if - as is likely - "RDT" can be reverse 
engineered, this will not be enough to stream RealAudio/RealVideo from a 
RealNetworks server, because the server also includes a cryptographic 
'challenge-response', test to ensure that only valid RealNetworks clients 
can start the stream.  In your example network dump, notice the various 
"Challenge" strings that are included in RTSP commands.  So, streaming 
RealAudio or RealVideo from a RealNetworks server - even if we support the 
codecs - will require figuring out how to make our own RTSP client (e.g., 
"mplayer") authenticate itself  to the server as if it were a legitimate 
RealNetworks client.

Microsoft (Windows Media):
==========
It's encouraging that 'Corona' apparently supports (at least a variant of) 
RTSP.  However, given how heavily Microsoft is promoting DRM bullshit, it 
seems almost inevitable that they, too, will use some sort of 
authentication scheme to ensure that only 'trusted' clients can access 
their servers' streams.  So, I'm not optimistic that it will be easy to 
stream from their servers...

I hope ths helps shed some light on the situation.

         Ross.