silverlight   发布时间:2022-05-03  发布网站:大佬教程  code.js-code.com
大佬教程收集整理的这篇文章主要介绍了silverlight流媒体播放无法progressive download的BUG解决方案大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。

概述

现象: silverlight播放器播放同样的mp4,放到不同的流媒体服务器上,有的可以支持progressive download(边下边播,随机seek),有的不行(需要整个下载完了才能开始播放或者无法随机seek)。 解决方案: 修改流媒体服务器(http服务器)的配置,将返回的http header的版本号由http/1.0改为http/1.1 原因: silverlight的BUG,一直

现象:

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!!!!!!

大佬总结

以上是大佬教程为你收集整理的silverlight流媒体播放无法progressive download的BUG解决方案全部内容,希望文章能够帮你解决silverlight流媒体播放无法progressive download的BUG解决方案所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。