EE4：EE4播放器模板中的比特率切换（CPU启发式）问题 [英] EE4: Bitrate switching (CPU Heuristics) problems in EE4 player templates

问题描述

我遇到了EE4播放器模板中比特率切换的严重问题。 6月，Henrik Dahl问道："为什么我会得到一个非常低的比特率？" （ http://social.expression.microsoft.com /论坛/ en-US /编码/线程/ 836e84db-6c80-4aba-9c10-694c3799a502 ）
这似乎与我看到的问题相同。

Intel Core 2 Duo，P7450 @ 2.13 GHz，8 GB RAM，2008 R2 64位，一切都是最新的，屏幕分辨率1920x1200

720p体验流畅的流媒体 - 完美播放 - CPU @ ~85-90％

http://www.iis.net/media /体验平流

http://cdn.videoready.com /test/question/experience1.jpg - 比特率图

图片显示了播放上面的流时的比特率图。它在不到10秒的时间内达到2.75M并在播放期间保持一致，当我在1920x1200全屏运行时。

1080p体验流畅的流媒体 - 尽管播放完美但CPU @ ~98-99％

http://www.iis.net/media/体验平衡流1080p

http://cdn.videoready.com/ test / question / experience2.jpg - 比特率图表

它可以快速达到4.93M并且大部分时间都停留在那里并且播放顺畅

我的测试文件，用EE4预设H.264 720p CBR编码（ http://insinceu.ssod.llnwd.net/165mul/trailer-1280/Trailer-1280_122225082010.ism/Manifest ），
使用Silverlight Media Framework（smoothstreamingplayer-2.2010.0811.1）播放）：

http://cdn.videoready.com/test/question/trailer-720p .html

http://cdn.videoready.com /test/question/smf1.jpg - 截图

它相对快速地达到更高的比特率，保持一致并且播放流畅，CPU @ ~70- 85％。但是，与"体验流畅的流式传输"相比，自己达到最高比特率需​​要更长的时间。上面的链接。

所有这些测试表明我的电脑以最高质量播放这些流没有问题。

现在我们到达EE4模板似乎是灾难（EE3模板工作得很好！）...

这里使用EE4 Graphing模板播放上面相同的测试文件：

http://cdn.videoready.com/test/question/ee4-graphing /ExpressionEncoderMediaPlayerTestPage.html

http：//cdn.videoready .com / test / question / graphing1.jpg

http ：//cdn.videoready.com/test/question/graphing2.jpg

我目前正在使用Microsoft.Web.Media.SmoothStreaming.dll版本1.0.837.34 in SmoothStreaming.xap。

播放是一场灾难，它只能快速播放l owest或最低比特率旁边。在我看来，主要的罪魁祸首是浅绿色线，这意味着"估计下一个更高比特率下的CPU处理器负载"。根据

http://blogs.msdn.com/b/randyoakley/archive/2010/06/21/what-s-new-in-expression-encoder-4-player-templates.aspx 。上面的屏幕截图显示浅绿色线在顶部最大化。 Randy在那篇文章中进一步说

直浅绿线 - 估计CPU处理器负载"UP"阈值 - 如果"估计的CPU处理器在下一个更高的比特率下加载" line低于此值"CPU启发式"。将尝试播放下一个更高的比特率"

希望来自EE团队的人能够更好地理解图表。

我看到任何使用任何平滑流预设（H.264，VC-1，bframe 0或bframe 1等等）编码的文件都存在同样的问题。

问题：

1）有人可以解释一下并提供解决方案吗？

2）是否可以调整CPU启发式配置设置？使用EE3可以使用SmoothStreamingConfig.xml来调整启发式算法，但我不认为这个文件已经被使用了（Fiddler没有显示任何请求）？

3 ）为什么"体验流畅的流媒体"？与默认的SMF平滑流媒体播放器相比，链接提供了如此壮观的观看体验？它可以更快地发挥最高质量，并且在最高的
质量下回放看起来更加一致。是否有可能调整SMF启发式设置？

4）是否可以强制播放器在首次开始播放时跳到中等质量比特率并跳到另一个位置而不是从最低质量比特率开始？比如说，如果我希望至少90％的用户
能够正常播放800K，那么我希望玩家能够立即尝试800K而不是总是将比特率降低10％而不是总是从最低比特率开始。不确定它是否是一个好主意，但希望能够
尝试它。

谢谢，

Kurt Gronbech

 

解决方案

可以配置甚至禁用CPUHeuristic。 为此，需要重建Smooth Streaming MediaElement Shim。  这篇博文将告诉你如何做到这一点： 

http://blogs.msdn.com/b/randyoakley/archive/2010/06/23/how- to-update-expression-encoder-4-player-templates-to-use-an-updated-version-the-smooth-streaming-media-element.aspx

重建垫片之后 - 可以重新配置设置 - 在以下类的SmoothStreamingMediaElementShim.cs文件中查看

公共静态类配置

在该类中，可能会对以下属性感兴趣：

///开始限制比特率的处理器负载百分比

private static float sm_cpuMinPercent = 84.0F;

///允许增加比特率的处理器负载百分比

private static float sm_cpuUpPercent = 72.0F;

 

您也可以完全通过注释突出显示的行禁用CPUHeuristic：

        ///< summary>

        ///初始化SmoothStreamingMediaElementShim类的新实例

        ///< / summary>   


        public SmoothStreamingMediaElementShim（）

        {

            this.actualMediaElement = new SmoothStreamingMediaElement（）;

            // this.cpuHeuristic = new CPUHeuristic（this，this.actualMediaElement）;

           ;&NBSP; UserSetMinBitrate = ulong.MinValue;

            UserSetMaxBitrate = ulong.MaxValue;

            AttachEventHandlers（）;

        }

强制播放以中等值开始也是可能的 - 但有点棘手 - 一种可能有效的方法是添加对ApplyBitrateRange（）方法的调用将"最小比特率"设置为"在线"范围内的中间范围内的
。 manifestReady事件处理程序的代码路径。

protected void actualMediaElement_ManifestReady（object sender，EventArgs e）

"offline"事件处理程序中的代码路径调用ApplyBitrateRange（） - 因此，这将是复制该方法调用并以某种方式计算中间值的问题。 棘手的部分是找出何时在一个初始时间段后再次调用ApplyBitrateRange（）
来移除中档值，这样10％的低端机器用户不会试图发挥比特率机器无法处理。

顺便说一句 - 如果你创建一个自定义版本的垫片 - 几乎可以肯定你需要学习这篇博文来让它让你满意：

http://blogs.msdn.com/b/randyoakley/archive/2009/10/07/how-to-debug-expression-encoder-3-templates-with-smoothstreaming -content.aspx

I'm experiencing severe problems with the bitrate switching in the EE4 player templates. In June Henrik Dahl asked "Why do I get a really low bitrate?" (http://social.expression.microsoft.com/Forums/en-US/encoder/thread/836e84db-6c80-4aba-9c10-694c3799a502) which seems to be the same problem I am seeing.

Intel Core 2 Duo, P7450 @ 2.13 GHz, 8 GB RAM, 2008 R2 64-bit, everything fully up-to-date, screen resolution 1920x1200

720p Experience Smooth Streaming - Plays perfectly - CPU @ ~ 85-90%

http://www.iis.net/media/experiencesmoothstreaming

http://cdn.videoready.com/test/question/experience1.jpg - bitrate graph

The picture shows the bitrate graph when playing the stream above. It takes less than 10 seconds for it to work itself up to 2.75M and it stays there consistently during playback, when I run it fullscreen in 1920x1200.

1080p Experience Smooth Streaming - Plays perfectly although CPU @ ~ 98-99%

http://www.iis.net/media/experiencesmoothstreaming1080p

http://cdn.videoready.com/test/question/experience2.jpg - bitrate graph

It quickly works itself up to 4.93M and stays there for the most part and playback is smooth

A test file of mine, encoded with EE4 preset H.264 720p CBR (http://insinceu.ssod.llnwd.net/165mul/trailer-1280/Trailer-1280_122225082010.ism/Manifest), played back with Silverlight Media Framework (smoothstreamingplayer-2.2010.0811.1):

http://cdn.videoready.com/test/question/trailer-720p.html

http://cdn.videoready.com/test/question/smf1.jpg - screenshot

It relatively quickly works its way up to the higher bitrates, stays there consistently and playback is smooth, CPU @ ~ 70-85%. But it takes much longer to work itself up to the highest bitrate than the "experience smooth streaming" links above.

All of these tests show that my computer has no problem playing back these streams at their highest quality.

Now we arrive at the disaster that the EE4 templates seem to be (EE3 templates work just fine!)...

Here the same test file above is played with the EE4 Graphing template:

http://cdn.videoready.com/test/question/ee4-graphing/ExpressionEncoderMediaPlayerTestPage.html

http://cdn.videoready.com/test/question/graphing1.jpg

http://cdn.videoready.com/test/question/graphing2.jpg

I'm currently using Microsoft.Web.Media.SmoothStreaming.dll version 1.0.837.34 in SmoothStreaming.xap.

The playback is a disaster and it quickly plays only the lowest or next to lowest bitrates. It seems to me that the main culprit is the light green line which means "estimated CPU processor load at next higher bitrate" according to http://blogs.msdn.com/b/randyoakley/archive/2010/06/21/what-s-new-in-expression-encoder-4-player-templates.aspx. The screenshots above show that the light green line is maxing out at the top. Randy further says in that post that

Straight light green line - estimated CPU processor load "UP" threshold - if the "estimated CPU processor load at next higher bitrate" line is below this value the "CPU heuristic" will attempt to play the next higher bitrate"

Hopefully someone from the EE team can make more sense of the graphs.

I'm seeing the same issue with any files encoded with any of the Smooth Streaming presets (H.264, VC-1, bframe 0 or bframe 1, etc, doesn't matter).

Questions:

1) Can someone explain this and provide a solution?

2) Is it possible to tweak the CPU Heuristics configuration settings? With EE3 it was possible to use SmoothStreamingConfig.xml to tweak heuristics, but I don't think this file is used any more (Fiddler doesn't show any request for it)?

3) Why do the "Experience Smooth Streaming" links provide such a spectacular viewing experience compared to even the default SMF smooth streaming player? It works its way up to the highest quality much quicker and playback seems more consistent at the highest quality. Is it possible to tweak the SMF heuristics settings?

4) Is it possible to force the player to start plackback at a medium quality bitrate upon first starting play and after skipping to another location instead of starting at the lowest quality bitrate? Say for example that if I expect at least 90% of the users to be able to play 800K just fine then I want the player to try 800K immediatly and instead lower the bitrate down for those 10% with problems instead of always starting at the lowest bitrate. Not sure if its a good idea or not, but would like to be able to try it.

Thanks,

Kurt Gronbech

 

解决方案

The CPUHeuristic can be configured or even disabled.  To do so requires rebuilding the Smooth Streaming MediaElement Shim.   This blog post will tell you how to do that:  http://blogs.msdn.com/b/randyoakley/archive/2010/06/23/how-to-update-expression-encoder-4-player-templates-to-use-an-updated-version-of-the-smooth-streaming-media-element.aspx

Once you have a rebuilt shim -- it's possible to reconfigure the settings -- to do this look in the SmoothStreamingMediaElementShim.cs file for the following class

public static class Configuration

Within that class the following properties are likely of interest:

/// Percentage of processor load to start throttling the bitrate
private static float sm_cpuMinPercent = 84.0F;

/// Percentage of processor load to allow increasing the bitrate
private static float sm_cpuUpPercent = 72.0F;

 
You may also completely disable the CPUHeuristic by commenting out the highlighted line:

        /// <summary>
        /// Initialized a new instance of the SmoothStreamingMediaElementShim class
        /// </summary>   
        public SmoothStreamingMediaElementShim()
        {
            this.actualMediaElement = new SmoothStreamingMediaElement();
            //this.cpuHeuristic = new CPUHeuristic(this, this.actualMediaElement);
            UserSetMinBitrate = ulong.MinValue;
            UserSetMaxBitrate = ulong.MaxValue;
            AttachEventHandlers();
        }

Forcing the playback to start at a midrange value is also possible -- but a bit trickier -- one approach that might work would be to add a call to the ApplyBitrateRange() method that would set the minimum bitrate to something mid-range
from within the "online" code path of the manifestReady event handler.

protected void actualMediaElement_ManifestReady(object sender, EventArgs e)

The "offline" code path within the event handler has a call to ApplyBitrateRange() -- so it would be a matter of copying that method call and somehow calculating a midrange value.  The tricky part would be figuring out when to call ApplyBitrateRange() again after an intial time period to remove the mid-range value so the 10% of users with lower-end machines aren't stuck attempting to play bitrates their machines can't handle.

BTW -- if you create a customized version of the shim -- almost certainly you'll need to study this blog post to get it working to your satisfaction:

http://blogs.msdn.com/b/randyoakley/archive/2009/10/07/how-to-debug-expression-encoder-3-templates-with-smoothstreaming-content.aspx

这篇关于EE4：EE4播放器模板中的比特率切换（CPU启发式）问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！