silverlight流媒体播放无法progressive download的BUG解决方案

最新推荐文章于 2019-09-23 22:30:29 发布

码农CGGG

最新推荐文章于 2019-09-23 22:30:29 发布

阅读量1.1k

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/rcfalcon/article/details/40650339

探讨了Silverlight播放器在不同流媒体服务器上的表现差异，指出通过将HTTP头版本从1.0升级到1.1可以解决播放器无法进行边下边播的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

现象：

silverlight播放器播放同样的mp4，放到不同的流媒体服务器上，有的可以支持progressive download（边下边播，随机seek），有的不行（需要整个下载完了才能开始播放或者无法随机seek）。

解决方案：

修改流媒体服务器（HTTP服务器）的配置，将返回的http header的版本号由http/1.0改为http/1.1

原因：

silverlight的BUG，一直未修复，见MSDN上的讨论：https://social.msdn.microsoft.com/Forums/silverlight/zh-TW/441623fd-a5cf-41bd-9c63-9da6c9cebffb/about-the-buffer-of-silverlight-progressive-download?forum=silverlightmedia

OK I've made more progress on this.

Turns out that its an Accept-Ranges vs HTTP/1.0 header issue.

Good: If the server returns a response to an http/1.1 request with an http1.1 response header containing the Accept-Ranges as bytes, then everything works fine and seeking in a progressively download file rocks.

Bad: If the server returns a response to an http/1.1 request with an http1.0!!!! response header but the 1.0 header still contains the Accept-Ranges as bytes, Silverlight assumes the 1.0 header means that the Accept-Ranges field will not be in the header and therefore never looks for it and therefore it never makes any more http request when the seek is occurs. This is exactly what cloudfront is doing and it's not going to change because it's perfectly legal to return a 1.0 header from a 1.1 request but contains 1.1 fields. https://forums.aws.amazon.com/message.jspa?messageID=166533

So I declare this as a Silverlight bug!!!!!!