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

Ross Finlayson finlayson at live.com
Thu Aug 29 03:22:47 CEST 2002


> > >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 :-)


> > >Another questions:
> > >How do you easily add some field in the RTSP requests?
> > >like adding the User-Agent and other Pragma fields?
> >
> > Right now you would need to modify the RTSP client code (in the LIVE.COM
> > libraries) to do this.  However, I think it would be a good idea to allow
> > RTSP clients (such as "mplayer") to set the "User-Agent", so I'll try to
> > add support for this soon.
>
>Not only set the mplayer user agent, but also fake the WMPlayer user-agent for
>WMP9 soon to be released.

Does WMP use RTSP at all?? I thought it used only M$'s proprietary protocols?

>I also need to be able to set any kind of field in all RTSP requests
>(DESCRIBE, SETUP, PLAY...) on mplayer code side.

Why do you need to do this?  The RTSP client implementation (in the 
LIVE.COM libraries) should be setting the RTSP protocol fields 
correctly.  Apart from fields like "User-Agent" that are specific to the 
particular type of client, what RTSP field(s) do you want to be able to set 
or modify from the client, and why?

This is a serious question.  Note that the RTSP client functionality 
(implemented by the LIVE.COM libraries) are being used in many applications 
(not just "mplayer"), so I'm interested in learning if there's any need for 
a richer API to this code.

         Ross.




More information about the MPlayer-dev-eng mailing list