[MPlayer-dev-eng] ASF Streaming

Bertrand Baudet bertrand_baudet at yahoo.com
Mon Dec 17 20:30:36 CET 2001


On Monday 17 December 2001 08:56 am, you wrote:
> Hi,
>
> > > almost done ?
> > > it means it's usable? i'm currently working on -loop and precache
> > > stuff...
> >
> > 	I can say yes, there is just one issue with the prercorded stream. They
> > don't end, it's freezze on the last frame but it's minor and will soon be
> > fixed. Another is that on my old box (K6-2 333) some live stream play
> > strangly but giving a fixed fps solve this perfectly (Ex : BBC World in
> > 300Kb mms://216.106.173.141/v2/onair/BBC/BBCworld_300k.asf play fine with
> > -fps 30 but without it's unwatchable). I don't think this issue is
> > related to the streaming.
> >
> >  I have also a question, the asx files can be some sort of playlist.
> > First we will use only the first entry and ignore the others. But after
> > there must be a way to pass all the entry to the file list. Perhaps that
> > putting the asx parser in libmpdemux isn't a so good idea (OK first it
> > must be done ;·)) to achive this. Any proposition would be apreciated
> > here.
>
> Agree. It should be handled at outside, where playlist and multifile
> support (mplayer.c). Maybe an independent asx parser function can go to
> libmpdemux, but it should be called from outside. just like other utility
> functions used by mencoder and other tools.
> (libmpdemux is more than a demuxer, it contains some usefull functions to
> parse or create various media files)
>
> btw, just commited initial precaching.
> wanted to test with http:// downlaod-like streaming of .mpg file, but i
> always get:
>
> Playing http://mphq/MPlayer/samples/MPEG-VOB/dallas.mpg
> Connecting to server mphq:80 ...
> protocol: HTTP/1.1
> http minor version: 1
> uri: (null)
> method: (null)
> status code: 200
> reason phrase: OK
> Fields:
>  0 - Date: Mon, 17 Dec 2001 17:00:43 GMT
>  1 - Server: Apache/1.3.22 (Unix) Debian/GNU PHP/4.1.0RC1
>  2 - Last-Modified: Thu, 03 May 2001 12:10:00 GMT
>  3 - ETag: "c8031-57d004-3af14a98"
>  4 - Accept-Ranges: bytes
>  5 - Content-Length: 5754884
>  6 - Connection: close
>  7 - Content-Type: video/mpeg
> Content-Type: [video/mpeg]
> Content-Length: [5754884]
> Connected to server: mphq
> Connecting to server mphq:80 ...
> Content-Type: [video/mpeg]
> Content-Length: [5754884]
> streaming_bufferize
> Unable to open URL: http://mphq/MPlayer/samples/MPEG-VOB/dallas.mpg
>
> Exiting... (End of file)
>
> I think it's broken by latest asf/mms patches, as it worked about a month
> ago.

It's working for me. Maybe the commit I made this week end fixed it.
Can you try with today version of CVS and let me know if it's still broken
for you.

> Also note, the above log seems to mplayer now opnes the connection twice,
> but second time it fails somehow (maybe as it didn't parsed asf header at
> first connection???)

Yes, there are 2 connections made. The first connection is to attempt to 
detect what kind of streaming to use, this response to this request will
content the mime-type. Depending on the another connection is made
using the appropriate protocol. In the case of progressive streaming
(from an HTTP server) the same request is made and kept open.
Sure an optimization on this can be done. But for now I want
make everything working to turn the streaming ON by default so
every body can enjoy this long time waiting feature :)

Bertrand


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




More information about the MPlayer-dev-eng mailing list