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

[Bertrand Baudet]

On Thursday 29 August 2002 10:37 am, Ross Finlayson wrote:
> > > > > >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.

Ah, that's not so bad ;)

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

Yes I have seen that. 
Like Alex suggested, you should provide a LIVE_VERSION macro that
can be used at compilation time to use the proper version of the LIVE API.
That help a lot to avoid bug report on broken compilation because of not
up-to-date extern lib dependencies.
Can you add this in your liveMedia.hh file for example?

something like this can do the job:
#define  LIVEMEDIA_VERSION(maj,min,micro)  ((maj)*10000 + (min)*100 + (micro))
#define   LIVEMEDIA_VERSION      DVDREAD_VERSION(0,9,0)
#if  LIVEMEDIA_VERSION >=  LIVEMEDIA_VERSION(0,9,0)

Please do something like this so I can commit your patch, thanks.

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

Argh, another mailing, ok, ok. I will subscribe to it too.

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

Yes, darwin use the standard IETF RTSP to request RTSP RTP/UDP but when
it comes to go through firewall, they implemented there own version.
They use RTSP/HTTP, they have 2 connections open, one HTTP GET and
one HTTP POST. You will see first a regular HTTP request and then inside
the HTTP GET, they will send the RTSP request encoded in base64 where the
response will be sent in the HTTP POST connection in base64 as well.
Then they will use the regular interleaved header as specified in the RFC.
Actually, I have play with darwin and QT for 2 years, so I don't know if they
fix the protocol with QT6!

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

Yes, I have seen that, I already tried to reverse there challenge-key crap, 
but gave up quickly...

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

Yes, actually I already know most of this. I was just trying to show the fact
that people will maybe need to add some additional fields in the transaction
and it will be a good idea to have such access in you RTSP lib.

Anyway, I will subscribe to the LIVE mailing list and move the thread on this
over there.

Bertrand