一种基于屏幕分享的数据处理方法和装置与流程

1.本技术涉及互联网通信技术领域，尤其涉及一种基于屏幕分享的数据处理方法和装置。


背景技术：

2.随着视频处理领域的发展，出现了屏幕分享技术。屏幕分享技术是将发送端的屏幕内容分享至接收端的技术。其中发送端采集屏幕内容形成视频，然后通过编码器对视频执行编码操作，再将编码得到的数据发送至服务器；服务器将接收到的数据转发至接收端；接收端通过相应的解码器执行解码操作以得到屏幕内容对应的视频并显示。由此实现了发送端将屏幕内容分享至接收端的效果。
3.相关技术中，发送端往往采用软编码器对视频执行编码操作，这是一种使用cpu(中央处理器)做算法运算的方案。在较大程度占用作为计算资源的cpu的同时，也较大程度占用作为存储资源的内存，从而影响着发送端的系统性能。针对有着较高分辨率及较高帧率需求的屏幕分享场景，相关技术中的编码方案并不能保证编码效率，也影响兼顾清晰度和流畅度的屏幕分享效果的实现。


技术实现要素：

4.为了解决现有技术应用在屏幕分享时，对作为系统资源的cpu和内存占用率高、编码效率低等问题，本技术提供了一种基于屏幕分享的数据处理方法和装置：
5.根据本技术的第一方面，提供了一种基于屏幕分享的数据处理方法，所述方法包括：
6.响应于屏幕分享请求，确定本地设备的显卡信息；
7.根据所述本地设备的显卡信息确定目标硬编码器；
8.按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码；
9.发送编码得到的数据至服务端。
10.根据本技术的第二方面，提供了一种基于屏幕分享的数据处理装置，所述装置包括：
11.响应模块：用于响应于屏幕分享请求，确定本地设备的显卡信息；
12.确定模块：用于根据所述本地设备的显卡信息确定目标硬编码器；
13.编码模块：用于按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码；
14.发送模块：用于发送编码得到的数据至服务端。
15.根据本技术的第三方面，提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如第一方面所述的基于屏幕分享的数据处理方法。
16.根据本技术的第四方面，提供了一种计算机可读存储介质，所述存储介质中存储
有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如第一方面所述的基于屏幕分享的数据处理方法。
17.根据本技术的第五方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如第一方面所述的基于屏幕分享的数据处理方法。
18.本技术提供的一种基于屏幕分享的数据处理方法和装置，具有如下技术效果：
19.本技术通过确定本地设备的显卡信息，然后根据本地设备的显卡信息确定目标硬编码器，再按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码，从而发送编码得到的数据至服务端，以实现发送端针对屏幕分享请求的响应。本技术中开放式画面组(opengop)的模式以及硬编码器的应用，提升了编码效率，减少了对cpu和内存的占用以保障发送端的系统性能。对于屏幕分享大分辨率场景，本技术能够保证兼顾了清晰度和流畅度的屏幕分享效果的实现。
附图说明
20.为了更清楚地说明本技术实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
21.图1是本技术实施例提供的一种应用环境的示意图；
22.图2是本技术实施例提供的一种基于屏幕分享的数据处理方法的流程示意图；
23.图3是本技术实施例提供的根据本地设备的显卡信息确定目标硬编码器一种流程示意图；
24.图4是本技术实施例提供的按照开放式画面组的模式，利用目标硬编码器对屏幕分享视频流进行编码一种流程示意图；
25.图5是本技术实施例提供的基于开放式画面组的模式结束构建上一个待编码画面组，以及将屏幕分享视频流中最靠近上一个待编码画面组的末帧的视频帧作为下一个待编码画面组的关键视频帧的一种流程示意图；
26.图6也是本技术实施例提供的一种基于屏幕分享的数据处理方法的流程示意图；
27.图7是本技术实施例提供的应用强制编i帧功能的一种流程示意图；
28.图8是本技术实施例提供的一种基于屏幕分享的数据处理装置的组成框图；
29.图9是本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
30.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
31.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“包括”和“具
有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
32.对本技术实施例进行进一步详细说明之前，对本技术实施例中涉及的名词和术语进行说明，本技术实施例中涉及的名词和术语适用于如下的解释。
33.h.264：它是一种高度压缩数字视频编解码器的标准。
34.h.265：它是继h.264之后制定的新的标准。
35.gop：它是group of pictures的缩写，释义为画面组。一个gop为一组连续的编码帧。
36.i帧：帧内编码帧，它可以表示关键帧。i帧通常是每个gop的首帧。
37.码率：视频码率就是数据传输时单位时间传送的数据位数，一般我们用的单位是kbps即千位每秒。通俗一点的理解就是取样率，单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件。
38.请参阅图1，图1是本技术实施例提供的一种应用环境的示意图，该应用环境中可以包括第一类客户端(发送端)10、服务端20以及第二类客户端(接收端)30。发送端10采集屏幕内容形成视频，然后通过编码器对视频执行编码操作，再将编码得到的数据发送至服务端20。服务端20将接收到的数据转发至接收端30。接收端30通过相应的解码器执行解码操作以得到屏幕内容对应的视频并显示。需要说明的是，图1仅仅是一种示例。客户端与服务端可以通过有线或无线通信方式进行直接或间接地连接。
39.第一类客户端10和第二类客户端30可以是智能手机、台式电脑、平板电脑、笔记本电脑、增强现实(augmented reality，ar)/虚拟现实(virtual reality，vr)设备、数字助理、智能音箱、智能可穿戴设备等类型的实体设备，也可以是运行于实体设备中的软体，比如计算机程序。第一类客户端所对应的操作系统和第二类客户端所对应的操作系统可以是安卓系统(android系统)、ios系统(是由苹果公司开发的移动操作系统)、linux(一种操作系统)、microsoft windows(微软视窗操作系统)等。
40.服务端20可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn(content delivery network，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。其中服务器可以包括有网络通信单元、处理器和存储器等等。服务端可以为对应的客户端提供后台服务。
41.在实际应用中，本技术提供的基于屏幕分享的数据处理方案可以应用于在线办公产品、在线教育产品等互联网产品中。比如，可以在线办公产品的会议引擎的编解码模块内部应用该基于屏幕分享的数据处理方案。
42.以下介绍本技术一种基于屏幕分享的数据处理方法的具体实施例，图2是本技术实施例提供的一种基于屏幕分享的数据处理方法的流程示意图，本技术提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，所述方法可以
包括：
43.s201：响应于屏幕分享请求，确定本地设备的显卡信息；
44.在本技术实施例中，发送端接收屏幕分享请求，确定本地设备的显卡信息。发送端，即是针对屏幕分享的数据发送端/对象，也可以视作主播端。屏幕分享请求可以是目标对象(比如用户、模拟器等)基于相关互联网产品(比如在线办公产品)的用户交互界面触发的。在实际应用中，主播可以从某在线办公产品的会议选项或网络电话(voip)选项中进入屏幕分享模式，进而选择屏幕或应用窗口进行分享。
45.在一示例性的实施方式中，发送端可以确定本地设备的显卡类型信息，以及将本地设备的显卡类型信息作为本地设备的显卡信息。本地设备的显卡类型信息可以用于指示本地设备中独立显卡的情况(有没有独立显卡；有的话，独立显卡的数量是多少)以及集成显卡的情况(有没有集成显卡；有的话，集成显卡的数量是多少)。其中独立显卡可以是将显示芯片及相关器件制作成一个独立于主板和处理器的板卡。集成显卡可以指将显示芯片及相关器件集成在主板或者处理器上。这里提及的“处理器”一般指示cpu。
46.进一步的，发送端可以确定本地设备的显卡数量以及显卡型号信息，以及根据本地设备的显卡数量以及显卡型号信息，确定本地设备的显卡类型信息。本地设备可以有多个显卡，可以通过显卡数量和显卡型号来判断是否存在独立显卡。比如，作为本地设备的pc(个人计算机)可以有多个显卡，可以通过获取主机的显卡数量和显卡型号来确定显卡类型信息。若显卡数量为2或者显卡型号是指示独立显卡的第一预设厂商型号，则可以判断存在独立显卡。其中第一预设厂商型号可以是nvidia(英伟达)系列、amd(超微半导体)r5以上的系列。
47.s202：根据所述本地设备的显卡信息确定目标硬编码器；
48.在本技术实施例中，发送端根据本地设备的显卡信息确定目标硬编码器。
49.在一示例性的实施方式中，在所述确定本地设备的显卡信息之后，所述方法还包括：首先，获取指示硬编的历史记录信息；然后，确定本地设备的设备信息；其中，所述本地设备的设备信息包括所述本地设备的显卡信息；再者，根据所述本地设备的设备信息，在所述历史记录信息中确定对应的同类设备以及所述同类设备的硬编记录；最后，当所述同类设备的硬编记录指示编码成功时，触发所述根据所述本地设备的显卡信息确定目标硬编码器的步骤。
50.硬编码器是依赖于显卡硬件与系统版本的支持的。比如，一些旧的pc(个人计算机)可能不支持基于预设编码标准进行编码；不同显卡厂商提供了繁多的显卡型号，不同显卡型号对基于预设编码标准的硬编功能的支持程度也存在差别。其中预设编码标准可以包括但不限于h.265、h.264。考虑到硬编码器可能存在的兼容性与不稳定性问题，本技术提出了利用指示硬编的历史记录信息来确定本地设备是否支持基于预设编码标准的硬编功能或者本地设备的硬编效果是否稳定，这样可以过滤掉为不支持基于预设编码标准的硬编功能的本地设备确定硬编码器的无用步骤，可以避免后续因硬编码器启动失败或者利用硬编码器进行编码的效果达不到预期而切换软编码器来编码所造成的耗时影响和流畅性影响。
51.指示硬编的历史记录信息可以由服务端管理，具体可以是由服务端中的云端服务器管理。发送端可以基于屏幕分享请求向服务端发送获取指示硬编的历史记录信息的请求，进而获取该历史记录信息。发送端也可以从本地存储中获取指示硬编的历史记录信息，
本地存储中的指示硬编的历史记录信息可以是由服务端定时下发的。历史记录信息中记录着不同设备对应的硬编历史，比如设备a硬编成功的历史、设备b硬编失败的历史。其中，为设备a和设备b标注有对应的设备信息(比如显卡信息、系统版本信息等)。发送端根据本地设备的设备信息(比如显卡信息、系统版本信息等)，在历史记录信息中确定对应的同类设备以及同类设备的硬编记录。当同类设备的硬编记录指示编码成功时，触发根据本地设备的显卡信息确定目标硬编码器的步骤。
52.当然，指示硬编的历史记录信息可以记录不同设备对应的硬编失败历史，这样可以降低服务端进行历史记录信息维护的资源消耗。发送端获取到的历史记录信息可以看作是硬编黑名单，若其中有本地设备的同类设备，那么不再触发根据本地设备的显卡信息确定目标硬编码器的步骤，而是启动本地设备对应的软编码器以对屏幕分享视频流进行软编。这里用于确定同类设备的设备信息也可以是设备型号，而硬编黑名单记录着一些不可用设备的设备型号。
53.在一示例性的实施方式中，结合上述步骤s201中对于“本地设备的显卡类型信息”的相关记载，如图3所示，所述根据所述本地设备的显卡信息确定目标硬编码器，包括：
54.s301：当所述本地设备的显卡类型信息指示存在独立显卡时，确定所述本地设备中独立显卡对应的硬编码器为目标硬编码器；
55.s302：当所述本地设备的显卡类型信息指示不存在独立显卡且存在集成显卡时，确定所述本地设备中集成显卡对应的硬编码器为目标硬编码器。
56.图形处理器(graphic processing unit，gpu)可以作为独立显卡的主要处理单元。独立显卡的gpu性能比集成显卡的gpu性能高。因此，若本地设备的显卡类型信息指示存在独立显卡，则使用独立显卡，将独立显卡对应的硬编码器作为目标编码器。即便在独立显卡与集成显卡共存的情况下，也优先使用独立显卡。将gpu性能更好的独立显卡支持的硬编码器作为目标硬编码器来编码以实现屏幕分享，可以有效较少对cpu的依赖以减少对cpu和内存的占用，从而提升系统性能。在不存在独立显卡且存在集成显卡的情况下，则使用集成显卡，将集成显卡对应的硬编码器作为目标编码器。相比软编码器的应用，将集成显卡支持的硬编码器作为目标硬编码器来编码以实现屏幕分享，也可以有效减少对cpu和内存的占用，保证系统性能。
57.下面将介绍硬编码器启动方面的内容。作为本地设备的pc，可能由于缺乏系统层面上的针对硬编码的统一开始框架，可以在使用ffmpeg框架(一种多媒体编解码框架)时针对具体的显卡类型启动对应的硬编码器。
58.对于独立显卡，可以基于独立显卡型号启动对应厂商的硬编码器框架。其中，对于出产于nvidia的独立显卡，可以启动nvenc编码库(一种编码库)，将其集成在ffmpeg中时对应hevc_nvenc编码器(一种硬编码器)。对于出产于amd的独立显卡，可以启动amf编码库(一种编码库)，将其集成在ffmpeg中时对应hevc_amf编码器(一种硬编码器)。结合后续步骤中涉及开放式画面组(opengop)的模式的应用。可以在启动硬编码器之前，设置opengop模式，使用ffmpeg时则对应于打开avcodeccontext(ffmpeg中的结构体)中av_codec_flag_closed_gop标志的操作。
59.对于集成显卡，它集成于cpu上。对于集成在出产于intel(英特尔)的cpu上的集成显卡，可以启动libmfx库(一种编码库)，将其集成在ffmpeg中时对应hevc_qsv编码器(一种
硬编码器)，对于集成在出产于amd的cpu上的集成显卡，可以启动amf编码库(一种编码库)，将其集成在ffmpeg中时对应hevc_amf编码器(一种硬编码器)。
60.参见图6，1)当所述目标硬编码器启动失败时，确定所述目标硬编码器对应的显卡类型；2.1)当所述显卡类型指示独立显卡且所述本地设备存在集成显卡时，启动所述本地设备中集成显卡对应的硬编码器；以及当所述本地设备中集成显卡对应的硬编码器启动失败时，启动所述本地设备对应的软编码器；2.2)当所述显卡类型指示集成显卡时，启动所述本地设备对应的软编码器。
61.如果启动独立显卡对应的硬编码器失败，则启动集成显卡对应的硬编码器。如果启动集成显卡对应的硬编码器失败，则启动本地设备对应的软编码器以对屏幕分享视频流进行软编。优先利用gpu性能更好的独立显卡的硬编码器，以减少屏幕分享过程中的cpu和内存占用。同时，为应对硬编码器启动失败的情形，设置了兜底的软编流程，保证了屏幕分享的顺利进行。
62.s203：按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码；
63.在本技术实施例中，发送端按照开放式画面组的模式，利用目标硬编码器对屏幕分享视频流进行编码。
64.在一示例性的实施方式中，如图4所示，所述按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码，包括：
65.s401：基于所述开放式画面组(opengop)的模式为每个待编码画面组动态设置关键视频帧；其中，所述待编码画面组包括一个作为首帧的关键视频帧和至少一个非关键视频帧；
66.s402：基于针对当前待编码画面组的关键视频帧设置信息，从所述屏幕分享视频流中依次确定出用于构建所述当前待编码画面组的视频帧；
67.s403：针对依次确定出的视频帧，分别利用所述目标硬编码器进行编码。
68.在固定gop模式中，构建每个待编码画面组的视频帧的数量相同。相应的，可以基于这样的标准确定每个待编码画面组的关键视频帧。示例性的，屏幕分享视频流为当前时间段(比如最近5秒)针对发送端的屏幕录制视频，若该屏幕录制视频有50帧图像，固定gop模式所规定的构建每个待编码画面组的视频帧的数量为10。那么构建第一个待编码画面组的关键视频帧为该屏幕录制视频的第1帧图像，构建第二个待编码画面组的关键视频帧为该屏幕录制视频的第11帧图像，以此类推，不再赘述。考虑到屏幕分享视频流在时间上的连续性，也可以将固定gop模式的应用，理解为定时编i帧(关键帧)。
69.相对于固定gop模式，在开放式画面组(opengop)的模式中，构建每个待编码画面组的视频帧的数量可能是不同的。结合上述示例，构建第一个待编码画面组的关键视频帧为该屏幕录制视频的第1帧图像，构建第二个待编码画面组的关键视频帧可以是该屏幕录制视频的第15帧图像，构建第三个待编码画面组的关键视频帧为该屏幕录制视频的第42帧图像。每个待编码画面组的关键视频帧的设置，可以结合屏幕内容的变化程度。若相邻两帧图像的相似度大于等于预设阈值，则继续上一个待编码画面组的构建。若相邻两帧图像的相似度小于预设阈值，则结束上一个待编码画面组的构建，开启下一个待编码画面组的构建。考虑到屏幕分享视频流在时间上的连续性，也可以将开放式画面组(opengop)的模式的
应用，理解为非定时编i帧(关键帧)，在少数需要i帧时如画面场景变化大才会编i帧，这样能极大节省和利用码率以提升清晰度。
70.以针对第二个待编码画面组的编码为例，基于针对当前待编码画面组的关键视频帧设置信息(构建第二个待编码画面组的关键视频帧可以是该屏幕录制视频的第15帧图像)，那么确定出第15帧图像，然后利用目标硬编码器对第15帧图像进行编码；再确定出第16帧图像，然后利用目标硬编码器对第16帧图像进行编码；......确定出第n帧图像，然后利用目标硬编码器对第n帧图像进行编码。其中，n为大于16小于42的正整数。在实际应用中，屏幕分享视频流的数据源是针对发送端的屏幕录制视频，屏幕分享视频流可以是基于发送端的屏幕录制而实时更新的。
71.待编码画面组包括一个作为首帧的关键视频帧和至少一个非关键视频帧。对于关键视频帧的编码不同于对于非关键视频帧的编码，前者对图像的压缩程度更小，尽可能的保留图像的信息，甚至不对其进行压缩。由于关键视频帧在编码后常会在发送至服务端的数据中占用较多数据位数，对于屏幕分享场景中画面变化不大的情形(比如在线会议中进行屏幕分享的情形)，应用固定gop模式则会降低码率的利用率；而应用开放式画面组(opengop)的模式，可以更具适应性的为每个待编码画面组动态确定i帧，这样可以在保证较高清晰度的屏幕分享效果的同时提高码率的利用率。
72.进一步的，所述基于所述开放式画面组的模式为每个待编码画面组动态设置关键视频帧，包括：响应于所述服务端发送的新增对象信息，基于所述开放式画面组的模式结束构建上一个待编码画面组，以及将所述屏幕分享视频流中最靠近所述上一个待编码画面组的末帧的视频帧作为下一个待编码画面组的关键视频帧；其中，所述新增对象信息指示当前时间有新增的针对屏幕分享的数据接收对象。
73.针对屏幕分享的数据接收对象是与发送端相对的，它可以解释为针对屏幕分享的数据接收端，也可以视作观众端。在实际应用中，新增对象信息可以表示当前时间有新用户进入进行中的在线会议或者在线课堂。
74.由于开放式画面组(opengop)的模式中编i帧的时机不固定，或者说开始构建一个新的待编码画面组的时机不固定。那么新增的接收端可能存在由于长时间得不到服务端转发的指示i帧(关键视频帧)的数据而无法有效解码的情况，新用户也因此无法观看发送端的屏幕内容。因此，响应于新增对象信息，基于开放式画面组的模式及时结束上一个待编码画面组的构建，进而及时开启下一个待编码画面组的构建。这样可以保证新增的接收端尽快得到服务端转发的指示i帧的数据以解码显示，从而提高新用户对于相关产品屏幕分享功能的使用体验。
75.所开启的下一个待编码画面组的关键视频帧，选用屏幕分享视频流中最靠近上一个待编码画面组的末帧的视频帧。比如，屏幕分享视频流可以是基于发送端的屏幕录制而实时更新的。构建第m个待编码画面组时，将屏幕分享视频流中的第m帧图像作为构建第m个待编码画面组的首帧，也即是关键视频帧。发送端接收到新增对象信息之前，发送端继续构建着第m个待编码画面组，已依次将屏幕分享视频流中的第m+1帧图像、第m+2帧图像作为构建第m个待编码画面组的非关键帧，并在选中第m+1帧图像后对其编码、以及在选中第m+2帧图像后对其编码。发送端接收到新增对象信息之后，结束第m个待编码画面组的构建，第m个待编码画面组的构建对象有第m帧图像、第m+1帧图像以及第m+2帧图像。将第m+3帧图像作
为构建第m+1个待编码画面组的首帧，也即是关键视频帧。其中，m、m可以取大于等于1的正整数。需要说明的是，发送端接收到新增对象信息之前，发送端可以没有完成对第m+2帧图像的编码。这不影响第m+2帧图像作为第m个待编码画面组的构建对象之一。
76.在实际应用中，“基于所述开放式画面组的模式结束构建上一个待编码画面组，将所述屏幕分享视频流中最靠近所述上一个待编码画面组的末帧的视频帧作为下一个待编码画面组的关键视频帧”可以表现为基于新增对象信息而触发一个强制编i帧功能。相应的，可以在ffmpeg中设置编码请求的pic_type为av_picture_type_i)。
77.此外，参见图5，所述基于所述开放式画面组的模式结束构建上一个待编码画面组，以及将所述屏幕分享视频流中最靠近所述上一个待编码画面组的末帧的视频帧作为下一个待编码画面组的关键视频帧，包括：
78.s501：获取第一预设数值；其中，所述第一预设数值指示相邻两个所述待编码画面组的关键视频帧之间的最小间隔帧数；
79.s502：确定所述上一个待编码画面组对应的已编码的非关键帧的帧数；
80.s503：当所述帧数大于等于所述第一预设数值时，结束构建所述上一个待编码画面组，以及将所述屏幕分享视频流中最靠近所述上一个待编码画面组的末帧的视频帧作为所述下一个待编码画面组的关键视频帧；
81.s504：当所述帧数小于所述第一预设数值时，基于所述帧数与所述第一预设数值的差值，从所述屏幕分享视频流确定出用于构建所述上一个待编码画面组的剩余视频帧，以及将所述屏幕分享视频流中最靠近所述上一个待编码画面组的末帧的视频帧作为下一个待编码画面组的关键视频帧。
82.考虑到若不断接收到新增对象信息(可以指示不断有新用户进入)，则需要不断结束上一个待编码画面组的构建、不断开启下一个待编码画面组的构建。这样将因关键视频帧的增加而导致频繁的编i帧，从而影响了开放式画面组(opengop)的模式应用来减少编i帧以节省码率的意义。
83.结合上述第m个待编码画面组和第m+1待编码画面组的示例。若第一预设数值为5，第m个待编码画面组对应的已编码的非关键帧(第m+1帧图像、第m+2帧图像)的帧数为2。作为上述帧数的2小于作为第一预设数值的5，基于它们的差值3确定构建第m个待编码画面组的剩余视频帧：第m+3帧图像、第m+4帧图像以及第m+5帧图像。第m个待编码画面组的构建对象有第m帧图像、第m+1帧图像、第m+2帧图像、第m+3帧图像、第m+4帧图像以及第m+5帧图像。将第m+6帧图像作为构建第m+1个待编码画面组的首帧，也即是关键视频帧。若第一预设数值为2，那么结束第m个待编码画面组的构建，第m个待编码画面组的构建对象有第m帧图像、第m+1帧图像以及第m+2帧图像。将第m+3帧图像作为构建第m+1个待编码画面组的首帧，也即是关键视频帧。
84.在实际应用中，参见图7，对于强制编i帧功能，在有大量用户或同时多个用户进来时，就会出现频繁编i帧的情况。因此设置一个编i帧的最小间隔帧数，在减少强制编i帧的同时也不会出现新用户进入后长时间等不到i帧的情况，此时编i帧逻辑流程如下：1)正常opengop编码模式根据场景变化编出i帧，此时如果有请求i帧标志将其清空；2)新观众进入时请求i帧。由于设置了最小间隔帧数，此时先判断是否有上一个观众请求的i帧标志，如果己有则无须重复请求。如果还没有，则计算上一次i帧对应的时间范围内所编的非i帧数与
最小间隔帧数的差值，如满足大于则强制编i帧，如有差值n，则设置请求i帧标志，在后续的第n帧时强制编i帧。
85.在一示例性的实施方式中，在所述利用所述目标硬编码器对屏幕分享视频流进行编码之后，所述方法还包括：首先，获取第二预设数值；然后，当编码失败次数大于等于所述第二预设数值时，启动所述本地设备对应的软编码器，以及基于所述本地设备的硬编失败信息更新所述历史记录信息。
86.结合前述步骤s202中记载的“历史记录信息”，考虑到硬编码器可能存在的兼容性与不稳定性问题，有些机器可用成功启动硬编码器，但实际编码时也有可能会返回失败结果。针对编码器启动成功但编码过程中的出现失败的情况，当编码失败次数大于等于第二预设数值时，启动本地设备对应的软编码器以对屏幕分享视频流进行软编，保证了屏幕分享的顺利进行。同时，基于本地设备的硬编失败信息更新历史记录信息。
87.对于编码失败次数的界定，可以是编码过程中出现1帧图像编码失败则视作一次编码失败。第二预设次数可以根据实际需要灵活设置，比如取10。统计上述编码失败的次数，当超过10次的编码失败，则认为目标硬编码器存在异常，需要切换软编流程以确保屏幕分享的正常使用。发送端可以利用本地设备的硬编失败信息更新本地存储中的历史记录信息，同时将本地设备的硬编失败信息上报至服务端。发送端也可以直接将本地设备的硬编失败信息上报至服务端。本地设备的硬编失败信息中可以有携带有异常标识的本地设备的设备型号信息、显卡信息、系统版本信息等。服务端可以根据本地设备的硬编失败信息来统计同类设备的硬编失败信息，如多次收到同类设备的硬编失败信息，则可将这类设备标记为不可用设备。
88.s204：发送编码得到的数据至服务端。
89.在本技术实施例中，发送端发送编码得到的数据至服务端。服务器可以将接收到的数据转发至接收端。接收端可以通过相应的解码器对接收到的数据进行解码以得到屏幕内容对应的视频并显示。
90.下面结合图6介绍应用本技术提供的基于屏幕分享的数据处理方案的实施例：
91.1.用户可以从某在线办公产品的会议选项或网络电话(voip)选项中进入屏幕分享模式，该在线办公产品的客户端进入屏幕分享功能；
92.2.该客户端拉取云端下发的配置，该配置可以对应上述步骤s202、s203中记载的“历史记录信息”；
93.3.根据该配置确定是否允许硬编；这里可以参考前述步骤s202中的相关记载。
94.4.在允许硬编的情况下，获取显卡类型信息，这里可以参考前述步骤s201中的相关记载；否则，启用软编流程(13)。在不允许硬编的情况下，及时启用软编流程，可以避免后续硬编流程出现异常时中途切换软编流程的耗时。
95.5.根据显卡类型信息确定是否有独立显卡；
96.6.在有独立显卡的情况下，启用独立显卡对应的硬编码器；否则，确定是否有集成显卡(14)，若有，启用集成显卡对应的硬编码器；
97.7.设置开放式画面组的模式；
98.8.判断是否成功启动硬编码器；
99.9.若成功启动，则设定最小间隔帧数；否则，则存在下述3种情况：
100.1)确定是否有集成显卡(14)，若有，启用集成显卡对应的硬编码器，设置开放式画面组的模式(7)，若依然启动失败，则启用软编流程(13)；
101.2)确定是否有集成显卡(14)，若无，则启用软编流程(13)；
102.3)确定是否有集成显卡(14)，若有，启用集成显卡对应的硬编码器，设置开放式画面组的模式(7)，若启动成功，则设定最小间隔帧数(9)；
103.10.编码；
104.11.判断是否出现编码失败；
105.12.若没有出现编码失败，发送编码得到的数据至服务器；
106.15.若出现编码失败，判断硬编失败是否超过阈值；
107.16.若超过阈值，则更新云端硬编黑名单配置。
108.由以上本技术实施例提供的技术方案可见，本技术实施例通过确定本地设备的显卡信息，然后根据本地设备的显卡信息确定目标硬编码器，再按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码，从而发送编码得到的数据至服务端，以实现发送端针对屏幕分享请求的响应。本技术中开放式画面组(opengop)的模式以及硬编码器的应用，提升了编码效率和对码率的利用率，减少了对cpu和内存的占用以保障发送端的系统性能，同时避免了因编码耗时较大而在高帧率场景出现流畅性不足的情况。对于大分辨率场景，本技术能够保证兼顾了清晰度和流畅度的屏幕分享效果的实现。
109.本技术实施例还提供了一种基于屏幕分享的数据处理装置，如图8所示，所述基于屏幕分享的数据处理装置800包括：
110.响应模块801：用于响应于屏幕分享请求，确定本地设备的显卡信息；
111.确定模块802：用于根据所述本地设备的显卡信息确定目标硬编码器；
112.编码模块803：用于按照开放式画面组的模式，利用所述目标硬编码器对屏幕分享视频流进行编码；
113.发送模块804：用于发送编码得到的数据至服务端。
114.需要说明的，所述装置实施例中的装置与方法实施例基于同样的发明构思。
115.本技术实施例提供了一种电子设备，该电子设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的基于屏幕分享的数据处理方法。
116.进一步地，图9示出了一种用于实现本技术实施例所提供的基于屏幕分享的数据处理方法的电子设备的硬件结构示意图，所述电子设备可以参与构成或包含本技术实施例所提供的基于屏幕分享的数据处理装置。如图9所示，电子设备90可以包括一个或多个(图中采用902a、902b，
……
，902n来示出)处理器902(处理器902可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器904、以及用于通信功能的传输装置906。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图9所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备90还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。
117.应当注意到的是上述一个或多个处理器902和/或其他数据处理电路在本文中通
常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到电子设备90(或移动设备)中的其他元件中的任意一个内。如本技术实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
118.存储器904可用于存储应用软件的软件程序以及模块，如本技术实施例中所述的基于屏幕分享的数据处理方法对应的程序指令/数据存储装置，处理器902通过运行存储在存储器94内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种基于屏幕分享的数据处理方法。存储器904可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器904可进一步包括相对于处理器902远程设置的存储器，这些远程存储器可以通过网络连接至电子设备90。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
119.传输装置906用于经由一个网络接收或者发送数据。上述的网络具体实例可包括电子设备90的通信供应商提供的无线网络。在一个实例中，传输装置906包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一示例性的实施方式中，传输装置906可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
120.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与电子设备90(或移动设备)的用户界面进行交互。
121.本技术的实施例还提供了一种计算机可读存储介质，所述存储介质可设置于电子设备之中以保存用于实现方法实施例中一种基于屏幕分享的数据处理方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的基于屏幕分享的数据处理方法。
122.可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
123.需要说明的是：上述本技术实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
124.本技术中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
125.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读
存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
126.以上所述仅为本技术的较佳实施例，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。