[MPlayer-users] about the mms:// support/problems Fwd: Re: Re: [MPlayer-dev-eng] [BUG] in mms support

[Arpi]

--------- Forwarded message ---------
From: Bertrand Baudet <bertrand_baudet at yahoo.com>
To: mplayer-dev-eng at mplayerhq.hu
Subject: Re: Re: [MPlayer-dev-eng] [BUG] in mms support

On Monday 13 May 2002 08:43 am, Arpi wrote:
> Hi,
>
> > > Unknown ASF streaming type
> > > Unknown protocol: mms
> > > asf_streaming_start failed
> > > Unable to open URL: mms://213.35.101.18/trance_medium
> > >
> > > Exiting... (End of file)
> >
> > IMHO mms support patch was never commited!
>
> hmm
> afaik there _IS_ mms:// support.
> the uncommited patch is about mmst://
> (don't ask the difference - i know 0 about this mms* stuff)

I tried the url with windows media player and couldn't get it to
work neither! 

The current support for mms in mplayer only use HTTP.
To have a full mms support in mplayer that will require
to have mmsu, mmst and http.

MMSU stand for MMS over UDP, the trouble with this
protocol is it only work for external IP people, firewall, NAT
and other gateway will drop the incoming UDP packets.

MMST is MMS over TCP, the protocol is the same as
mmsu but use a TCP connection instead. This should
allow to go through most of the firewall, but will not work
for people behind a http proxy.

The fall back protocol is HTTP, this one should be able
to go through most of the firewall/proxy/gateway.
That has nothing to see with a file download and play
back on the fly (aka progressive download). 
The server encapsulate ASF packets and send them
depending of their timestamps. 
The only drawback of this is that some MS admin don't
allow HTTP support in their MMS server. The http support
on the mms server is kinda tricky because mms servers
have to share port 80 with IIS. That's possible, you just need
to be aware of this and know how to do it...

So if you put a mms:// in front of your url it will use the same
protocol(http) as if you had put a http://, it will just avoid
a first standard http request to detect the server.

I didn't commit the mmst patch because it never worked
for me. This patch was a cut & paste from the xine mms 
support without the author credit (majormms) :( 
In addition this patch doesn't do sanity checks on 
network reading/writing, it just assums that read and write
always works...
All the values reading is done by bit shifting from a raw
char pointer no data structs, no endian handling, this
make it really hard to understand and maintain.
When I asked the guy that sent the pacth to do some clean up, 
he never came back to me, instead he gave the patch to Nick
for mplayerxp who put in it. 

I don't think it a good idea to commit this patch for now,
since it's still buggy, and it will override the use of the 
current working mms(http) support.

The current state of the reverse engineering of the
mmsu/mmst protocol is not fully complete, far less
complete(understood) than the http one.
Maybe an ifdef to enable/disable mmst support, but
I don't want to support the mmst code.  And since
the provider of the patch is not the author of the
mmst support, I doubt that we can ask him to do
some support.

If people want to try it I can send the patch to them.

Information about mmsu/mmst can be found at:
http://get.to/sdp and the xine mms plugin at:
http://geocities.com/majormms/

So in a few words, http support for mms should
work in most of the cases and will never work
for a badly configured mms servers.
mmst will enable to connect to those
badly configured servers only if we have a reliable
mmst implementation!

I hope that gave you a understandable overview
of mmsu/mmst/http.
If you have questions, fell free to ask ;)

Bertrand
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng at mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng