[MPlayer-dev-eng] [PATCH] http1 to ingore DEMUXER_TYPE_ASF unconditionally

[Zuxy]

Hi,

libmpdemux/asf_streaming.c:asf_http_streaming_type contains asf mime
types not listed in libmpdemux/network.c:mime_type_table[], so
STREAM_HTTP(1) might treat those unlisted (for example
application/x-mms-framed) as raw http data and would not give
STREAM_ASF a chance to try.

My suggestion is to avoid duplicated mime types in mime_type_table[]
and asf_http_streaming_type by removing them from network.c so we can
maintain one thing instead of two, and STREAM_HTTP(1) should never
handle contents that lack proper information in the Content-Type
field. Anyway we still have STREAM_HTTP(2) :-)

Now the code should correctly handle the following cases (not until
recently have I found out that there are so many different asf server
configurations in the world!):

1. Urls that begins with http or mms, with Content-Type set correctly,
go STREAM_ASF.
2. Urls that begins with http or mms, with Content-Type set
incorrectly or null, raw asf data, go STREAM_HTTP(2).

But still it can't handle this extremely ridiculous configuration yet;
I'm working on it (or should mplayer support it?):
3. Urls that begins with http, with no http header at all (without
even the status code 200), raw asf data.

Windows Media Player can handle all of the above.

Maybe the patches are more explanatory:-)
--
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http.c.diff
Type: application/octet-stream
Size: 1065 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20051013/3d3572f3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network.c.diff
Type: application/octet-stream
Size: 651 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20051013/3d3572f3/attachment-0001.obj>