[MPlayer-users] asf mmst streaming problems

[Jake Benilov]

> >Hello,
> >
> >I've been trying to regularly "download" (dump to disk) WMV3 streams
> >off a website; here are a couple of example commands that i'm calling:
> >
> >mplayer -noframedrop -dumpstream -dumpfile "Daily Show - 2005.09.21 -
> >Stewart - Closer Look - Press Secretaries.wmv"
> >mms://a874.v99506.c9950.g.vm.akamaistream.net/7/874/9950/v001/comedystor.downlo
> >ad.akamai.com/9951/com/dailyshow/jon/jon_10119.wmv
> >
> >mplayer -noframedrop -dumpstream -dumpfile "Daily Show - 2005.09.21 -
> >Celebrity Interview - Ricky Gervais.wmv"
> >mms://a1740.v99506.c9950.g.vm.akamaistream.net/7/1740/9950/v001/comedystor.down
> >load.akamai.com/9951/com/dailyshow/celeb/celeb_10119.wmv
> >
> >Frustratingly, my downloads are frequently fail. Mplayer falls over
> >with the following message:
> >
> >read error:: Invalid argument
> >pre-header read failed
> >Core dumped ;)
> >
> >I tracked this message down in the code to
> >libmpdemux\asf_mmst_streaming.c
> >
> >I poked around further and hypothesised that the error has something
> >to do with a dropped connection to the server. I then tested a hunch
> >by repeating my download and disabling my network connection during
> >the process. And presto, I got the same message, and upon repeating it
> >I got the message:
> >
> >read error:: Invalid argument
> >media data read failed
> >Core dumped ;)
> >
> >(which is from the same function in the code).
> >
> >This all probably makes sense, because my internet connection is a bit
> >dodgy: it's shared amonst many people and also it's through a proxy;
> >as a result, it must drop out periodically.
> >
> >As a result of this "adventure", I have several requests/bug reports to make:
> >1) Is it possible to make the error message less cryptic? Users
> >shouldn't really have to dig through the source to figure out the
> >meaning of errors.
> >
> >2) These streams that I'm using are diagnosed as "not seekable".
> >However this isn't the case as windows media player (and other
> >programs) have no problems resuming from the failure point in the
> >video stream when the connection is dropped. If the streams could be
> >made resumable under MPlayer, then interruptions would not be so bad,
> >in the sense that the dumping could just proceed from that point, and
> >wouldn't have to be started again.
> >
> >3) If while viewing one of the above URLs, the user tries to seek
> >forward, Mplayer crashes.
> >
> >The "-v" output is included below. I'm running an AMD Athlon64 3000+
> >S939 under WinXP SP2; these problems manifest themselves under the
> >latest CVS build.
> >
> >Regards,
> >
> >Jake Benilov
> <snip>
>
>   Hi,
>
>   The "Stream not seekable!"  is normal, for most streams, and the "Core
>   dumped ;)" tells you only that it's finished (a joke the developers
>   slipped in :)).
>
>   If you check, you should have a file with the name you used for
>   -dumpfile. In the first case, the file contains these URLs (among
>   other things) :
>
> http://a1437.v99506.c9950.g.vm.akamaistream.net/7/1437/9950/v001/comedystor.download.akamai.com/9951/com/dailyshow/jon/jon_10116.wmv
> http://209.170.79.203:80/7/1437/9950/v001/comedystor.download.akamai.com/9951/com/dailyshow/jon/jon_10116.wmv
>
>   I had to trim some junk at the end of the URLs to get it to work, but
>   that should do it. I hope this makes sense, I'm running on too little
>   sleep. :)
>
>   Take care,
>   Steve
>

Steve, thanks for your reply, but:

1)
If the commands that I wrote don't work, that is down to the
differences between a windows and a POSIX command line (I was probably
a bit too liberal with using spaces in names which is a big no-no on
POSIX systems). They work under Windows; what may not be implicit from
my first post is that my "downloads" are successful about 50% of the
time (i.e. in the cases when my connection is stable). In the
remainder of cases, the errors I described happen.

2)
Yes I do realise that "stream not seekable" is a "normal" thing, but
when a stream that clearly *IS* seekable is flagged as not seekable,
that means two things:
a) The functionality to seek this particular type of stream has not
been coded in, or
b) It's an mplayer bug which misdiagnoses the type of stream

I simply want to bring this issue to the attention of MPlayer's
coders, so they can say which of the above situations is really the
case.

Thanks
Jake

p.s. I still don't really understand what kind of event the "core
dumped" message signifies. It doesn't imply a successful completion,
because it appears in the case when the dump fails. It doesn't signify
that mplayer has finished its business, because "Exiting... (End of
file)" signifies that. Is there any useful information that can be
inferred as a result of the appearance of that message?