On Sat, Jun 05, 2010 at 11:59:23AM -0700, Alun Jones wrote: > Reimar D?ffinger [mailto:Reimar.Doeffinger at gmx.de]: > > > > On Sun, May 30, 2010 at 08:10:49AM -0700, Alun Jones wrote: > > > Please let me know if there's anything I'm doing wrong, if this is a > > > fundamental limit set at the server, or something else entirely. > > > > Something in-between. MMS is indeed designed to only produce data > > in realtime, however there seem to be some tricks to convince it to > > do it faster. However MPlayer does not use these tricks, and actually > > I don't even know nay details how they work (I think something like > > telling > > the server that the client is still trying to buffer). > > It'd be interesting to know what the level of effort is in making these > happen. > > Would this document help? > > http://msdn.microsoft.com/en-us/library/cc251059.aspx It's from Microsoft, so what do you guess? Completely useless, it does not even properly document the meaning of the fields, and it certainly does not document the very specific (and often strange) behaviour of their servers. To be honest I actually think the possibility to download faster that realtime would acually be considered a bug, so it's possible it is not possible at all for this use-case, I just remember that some people managed in the past. If seeking is supported in priniple it should also be possible to start multiple downloads at different offsets and then stitch together the resulting files, but since I expect it to be around several full working days of effort to implement any solution I at least am not at all motivated to work on it.
