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

[Bertrand Baudet]

On Monday 10 December 2001 10:18 pm, you wrote:
> Bertrand Baudet wrote:
> > On Monday 10 December 2001 04:30 pm, you wrote:
> > > Bertrand Baudet wrote:
> > > > No, no. The network related include files need to stay in the network
> > > > files, just reinclude what you need in you c file.
> > > > See Arpi's previous post on the changes I made on the network include
> > > > files....
> > > >
> > > > Please, create new files for mmst and instead of putting all the enum
> > > > you created inside asf.h
> > > > Please read you patch before sending them, this one touch asfheader.c
> > > > by only adding 2 empty lines. And it also removed some lines in
> > > > tvi_dummy.c. You don't need to touch those files, so please make
> > > > cleaner patches. Maybe the simplier solution for you is to create
> > > > separate files for your needs and only touch the current file if
> > > > really needed.
> > >
> > > Ok, will do. I am having the most trouble with generating the patches.
> > > I will try the diff command again. (would be nice if the cvs rdiff
> > > command was working; oh well) I will update the tree again and will put
> > > in the mmst.h file this time. I have created a local directory on my
> > > own system with the changed files.
> >
> > I just commited few changes into asf_streaming.c for you.
> > In the asf_streaming_start(), just uncomment the line:
> > fd = asf_mmst_streaming_start( stream );
> > so you stuff can be called. I didn't toke you implementation,
> > because it wasn't trying the other protocols if the first one failed.
> >
> > You shouldn't need to change the current files for now, I tried in a way
> > that by just adding your file and changing the makefile, it should work.
> > This will avoid to have some conflict on the changes I doing and the
> > changes you are doing.
> > So just send me the files (no diff for you ;) ) so I can try them.
> > And if you need to have other changes send me a patch and a quick
> > explaination of it, and I will see what I can do for you.
> >
> > Let me know if this help you or not.
> >
> > Bertrand
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at mplayerhq.hu
> > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
> Hehe, thanks. It does help. I have moved my functions to mmst.c and the
> function prototypes to mmst.h.

Ok, good ;)

> I got the asf_mmst_streaming() function written.  I only have it send
> out the initial  connection request after opening a port to the server.
> I'm still studying the asf_http_streaming_read() to see how the chunks
> get read in and how they get sent to the demux.

Ok, it simple, just write your asf_http_streaming_read() function and set
its pointer to the streaming_strl->read variable. The function will be 
automatically called inside the demuxer.
Your read fuction should only remove the network encapsulation and return
the buffer. 
I need to check my read function, because I'm not checking the size I read 
from the network and the size that is in the network encapsulation.
I don't know if the encapsulation in your case is the same as the HTTP one.

> I am thinking of letting asf_mmst_streaming_read handle the different
> server commands received (including receiving the MMS header and the ASF
> header).

You shouldn't. Just write the handshake in the start function, so it the 
handshake fail, the start function will return -1 and the http protocol
can be tried.
Just return the fd from the start function once you're sure that the 
handshake is completed. 
In addition once the asf_streaming_start() function returned, the
cache system is start, and should prebufferize(not done yet).
Once it's started the first process will block on the network read,
and the second process is handling the reading the stream from the
cache and send it to the demuxer. 
If you're not doing the complete handsake in the start function,
everything should be changed again, and I don't want to that
if we can do another way.

> It seems that the server sometimes doesn't send out the headers out (at
> least from what I'm gathering from the asfrecorder source).  I will just
> setup a switch statement and let it process different commands as they
> come in.

I don't know if this can help: in the http protocol, 2 requests are made.
The first one is to request the ASF header. From this header, I need to
extract the list of streams(A/V) from the ASF file. I'm still working
on this part. Once the streams are extract, I can build the next request.
The goal of this is to take the stream that the player can only play.
Some ASF files can have several video streams. For what I guessed, 
those videos streams are the same in different bitrate. There is an 
object in the ASF header that list all the streams and there bitrates.
The second request list the streams that the client want/can receive.
The ASF header parser that is in mplayer for now is not really conveniant
to handle this, so I might have to write a new one.

I don't know if this help.

Bertrand


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com