CN116896577A - 串流自动降级控制方法、推荐分辨率及帧率获取方法 - Google Patents

Abstract

本发明公开一种串流自动降级控制方法、推荐分辨率及帧率获取方法，涉及云游戏技术领域，解决了云游戏串流时，一般根据网络状态降低串流码率，容易影响用户的使用体验的技术问题。该控制方法包括：检测用户端网络是否正常连通；检测到用户端出现黑屏；检测串流分辨率是否为标准分辨率；检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行，否则降级为WebRTC软解码串流；检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行，否则降级到WebSocket软解码进行串流。本发明进行WebRTC串流降级时，还会对用户端的网络连接、黑屏、分辨率进行检测处理，实现了对串流降级更为精准的控制，提升了用户的体验。

Description

串流自动降级控制方法、推荐分辨率及帧率获取方法

技术领域

本发明涉及云游戏技术领域，尤其涉及一种串流自动降级控制方法、推荐分辨率及帧率获取方法。

背景技术

云游戏是目前高速发展的一类游戏应用场景，通过把游戏逻辑放在远程服务器上，把图像/音频流传输到客户端，最大化了后端控制，前端工作量被降到最低。这个过程中，“串流”是实现云游戏的关键方式，通过数据中心将游戏渲染场景转换成视频流，再通过传输网络推送到用户终端显示。从而用户不必部署昂贵的高配PC或手机，通过网页访问或者扫描二维码的方式，即可享受细腻、清晰、流畅的高清视频体验和实时的操控效果。

在云游戏串流中，一般采用WebRTC (Web Real-Time Communications，网页实时通信) 技术，WebRTC是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。在串流中，当玩家网络状态良好时，云游戏服务器端会用较高的串流码率以达到更好的游戏画质；当玩家网络状态较差、带宽较低的时候，云游戏服务器端会进行降级处理，即降低串流码率从而保证低操作时延。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

云游戏使用WebRTC串流时，一般直接根据网络状态降低串流码率，难以对更复杂的场景进行适当处理，容易影响用户的使用体验。

发明内容

本发明的目的在于提供一种串流自动降级控制方法、推荐分辨率及帧率获取方法，以解决现有技术中存在的云游戏使用WebRTC串流时，一般直接根据网络状态降低串流码率，难以对更复杂的场景进行适当处理，容易影响用户使用体验的技术问题。本发明提供的诸多技术方案中的优选技术方案所能产生的诸多技术效果详见下文阐述。

为实现上述目的，本发明提供了以下技术方案：

本发明提供的一种串流自动降级控制方法，用于对游戏串流降级进行动态控制，包括以下步骤：S100：检测用户端网络是否正常连通，如是，执行S200，否则提示网络异常；S200：检测到用户端出现黑屏，且请求设定次数的解码立即刷新帧IDR仍未恢复；S300：检测串流分辨率是否为标准分辨率，如是，执行S400，否则将串流分辨率切换为标准分辨率后再执行S400；S400：检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行WebRTC硬解码串流，否则降级为WebRTC软解码串流；S500：检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行WebRTC软解码串流，否则执行S600；S600：降级到WebSocket软解码进行串流。

优选的，所述S300、S400步骤之间还包括以下步骤：S350a：检测是否出现WebRTC的超时流水上报、解码器为空或WebRTC的首次连接失败，如是，执行S600，否则执行S400。

优选的，所述S200步骤中，通过以下步骤进行黑屏的检测：S210：获取用户端显示画面的原始图片，并转换为灰度图；S220：设定灰度图中偏暗部区域的灰度值范围，计算灰度图的总像素及偏暗部区域的像素；S230：设定对比阈值，当偏暗部区域的像素与灰度图的总像素的比值大于对比阈值时，判断出现黑屏。

优选的，所述S200步骤中，还可通过以下方式判断用户端出现黑屏：当连续两次请求解码立即刷新帧IDR之后，接收到两次关键帧解析失败事件。

优选的，所述S400~S500步骤替换为：检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行WebRTC硬解码串流，否则，降低串流分辨率和/或帧率，再次检测WebRTC硬解码串流的关键帧解析是否成功，如是，按照降低后的串流分辨率和/或帧率执行WebRTC硬解码串流，否则降级为WebRTC软解码串流；检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行WebRTC软解码串流，否则，降低串流分辨率和/或帧率，再次检测WebRTC软解码串流的关键帧解析是否成功，如是，按照降低后的串流分辨率和/或帧率执行WebRTC软解码，否则执行S600。

优选的，所述S400、S500步骤中，还可以通过以下方法判断是否需要进行串流降级：S410：采集游戏运行时的连续多帧图像；S420：计算获取到的连续数帧图像中每相邻两帧图像的相似度；S430：根据每相邻两帧图像的相似度，得出游戏运行时的画面是否出现卡顿的结论，判断是否需要进行串流降级。

优选的，在采集游戏运行时的多帧图像时；当预设的采集频率大于等于游戏画面的帧率时，采用游戏画面的两相邻游戏帧图像进行相似度计算；当预设的采集频率小于游戏画面的帧率时，采用采集到的两相邻采集帧图像进行相似度计算。

优选的，所述S400、S500步骤中，在解析关键帧失败两次后请求一次解码立即刷新帧IDR，若新的关键帧还是未解析成功，则判定为关键帧解析失败。

优选的，当用户再次进入系统时，自动检测用户配置是否发生变化，若未发生变化直接采用上次串流降级结果执行串流降级。

一种推荐分辨率及帧率获取方法，用于获取云游戏的推荐分辨率及帧率，使用以上任一项所述的一种串流自动降级控制方法，包括以下步骤：S10：选择测试节点启动测试，得到当前节点的下载速率、丢包率、抖动时间和延迟时间；S20：判断所述下载速率是否超过速率阈值，如是，执行S30，否则，结束测试并提醒用户；S30：进行解码测试，根据所述下载速率、丢包率、抖动时间和延迟时间匹配初始分辨率及帧率；S40：获取解码测试的丢包率和延迟时间，判断丢包率和/或延迟时间是否超过设定阈值，若超过设定阈值，执行S50，否则将初始分辨率及帧率作为推荐分辨率及帧率；S50：通过所述串流自动降级控制方法进行降级，得到推荐分辨率及帧率。

实施本发明上述技术方案中的一个技术方案，具有如下优点或有益效果：

本发明对云游戏进行WebRTC串流降级时，还会对用户端的黑屏、网络连接、分辨率进行检测处理，实现了对串流降级更为精准的控制，同时，对WebRTC串流进行梯度降级，从而为用户匹配了最合适的串流方式，较现有的直接降低串流码率，适应了更复杂的工作场景，也明显提升了用户的体验。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍，显而易见，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，附图中：

图1是本发明实施例一的一种串流自动降级控制方法的流程图；

图2是本发明实施例一的黑屏检测的流程图；

图3是本发明实施例一的判断是否需要进行串流降级的流程图；

图4是本发明实施例二的一种推荐分辨率及帧率获取方法的流程图；

图5是本发明实施例二的一种推荐分辨率及帧率获取方法的示意图；

图6是本发明实施例二的一种推荐分辨率及帧率获取方法的各端运行示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，下文将要描述的各种示例性实施例将要参考相应的附图，这些附图构成了示例性实施例的一部分，其中描述了实现本发明可能采用的各种示例性实施例。除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。应明白，它们仅是与如所附权利要求书中所详述的、本发明公开的一些方面相一致的流程、方法和装置等的例子，还可使用其他的实施例，或者对本文列举的实施例进行结构和功能上的修改，而不会脱离本发明的范围和实质。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”等指示的是基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的元件必须具有的特定的方位、以特定的方位构造和操作。术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。术语“多个”的含义是两个或两个以上。术语“相连”、“连接”应做广义理解，例如，可以是固定连接、可拆卸连接、一体连接、机械连接、电连接、通信连接、直接相连、通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。术语“和/或”包括一个或多个相关的所列项目的任意的和所有的组合。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

为了说明本发明所述的技术方案，下面通过具体实施例来进行说明，仅示出了与本发明实施例相关的部分。

实施例一：如图1所示，本发明提供了一种串流自动降级控制方法，用于对游戏串流降级进行动态控制，包括以下步骤。S100：检测用户端网络是否正常连通，如是，执行S300，否则提示网络异常，网络是否正常连通是进程串流降级控制的前提，因此，首先需要对网络是否正常连通进行测试，检测方法可采用现有技术进行，如Ping命令测试等。S200：检测到用户端出现黑屏，且请求设定次数的解码立即刷新帧IDR仍未恢复，用户端出现黑屏即用户端无法正常显示游戏运行画面，游戏画面无法进行正常渲染，这个设定次数优选为10次，当然也可以根据需要设定为其他数值。S300：检测串流分辨率是否为标准分辨率，如是，执行S400，否则将串流分辨率切换为标准分辨率后再执行S400，当串流分辨率与标准分辨率不一致时，可能会在用户端的游戏画面周围出现黑边，从而会影响云游戏是否正常串流的判断，通过分辨率调整标准分辨率便于更准确进行串流自动降级控制，标准分辨率优选为16：9，这与目前主流的游戏画面比例一致。S400：检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行WebRTC硬解码串流，否则降级为WebRTC软解码。即串流的最高等级为WebRTC硬解码，WebRTC使用UDP（User Datagram Protocol，用户数据报协议）协议，为无连接传输协议，具有延迟低、速度快的优势，特别适合云游戏这种对实时性要求较高但是对少量丢包并没有太大要求的场景，同时硬解码资源消耗低，解码更流畅。因此，WebRTC硬解码为云游戏串流的最优选择，当用户端硬件不支持时（如用户显卡不支持较新的解码格式），可以降级为WebRTC软解码，软解码仅支持“raw.h264”格式baseline等级，硬解码支持“mp4.h264"格式high等级，较baseline等级而言，一般high等级对视频的压缩效果更好，视频质量会更清晰。此时很可能会消耗更多的客户端资源，如增加功耗等，随着处理器性能的提升，软解码一般也能保证云游戏顺利运行。关键帧是一个完整的、无损的图像帧，它包含了视频序列中的所有信息，包括颜色、纹理、形状等。因此，关键帧可以独立地进行解码和显示，不需要依赖于其他帧。如果一个画面组中没有关键帧就会出现花屏现象，因此可通过关键帧的解析分析判断云游戏是否在流畅运行。S500：检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行WebRTC软解码串流，否则执行S600，WebRTC软解码串流如果关键帧无法解析成功，表现游戏运行较为卡顿，此时就需要降级为基于TCP（TransmissionControl Protocol，传输控制协议）可靠传输的WebSocket软解码，以保证用户的游戏体验。在WebRTC软解码串流的关键帧解析失败时，还可以选择先降级为WebSocket硬解码，WebSocket硬解码失败再降为WebSocket软解码，从而可充分利用客户端硬解码对游戏体验的支撑。S600：降级到WebSocket软解码进行串流，WebSocket本质上是借助于HTTP建立的TCP连接，从而WebSocket提供可靠的、面向连接的、基于流的传输服务，保证游戏画面传输的可靠性和完整性，但这种方式会消耗较多的资源，此时串流的码率可能相对较低，但可有效避免了游戏卡顿和丢帧，能在最大程度确保用户云游戏使用体验的流畅舒适。优选在降级后还通过用户绑定的邮箱等方式通知用户，以提醒用户，进一步改善使用体验。本发明对云游戏进行WebRTC串流降级时，还会对用户端的黑屏、网络连接、分辨率进行检测处理，实现了对串流降级更为精准的控制，同时，对WebRTC串流进行梯度降级，还可以修改分辨率，从而为用户匹配了最合适的串流方式，较现有的直接降低串流码率，适应了更复杂的工作场景，也明显提升了用户的体验。

作为可选的实施方式，如图1所示，S300、S400步骤之间还包括以下步骤。S350a：检测是否出现WebRTC的超时流水上报、解码器为空或WebRTC的首次连接失败，如是，执行S600，否则执行S400。检测到WebRTC的超时流水上报，即WebRTC candidate超时，此时表明无法快速获取到用户的网络地址信息，从而用户难以通过基于UDP协议的WebRTC获得流畅游戏体验，candidate超时流水上报触发基于TCP协议的WebSocket软解码确保了串流降级后的可靠传输，这个超时时间优选为7S，当然也可以根据需要设置为其他数值。解码器为空可由解码器含有“null”字符触发，且不区分大小写，此时表明用户端无法进行正常硬解码，因此需直接降级为WebSocket软解码，以使用户获得更好的游戏体验。WebRTC的首次连接失败，表明用户无法进行WebRTC解码，自然也需要降级为WebSocket软解码，可通过WebRTC的首次连接在超过设定时间还未连接上确认，这个设定时间优选为10S，当然也可根据需要选择其它时间。通过S350的判断过程，便于排除不能进行WebRTC串流的情形，而直接降级为WebSocket软解码则提高了串流降级控制的效率。

作为可选的实施方式，如图2所示，S200步骤中，通过以下步骤进行黑屏的检测。S210：获取用户端显示画面的原始图片，显然此时应为浏览器或客户端操作界面最大化且正在操作时的显示画面，并转换为灰度图，此时每个像素值为0~255的灰度值，数值越大则越白。S220：设定灰度图中偏暗部区域的灰度值范围，优选为灰度值0~29，当然也可根据需要设定其他范围，在这个数值范围内，对应的原始图片较黑，可以将黑屏中大部分像素包括进来，计算灰度图的总像素及偏暗部区域的像素，通过像素个数进行计算，如游戏画面为1080P分辨率时，灰度图的总像素个数即为2073600，而偏暗部区域的像素自然不会大于该数值。S230：设定对比阈值，当偏暗部区域的像素与灰度图的总像素的比值大于对比阈值时，判断出现黑屏。该对比阈值优选为0.8，当然也可根据需要选择其他数值，当用户端显示黑屏时，一般还会在黑屏区域的中部或者边缘显示部分文字、图案等构成的提示信息，而不是100%的区域为黑屏，通过设定阈值就可以有效排除这些提示信息对判断结果的干扰，从而得到更准确可靠的黑屏判断结果，避免误判。

作为可选的实施方式，S200步骤中，还可通过以下方式判断用户端出现黑屏：当连续两次请求解码立即刷新帧IDR之后，接收到两次关键帧解析失败事件。当连续两次请求解码立即刷新帧IDR可以避免一次请求造成的误判断，关键帧解析失败即无法正确的获取游戏画面，通过两次接收能更准确确认用户端出现黑屏。

作为可选的实施方式，S400~S500步骤替换为如下步骤。（1）检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行WebRTC硬解码串流，否则，降低串流分辨率和/或帧率。一般而言，帧率较分辨率对游戏体验更为重要，可以先降低分辨率一个档次，如从1440P降为1080P，当然，也可以分辨率与帧率同时降低，如分辨率从1080P降为720P、帧率从120降为60，显然，降低串流分辨率和/或帧率有一个最低数值，以免分辨率和/或帧率太低，严重影响用户的游戏体验，具体数值可根据不同类型的游戏进行设置，如720P、30帧。再次检测WebRTC硬解码串流的关键帧解析是否成功，如是，按照降低后的串流分辨率和/或帧率执行WebRTC硬解码串流，否则降级为WebRTC软解码串流。（2）检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行WebRTC软解码串流，否则，降低串流分辨率和/或帧率，具体过程与WebRTC硬解码串流降低串流分辨率和/或帧率操作类似，再次检测WebRTC软解码串流的关键帧解析是否成功，如是，按照降低后的串流分辨率和/或帧率执行WebRTC软解码，否则执行S600。在串流降级前，先调整串流分辨率和/或帧率，可以得到与用户端更适配的串流方式，从而进一步提升用户的使用体验。

作为可选的实施方式，如图3所示，S400、S500步骤中，还可以通过以下方法判断是否需要进行串流降级。S410：采集游戏运行时的连续多帧图像，即将游戏运行的动态画面中对应的图像进行静态固化。S420：计算获取到的连续数帧图像中每相邻两帧图像的相似度，游戏画面为实时动态画面，相邻两帧图像的虽然有大部分相似，但也有一部分存在区别，但游戏出现卡顿时，相邻两帧或多帧图像就会完全一样，通过相似度计算即可对网络卡顿进行确定。S430：根据每相邻两帧图像的相似度，得出游戏运行时的画面是否出现卡顿的结论，判断是否需要进行串流降级。此时，当相邻两帧图像的相似度小于设定阈值时（该阈值可根据不同游戏场景的经验进行设置），即可判断相邻两帧图像的相似度高，可能出现卡顿，此时再结合多个相邻两帧图像的相似度进行辅助判断，即可得到网络是否卡顿的判断结果。当出现卡顿时，即需要进行串流降级以获得流畅的游戏体验。上述方法可与关键帧解析是否成功相结合，从而得到更准确的是否需要执行串流降级的判断。通过直方图法、平均哈希法、感知哈希算法、差值哈希算法中的任意一种或多种进行相邻两帧图像的相似度计算。通过上述算法可对相邻两帧图像的相似度进行准确计算，可根据实际使用需要选择其中一种或多种。

作为可选的实施方式，在采集游戏运行时的多帧图像时；当预设的采集频率大于等于游戏画面的帧率时，采用游戏画面的两相邻游戏帧图像进行相似度计算，此时两相邻采集帧图像可能是游戏画面的同一帧，为完全一样图像，无法进行相似度计算，因此选择游戏画面的两相邻游戏帧图像（两相邻游戏帧图像作为S430中的相邻两帧图像）进行相似度计算。当预设的采集频率小于游戏画面的帧率时，采用采集到的两相邻采集帧图像（两相邻采集帧图像作为S430中的相邻两帧图像）进行相似度计算，显然，只有采集到的图像才能进行相似度计算，当游戏画面帧率更高时也只能选择采集设备采集到的两相邻采集帧图像。通过对上述两种情况的处理，从而可以实现相似度的计算。

作为可选的实施方式，S400、S500步骤中，在解析关键帧失败两次后请求一次解码立即刷新帧IDR（Instantaneous Decoding Refresh），若新的关键帧还是未解析成功，则判定为关键帧解析失败。由于解码立即刷新帧IDR请求失败是小概率事件，但响应时间无法保证、有可能超过一秒，因此，在解析关键帧失败两次后发起请求能够更准确判断是否出现了关键帧解析失败。

作为可选的实施方式，当用户再次进入系统时，即用户通过浏览器、客户端等登录进入云游戏，自动检测用户配置是否发生变化，一般为浏览器、客户端中具体参数的设置，若未发生变化直接采用上次串流降级结果执行串流降级。当用户配置未发生变化时，上次的串流降级结果即为最优结果，直接执行上次的结果可以省去用户重新进行串流自动降级配置的时间，提升了用户的使用体验。

实施例仅是一个特例，并不表明本发明就这样一种实现方式。

实施例二：本发明还提供一种云游戏推荐分辨率及帧率获取方法，用于获取云游戏的推荐分辨率及帧率，推荐分辨率及帧率即当前网络环境下系统推荐给用户的云游戏最佳分辨率及帧率组合，既包括推荐的分辨率，也包括推荐的帧率。本方法使用实施例一中的一种串流自动降级控制方法，如图4-图6所示，包括以下步骤。S10：选择测试节点启动测试（用户测试节点和最终启动游戏的地点不一定为同一个），得到当前节点的下载速率、丢包率、抖动时间和延迟时间，这几个指标都是影响云游戏是否流畅运行的重要指标。S20：判断下载速率是否超过速率阈值，如是，执行S30，否则，结束测试并提醒用户，对用户进行提醒便于用户重新选择网络环境。下载速率是上述几个指标中最重要的，下载速率达到一定数值是云游戏流畅运行的最基础条件，因此，通过设定速率阈值，具体值可根据需要进行设置，如20Mbps、30Mbps等，便于对用户进行筛选，将无法流畅体验云游戏的用户进行排除。S30：进行解码测试，根据下载速率、丢包率、抖动时间和延迟时间匹配初始分辨率及帧率，可根据云游戏流畅运行的经验值进行推荐。S40：获取解码测试的丢包率和延迟时间，判断丢包率和/或延迟时间是否超过设定阈值，该阈值根据需要进行设定，若超过设定阈值，执行S50，否则将初始分辨率及帧率作为推荐游戏分辨率及帧率。丢包率和/或延迟时间未超过设定阈值，表明当前设置即可实现游戏的流畅运行，即可将初始分辨率及帧率作为推荐游戏分辨率及帧率。若超过设定阈值，表明云游戏出现卡顿，会影响游戏体验，需要进行串流降级以获得流畅游戏的体验。S50：通过串流自动降级控制方法进行降级，得到推荐分辨率及帧率，当串流的关键帧持续解析成功时，表明当前降级的分辨率及帧率与用户网络环境实现了匹配，可以进行推荐。通过本方法，可以通过下载速率明显低于正常值的用户环境进行筛选，便于用户自查网络/设备问题。对于符合下载速率要求的用户，可以通过实施例一中的串流自动降级控制方法进行控制，为用户推荐最合适的分辨率、帧率，使用户体验最优。用户根据推荐游戏分辨率及帧率进行游戏设置，启动后即可开始正常的云游戏流程。

本方法运行过程中，涉及到APP、SDK（Software Development Kit，软件开发工具包）、后台和测试节点，各端要做的工作分别如下。（1）APP调用SDK的监测接口：网络监测和解码监测，是否一次性调用并返回；监测过程中的百分比，如何确认；返回之后的各阶段UI展示，需求方确认。（2）SDK回调的数据值：网络参数（包括网络时延、丢包率、抖动、网速带宽）；网络可支撑的清晰度级别；解码能力（各清晰度视频播放期间）；解码延迟；解码可支撑的清晰度级别。（3）APP根据SDK回调的数据值结果进行选择。（4）后台：各区域部署测速服务，包括带宽监测文件，即视频文件的压缩包；根据客户端请求，返回测速区域。

以上所述仅为本发明的较佳实施例而已，本领域技术人员知悉，在不脱离本发明的精神和范围的情况下，可以对这些特征和实施例进行各种改变或等同替换。另外，在本发明的教导下，可以对这些特征和实施例进行修改以适应具体的情况及材料而不会脱离本发明的精神和范围。因此，本发明不受此处所公开的具体实施例的限制，所有落入本申请的权利要求范围内的实施例都属于本发明的保护范围。

Claims (10)

1.一种串流自动降级控制方法，其特征在于，用于对游戏串流降级进行动态控制，包括以下步骤：

S100：检测用户端网络是否正常连通，如是，执行S200，否则提示网络异常；

S200：检测到用户端出现黑屏，且请求设定次数的解码立即刷新帧IDR仍未恢复；

S300：检测串流分辨率是否为标准分辨率，如是，执行S400，否则将串流分辨率切换为标准分辨率后再执行S400；

S400：检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行WebRTC硬解码串流，否则降级为WebRTC软解码串流；

S500：检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行WebRTC软解码串流，否则执行S600；

S600：降级到WebSocket软解码进行串流。

2.根据权利要求1所述的一种串流自动降级控制方法，其特征在于，所述S300、S400步骤之间还包括以下步骤：

S350a：检测是否出现WebRTC的超时流水上报、解码器为空或WebRTC的首次连接失败，如是，执行S600，否则执行S400。

3.根据权利要求1所述的一种串流自动降级控制方法，其特征在于，所述S200步骤中，通过以下步骤进行黑屏的检测：

S210：获取用户端显示画面的原始图片，并转换为灰度图；

S220：设定灰度图中偏暗部区域的灰度值范围，计算灰度图的总像素及偏暗部区域的像素；

S230：设定对比阈值，当偏暗部区域的像素与灰度图的总像素的比值大于对比阈值时，判断出现黑屏。

4.根据权利要求1所述的一种串流自动降级控制方法，其特征在于，所述S200步骤中，还可通过以下方式判断用户端出现黑屏：当连续两次请求解码立即刷新帧IDR之后，接收到两次关键帧解析失败事件。

5.根据权利要求1所述的一种串流自动降级控制方法，其特征在于，所述S400~S500步骤替换为：

检测WebRTC硬解码串流的关键帧解析是否成功，如是，继续执行WebRTC硬解码串流，否则，降低串流分辨率和/或帧率，再次检测WebRTC硬解码串流的关键帧解析是否成功，如是，按照降低后的串流分辨率和/或帧率执行WebRTC硬解码串流，否则降级为WebRTC软解码串流；

检测WebRTC软解码串流的关键帧解析是否成功，如是，继续执行WebRTC软解码串流，否则，降低串流分辨率和/或帧率，再次检测WebRTC软解码串流的关键帧解析是否成功，如是，按照降低后的串流分辨率和/或帧率执行WebRTC软解码，否则执行S600。

6.根据权利要求1所述的一种串流自动降级控制方法，其特征在于，所述S400、S500步骤中，还可以通过以下方法判断是否需要进行串流降级：

S410：采集游戏运行时的连续多帧图像；

S420：计算获取到的连续数帧图像中每相邻两帧图像的相似度；

S430：根据每相邻两帧图像的相似度，得出游戏运行时的画面是否出现卡顿的结论，判断是否需要进行串流降级。

7.根据权利要求6所述的一种串流自动降级控制方法，其特征在于，在采集游戏运行时的多帧图像时；当预设的采集频率大于等于游戏画面的帧率时，采用游戏画面的两相邻游戏帧图像进行相似度计算；当预设的采集频率小于游戏画面的帧率时，采用采集到的两相邻采集帧图像进行相似度计算。

8.根据权利要求1所述的一种串流自动降级控制方法，其特征在于，所述S400、S500步骤中，在解析关键帧失败两次后请求一次解码立即刷新帧IDR，若新的关键帧还是未解析成功，则判定为关键帧解析失败。

9.根据权利要求1-8中任一项所述的一种串流自动降级控制方法，其特征在于，当用户再次进入系统时，自动检测用户配置是否发生变化，若未发生变化直接采用上次串流降级结果执行串流降级。

10.一种推荐分辨率及帧率获取方法，其特征在于，用于获取云游戏的推荐分辨率及帧率，使用权利要求1-9中任一项所述的一种串流自动降级控制方法，包括以下步骤：

S10：选择测试节点启动测试，得到当前节点的下载速率、丢包率、抖动时间和延迟时间；

S20：判断所述下载速率是否超过速率阈值，如是，执行S30，否则，结束测试并提醒用户；

S30：进行解码测试，根据所述下载速率、丢包率、抖动时间和延迟时间匹配初始分辨率及帧率；

S40：获取解码测试的丢包率和延迟时间，判断丢包率和/或延迟时间是否超过设定阈值，若超过设定阈值，执行S50，否则将初始分辨率及帧率作为推荐分辨率及帧率；

S50：通过所述串流自动降级控制方法进行降级，得到推荐分辨率及帧率。