[MPlayer-dev-eng] MMS support in mplayer begun

[Bertrand Baudet]

On Friday 07 December 2001 12:44 pm, you wrote:
> Ok, That does make sense.  I have wiped out my changes and redownloaded
> the cvs tree.  I will modify asf_streaming_start function accordingly
> below.   I can make an enumerated type for mmsu, mmst, and then http in
> that order to make a switch statement work.  I don't know enough about
> UDP to do anything worthwhile there.  So, I will just make a stub for
> UDP for the time being, or simply return -1.

Ok, do you want to it, or do you want me to do it, so you can grab
it from CVS. In this way you will not have to patch mplayer. Then just
send me your new files and I will have a look and test them.

> As for the initial connection for MMST, I'm having to send the 01
> command (as per the MMS specs from the SDP web site).   Once that is
> sent, I'm having to immediately read the server response back in. So, I
> have to somehow parse the server's response to see if it was successful.
> I do know in the server response, if the player version is too low,
> there will be an URL to download the appropriate win32 DLLs. Should
> asf_mmst_streaming_start() just return -1 if that does happen?  Afaik,
> there is no mechanism to automatically install win32 codecs, no?

I don't quite understand. Do you mean that depending on the player version
number, the wms will return a list of codec to download if no present
localy, right?
There is no mechanism to download and intstall the win32 codecs, so
don't worry about this for now. We can add this later if it's really needed.
For now, just considere that the codec is already install, mplayer already
has a lot of win32 codec, so the probability to have to download a new
codec is really low.

Bertrand

> Bertrand Baudet wrote:
> > I didn't try the patch yet, I just read it. And I have few other
> > comments: - Please create a file called asf_mmst_streaming_start(). So
> > you will not have to change the asf_http_streaming_start() function.
> >   You will have also to create an asf_mmst_streaming_read() function,
> >   that desencapsulate the incoming stream.
> >   With those functions, it will be much more easier for me to integrate
> > it. You will have to call your asf_mmst_streaming_start() from the
> > asf_streaming_start function. Just comment the return line and put yours
> > for testing.
> >   The asf_streaming_start function is supposed to select the appropriate
> >   network streaming type. This function should first try mmsu, then mmst
> >   and then if they fail(because of firewall/proxy) it should try http.
> >   For now, what I can do, is having a simple switch on the protocol.
> >   I want keep mms doing http for now, so you can take the mmst for
> >   you test. I'm gonna add the switch in this function this week end.
> >   And I'm also gonna add the mmst entry in the network.c file.
> >
> > - Please try to not unindent my code, if some code are no indented and
> >   stick to the left, is because it's temporary and for debuging. It's
> > easier for me to find this code when it's not indented.
> >
> > - Why are you changing the open.c file? I don't understand why you are
> >   trying to pass the address of the stream pointer? In addition the I
> > don't see changes for the streaming_start declaration, so I will break
> > the current implementation.
> >
> > See below for more...
> >
> > On Thursday 06 December 2001 11:28 am, you wrote:
> > > BTW, I only currently have my section of code parsing URLs (like
> > > mms://server/blah). The HTTP code was modified by me, but this patch is
> > > not intended to make it to CVS yet. The functionality of HTTP code
> > > still works without any additional changes.
> > >
> > > Currently, the format for the URLs (mplayer mms://server/blah). I just
> > > have my section making an initial connection and returning the servers
> > > initial response.  The 4.1.3865 indicates it likes the player version.
> > > I had to set the player version to 6.4.1 to keep the stream (and the
> > > server) I'm testing happy.
> >
> > I don't quite understand. Are you sending an HTTP request? For what I
> > know, mmst doesn't need a HTTP handshake. So please make you code cleaner
> > according to what I told you at the beginning of this email and in my
> > previous emails. Thanks.
> >
> > Bertrand