[MPlayer-dev-eng] MMS streaming

[Bertrand Baudet]

On Monday 03 December 2001 11:51 am, you wrote:
> Bertrand Baudet wrote:
> > On Thursday 29 November 2001 10:50 pm, you wrote:
> > > Hi,
> > >
> > > > MMS streaming is still buggy, I have a couple ideas why. I just need
> > > > to find some time to do it. And it still need some prebuffering code,
> > > > that it's not yet there.
> > > >
> > > > Mplayer can't play audio only track, I will also like to use mplayer
> > > > to stream some radio feed.
> > > > Is the audio only stream support in someone's TODO list? What need
> > > > to be changed to be able to support that?
> > >
> > > player core. as now video control everything...
> >
> > Would it be hard to change?
> > Is it planed to be done?
> >
> > > and for other formats (mp3 etc) also implementing new demuxers...
> >
> > Yes, but at least I would be able to test mms radio streaming, without
> > adding a new demuxer.
>
> Hello, everyone. I have found out that the file descriptor gets blocked
> when trying to read in the header for that particular MMS stream I'm
> trying out.

As I said before, the mms is not fully supported yet and I still have to
test the ideas I have to fix it. The first one is that the file size is not 
set properly, which make the stream end too early.
But anyway, I always good to have several links to test against, so
what's the URL you are using?

> After it reads the first part of the header,  it does print out the
> pragma lines fine. But, when it gets to the while loop that tries to
> complete the header, it gets blocked at the read() statement.  Other
> times, it  doesn't read anything. "i" returns 0.  This is strange
> because fd does get configured for 0_NONBLOCK in open.c.

I don't follow you! Are you talking about the connect2Server function
in network.c? If this is the case, I set the socket to non blocking
to be able to make a timeout while connecting to a server. After that
I put back the socket as blocking. Because of the cache system, it's
fine to have a blocking socket.
Which read() are you talking about? the one in http_read_response?
Humm, I would like to see that. Please give me the URL you are using
to test it.

> I can see that MMS does use HTTP requests for the initial connection
> attempt. But, once that part gets read in, http.c goes out the window. I
> think that we would need a completely new file for mms streaming.   I
> couldn't see any references to mms in the ASF specifications.  I'm
> trying to find out the format needed for MMS. (I think a new mms.c file
> may be in order). But, I am studying the asfr+_1.4
> (http://yaan2.yeah.net) source code. It seems that mms is binary. I'll
> keep studying that code some more.

I don't get it. Why do you want to do a mms.c? One way of doing MMS is
ASF over HTTP, you also have another way with pure TCP and/or UDP,
and also multicast, but this need some reverse engineering on the protocol. 
I might do that one day, but for now I want to fix the HTTP streaming first.
In mplayer case, I use MMS in the ASF over HTTP way, so you can't 
throw away the HTTP layer.
The HTTP code is working fine for me on all the stream I tested (no mms, but 
mpeg, avi...). And like I said MMS is not fully working yet because of other 
thing.
But sure if you point me out, were and why my HTTP code is bad for 
mms, I will be pleased to have a look at it.
FYI, I already done an mms implementation for the company I'm working for,
and I did it the same way, ie, HTTP as the transport layer for ASF and 
everything is working fine.
BTW, the format you are looking for is the described in asf.h in the 
ASF_stream_chunck_t structure. It's the encapsulation layer when ASF is
streamed over network.

Bertrand