掌桥专利:专业的专利平台
掌桥专利
首页

云会议共享桌面动态编码方法、装置、设备及存储介质

文献发布时间:2023-06-19 12:11:54


云会议共享桌面动态编码方法、装置、设备及存储介质

技术领域

本发明涉及云计算和数据通信领域,具体涉及一种云会议共享桌面动态编码方法、装置、设备及存储介质。

背景技术

在远程办公、远程教育和远程医疗等场景中,需要用到云视频会议,其中有共享桌面这个功能。现有的云视频会议中共享桌面的方法,一种是固定共享桌面采集与编码,依靠解码接收时采用解码丢包策略和I帧请求策略来解决观看端的马赛克及跳帧卡顿问题。实现相对容易,但是没有考虑视频数据在信道中传输环境引入的问题,去动态调整传输数据量来适应当前信道。另一种是共享桌面固定采集,编码器根据信道状态进行实时重置处理。但是,重置编码器代价很大,会引入卡顿且不能频繁实时去重置,导致信道波动频繁的情况下出现卡顿等问题。

发明内容

因此,本发明要解决的技术问题在于克服现有技术中的上述缺陷,从而提供一种云会议共享桌面动态编码方法、装置、设备及存储介质。

本发明提供了一种云会议共享桌面动态编码方法,包括如下步骤:

S1:建立桌面采集线程,在采集线程中动态采集,将采集到的数据放入到采集队列中;

S2:建立桌面编码线程,从采集队列中取出有效数据,先进行缩放再进行编码处理,同时根据信道状态动态设置编码参数;

S3:建立桌面打包线程,同时创建信道状态监测线程,然后从编码队列中取出数据进行打包发送,当信道状态收到有效反馈则解析出数据放入到状态队列中;

S4:建立动态机制与分析线程,从状态队列中取出当前信道状态,然后进行数据归一化处理,将得到的采集频率和编码参数回调给采集线程和编码线程进行处理。

优选地,步骤S1具体包括如下步骤:

S11:桌面采集功能启动后,创建桌面采集线程,并在采集线程一开始处初始化相关参数,包括线程标记、全局采集频率、线程销毁信号量;

S12:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则更新采集参数,通过回调设置当前采集帧率参数,并根据采集帧率计算每次采集间隔时间,单位毫秒;

S13:传入平均采集间隔时间,并计算等待线程挂起处理;

S14:设置采集缓冲区,使用Grabber接口获取一帧当前桌面数据;

S15:将获取的数据放入到采集队列中,并将该数据回调给本地预览模块进行预览显示;

S16:Sleep 1毫秒释放CPU资源,并继续执行步骤S12。

优选地,步骤S2具体包括如下步骤:

S21:桌面编码功能启动后,创建桌面编码线程,并在桌面编码线程一开始处初始化相关参数,包括线程标记、全局编码码率、线程销毁信号量;

S22:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则更新编码参数,通过回调设置当前编码码率、动态参数标记;

S23:从采集队列取一帧数据,并判断当前数据是否非空,如果为空则Sleep 1毫秒释放CPU资源;

S24:如果获取的采集数据非空,则判断当前采集数据是否发生改变,即采集的宽和高是否与上次不同;

S25:如果采集数据发生改变,则重置图像缩放,如果没有改变则继续执行步骤S26;

S26:如果编码分辨率发生改变,则重置桌面编码器,如果没有改变则继续执行步骤S27;

S27:进行视频预处理,将采集数据按照编码分辨率进行缩放处理;

S28:判断动态参数标记是否为true,如果是则通过编码动态接口实时设置码率及可设质量参数,处理后设置动态参数为false;

S29:进行桌面编码,把编码后的数据放到编码队列中,进行Sleep 0毫秒释放CPU资源,并继续执行步骤S22。

优选地,步骤S3具体包括如下步骤:

S31:桌面打包发送功能启动后,创建桌面打包线程和信道监测线程,并在线程一开始处初始化相关参数,包括线程标记、线程销毁信号量;

S32:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则执行步骤S33;

S33:从编码队列中取出一帧数据,判断取出的编码数据是否为空,如果为空则Sleep 1毫秒释放CPU资源,进行下一循环;

S34:如果取出的编码数据非空,则进行RTP打包,264数据的NAL不超过1500时打Single包,若超过则进行FU-A规则打包;

S35:使用Socket发送打包后数据,进行循环发送。

优选地,步骤S4具体包括如下步骤:

S41:状态控制与监测功能启动后,在线程一开始处初始化相关参数,包括线程标记、线程销毁信号量;

S42:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则执行步骤S43;

S43:从信道监测队列中取出状态数据,如果数据为空,则进行Sleep 1毫秒释放CPU资源,如果数据非空,则继续执行步骤S44;

S44:解析信道状态数据,并对数据进行归一化处理,将信道状态延时和丢包率转化为采集频率和视频编码码率,保证桌面编码最终输出能满足当前信道的变化;

S45:按照步骤S44中归一化结果,将采集频率回调给采集线程,从而实时调整采集线程的采集频率;

S46:按照步骤S44中归一化结果,将视频编码码率回调给编码线程,从而实时调整编码线程,使用新参数无缝衔接编码;

S47:Sleep 1毫秒释放CPU资源,并继续执行步骤S42。

优选地,步骤S13具体包括如下步骤:

S131:获取当前系统时间,判断总采集时间是否为0,并用当前系统时间进行初始化;

S132:判断当前系统时间是否大于总采集时间,如果大于当前总采集时间,则计算当前帧实际的采集时间;

S133:将输入的平均采集间隔时间累加到总采集时间,并更新采集帧数计数器;

S134:判断当前帧实际的采集时间是否小于平均采集间隔,如果小于平均采集间隔,则计算得到线程所需挂起时间;如果大于平均采集间隔,则线程挂起时间为0;

S135:进行Sleep线程挂起操作,保证采集线程均匀采集数据。

优选地,步骤S31中创建信道监测线程具体包括如下步骤:

S311:初始化监测线程参数,设置线程RunFlag标记为true,开启线程运行;

S312:使用Socket接收数据,判断接收的数据是否为空,如果非空则执行步骤S313;如果为空则进行Sleep 1毫秒释放CPU资源,并进行下次循环;

S313:对收到的数据包进行校验,如果检验成功则执行步骤S314,如果校验失败则进行Sleep 1ms释放CPU资源,并进行下次循环;

S314:从传输数据包中解析信道状态数据,将信道监测数据放入到信道监测队列中,继续执行步骤S312;

步骤S35具体包括如下步骤:

S351:判断剩余待发送数据大于0,继续执行循环发送处理;

S352:使用SendTo接口发送一次数据,并得到返回值是实际发送出去的数据大小;

S353:重新计算剩余待发数据;

S354:如果剩余待发数据大于0,则继续执行步骤S351,否则跳出循环继续执行步骤S32。

本发明还提供了一种云会议共享桌面动态编码装置,包括:

动态采集模块,用于建立桌面采集线程,在采集线程中动态采集,将采集到的数据放入到采集队列中;

动态编码模块,用于建立桌面编码线程,从采集队列中取出有效数据,先进行缩放再进行编码处理,同时根据信道状态动态设置编码参数;

打包发送模块,用于建立桌面打包线程,同时创建信道状态监测线程,然后从编码队列中取出数据进行打包发送,当信道状态收到有效反馈则解析出数据放入到状态队列中;

动态控制模块,用于建立动态机制与分析线程,从状态队列中取出当前信道状态,然后进行数据归一化处理,将得到的采集频率和编码参数回调给采集线程和编码线程进行处理。

本发明还提供了一种电子设备,包括处理器和存储器,所述存储器存储有所述处理器可执行的机器可读指令,所述机器可读指令被所述处理器执行时执行如上所述的方法。

本发明还提供了一种存储介质,该存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如上所述的方法。

本发明提供的一种云会议共享桌面动态编码方法、装置、设备及存储介质,通过采用监控信道状态,实时动态调整与控制采集频率与编码码率等参数,实现了桌面视频可以在任意信道中能及时适应信道变化,同时,保证了桌面数据在信道中可靠传输,使得会议共享桌面效果最优,从而提升了用户云会议中共享桌面的使用体验。

附图说明

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

图1为本发明提供的一种云会议共享桌面动态编码方法的流程图;

图2为本发明提供的桌面采集方法的流程图;

图3为本发明提供的桌面编码方法的流程图;

图4为本发明提供的桌面打包发送方法的流程图;

图5为本发明提供的动态控制分析方法的流程图;

图6为本发明提供的一种云会议共享桌面动态编码装置的结构示意图;

图7为本发明提供的电子设备的结构示意图。

附图标记:1、动态采集模块;2、动态编码模块;3、打包发送模块;4、动态控制模块;5、处理器;6、存储器;7、存储介质。

具体实施方式

下面将结合附图对本发明的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

在本发明的描述中,需要说明的是,术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明和简化描述,而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作,因此不能理解为对本发明的限制。此外,术语“第一”、“第二”、“第三”仅用于描述目的,而不能理解为指示或暗示相对重要性。

在本发明的描述中,需要说明的是,除非另有明确的规定和限定,术语“安装”、“相连”、“连接”应做广义理解,例如,可以是固定连接,也可以是可拆卸连接,或一体地连接;可以是机械连接,也可以是电连接;可以是直接相连,也可以通过中间媒介间接相连,可以是两个元件内部的连通。对于本领域的普通技术人员而言,可以具体情况理解上述术语在本发明中的具体含义。

此外,下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

实施例1

本实施例提供了一种云会议共享桌面动态编码方法,需要说明的是,本实施例提供的云会议共享桌面动态编码方法可以被电子设备执行,这里的电子设备是指具有执行计算机程序功能的服务器,此处的服务器例如:x86服务器以及非x86服务器,非x86服务器包括:大型机、小型机和UNIX服务器等。如图1所示,所述方法包括如下步骤:

S1:建立桌面采集线程,在采集线程中动态采集,将采集到的数据放入到采集队列中;

S2:建立桌面编码线程,从采集队列中取出有效数据,先进行缩放再进行编码处理,同时根据信道状态动态设置编码参数;

S3:建立桌面打包线程,同时创建信道状态监测线程,然后从编码队列中取出数据进行打包发送,当信道状态收到有效反馈则解析出数据放入到状态队列中;

S4:建立动态机制与分析线程,从状态队列中取出当前信道状态,然后进行数据归一化处理,将得到的采集频率和编码参数回调给采集线程和编码线程进行处理。

在本实例中,通过平滑动态采集桌面数据,更新动态编码参数,确保编码得到的数据能满足当前信道。同时,实时监控传输信道状态做归一化处理,根据归一化数据去动态调整采集与编码参数。本发明实时综合参考传输信道状态,去动态调整桌面抓取频率及桌面编码参数,有效解决了信道空载及满载情况,充分使用了客户的上行信道,使得会议共享桌面效果最优,从而提升了用户共享桌面的直观体验。

如图2所示,步骤S1具体包括如下步骤:

S11:桌面采集功能启动后,创建桌面采集线程,并在采集线程一开始处初始化相关参数,包括线程标记、全局采集频率、线程销毁信号量;

S12:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则更新采集参数,通过回调设置当前采集帧率参数,并根据采集帧率计算每次采集间隔时间,单位毫秒;

S13:传入平均采集间隔时间,并计算等待线程挂起处理;

S14:设置采集缓冲区,使用Grabber接口获取一帧当前桌面数据;

S15:将获取的数据放入到采集队列中,并将该数据回调给本地预览模块进行预览显示;

S16:Sleep 1毫秒释放CPU资源,并继续执行步骤S12。

如图3所示,步骤S2具体包括如下步骤:

S21:桌面编码功能启动后,创建桌面编码线程,并在桌面编码线程一开始处初始化相关参数,包括线程标记、全局编码码率、线程销毁信号量;

S22:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则更新编码参数,通过回调设置当前编码码率、动态参数标记;

S23:从采集队列取一帧数据,并判断当前数据是否非空,如果为空则Sleep 1毫秒释放CPU资源;

S24:如果获取的采集数据非空,则判断当前采集数据是否发生改变,即采集的宽和高是否与上次不同;

S25:如果采集数据发生改变,则重置图像缩放,如果没有改变则继续执行步骤S26;

S26:如果编码分辨率发生改变,则重置桌面编码器,如果没有改变则继续执行步骤S27;

S27:进行视频预处理,将采集数据按照编码分辨率进行缩放处理;

S28:判断动态参数标记是否为true,如果是则通过编码动态接口实时设置码率及可设质量参数,处理后设置动态参数为false;

S29:进行桌面编码,把编码后的数据放到编码队列中,进行Sleep 0毫秒释放CPU资源,并继续执行步骤S22。

如图4所示,步骤S3具体包括如下步骤:

S31:桌面打包发送功能启动后,创建桌面打包线程和信道监测线程,并在线程一开始处初始化相关参数,包括线程标记、线程销毁信号量;

S32:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则执行步骤S33;

S33:从编码队列中取出一帧数据,判断取出的编码数据是否为空,如果为空则Sleep 1毫秒释放CPU资源,进行下一循环;

S34:如果取出的编码数据非空,则进行RTP打包,264数据的NAL不超过1500时打Single包,若超过则进行FU-A规则打包;

S35:使用Socket发送打包后数据,进行循环发送。

如图5所示,步骤S4具体包括如下步骤:

S41:状态控制与监测功能启动后,在线程一开始处初始化相关参数,包括线程标记、线程销毁信号量;

S42:判断线程RunFlag标记为true线程运行,先检测当前时刻各种信号量是否需要处理,未检测到信号量则执行步骤S43;

S43:从信道监测队列中取出状态数据,如果数据为空,则进行Sleep 1毫秒释放CPU资源,如果数据非空,则继续执行步骤S44;

S44:解析信道状态数据,并对数据进行归一化处理,将信道状态延时和丢包率转化为采集频率和视频编码码率,保证桌面编码最终输出能满足当前信道的变化;

S45:按照步骤S44中归一化结果,将采集频率回调给采集线程,从而实时调整采集线程的采集频率;

S46:按照步骤S44中归一化结果,将视频编码码率回调给编码线程,从而实时调整编码线程,使用新参数无缝衔接编码;

S47:Sleep 1毫秒释放CPU资源,并继续执行步骤S42。

在本实施例中,步骤S44根据下表进行归一化处理:

上表中,分为两种情况:第一种是信道满载,依赖信道状态中丢包率和延迟,其中首要影响视频传输的因素是信道丢包率。它能指明当前信道实际状况,即所有在此信道上传输的数据都会随机(近似泊松分布模型)丢包,则需要桌面编码动态调整发送码率,而与其相关的参数就是编码码率和采集频率。通过此参数来整体降低传输数据量,即是实际发送码率。将空余出的部分码率用来进行信道前向纠错等算法的计算,便能保证新的实际发送码率不超过上次的,便不会再次引起信道满载,从而在接收端按照一定规则解析恢复出丢失的数据。通过此方法机制,来保证桌面视频能在任意信道中可靠传输。

第二种是信道空载,即当前信道传输数据状态良好,低延时无丢包。当连续一段时间(5秒)信道状态信道延时低于10毫秒且丢包率为0%,则提升当前共享桌面编码码率20%。当信道延时高于50毫秒且丢包率为0%,取消共享桌面编码码率提升。若信道出现丢包率非0时,则直接进入到信道满载的处理中。

步骤S13具体包括如下步骤:

S131:获取当前系统时间,判断总采集时间是否为0,并用当前系统时间进行初始化;

S132:判断当前系统时间是否大于总采集时间,如果大于当前总采集时间,则计算当前帧实际的采集时间;

S133:将输入的平均采集间隔时间累加到总采集时间,并更新采集帧数计数器;

S134:判断当前帧实际的采集时间是否小于平均采集间隔,如果小于平均采集间隔,则计算得到线程所需挂起时间;如果大于平均采集间隔,则线程挂起时间为0;

S135:进行Sleep线程挂起操作,保证采集线程均匀采集数据。

步骤S31中创建信道监测线程具体包括如下步骤:

S311:初始化监测线程参数,设置线程RunFlag标记为true,开启线程运行;

S312:使用Socket接收数据,判断接收的数据是否为空,如果非空则执行步骤S313;如果为空则进行Sleep 1毫秒释放CPU资源,并进行下次循环;

S313:对收到的数据包进行校验,如果检验成功则执行步骤S314,如果校验失败则进行Sleep 1ms释放CPU资源,并进行下次循环;

S314:从传输数据包中解析信道状态数据,将信道监测数据放入到信道监测队列中,继续执行步骤S312;

步骤S35具体包括如下步骤:

S351:判断剩余待发送数据大于0,继续执行循环发送处理;

S352:使用SendTo接口发送一次数据,并得到返回值是实际发送出去的数据大小;

S353:重新计算剩余待发数据;

S354:如果剩余待发数据大于0,则继续执行步骤S351,否则跳出循环继续执行步骤S32。

在本实施例中,根据云会议运行设备的性能选定相应编码参数,同时,也依据当前传输信道中的状态来分析当前信道能支持的最大传输数据量。最后,根据传输支持的数据量来实时调整共享桌面采集频率与编码参数,确保最终编码后的数据不超过当前传输信道最大数据量,保证在当前信道中稳定传输,从而使得共享桌面效果达到最优,提升用户的直观体验。

实施例2

本实施例提供了一种云会议共享桌面动态编码装置,如图6所示,包括:

动态采集模块1,用于建立桌面采集线程,在采集线程中动态采集,将采集到的数据放入到采集队列中;

动态编码模块2,用于建立桌面编码线程,从采集队列中取出有效数据,先进行缩放再进行编码处理,同时根据信道状态动态设置编码参数;

打包发送模块3,用于建立桌面打包线程,同时创建信道状态监测线程,然后从编码队列中取出数据进行打包发送,当信道状态收到有效反馈则解析出数据放入到状态队列中;

动态控制模块4,用于建立动态机制与分析线程,从状态队列中取出当前信道状态,然后进行数据归一化处理,将得到的采集频率和编码参数回调给采集线程和编码线程进行处理。

应理解的是,该装置与上述的云会议共享桌面动态编码方法实施例对应,能够执行上述方法实施例涉及的各个步骤,该装置具体的功能可以参见上文中的描述,为避免重复,此处适当省略详细描述。该装置包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在装置的操作系统(operating system,OS)中的软件功能模块。

实施例3

本实施例提供了一种电子设备,如图7所示,包括处理器5和存储器6,所述存储器6存储有所述处理器5可执行的机器可读指令,所述机器可读指令被所述处理器5执行时执行如上所述的方法。

本实施例还提供了一种存储介质7,该存储介质7上存储有计算机程序,该计算机程序被处理器5运行时执行如上所述的方法。

其中,存储介质可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(Static Random Access Memory,简称SRAM),电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory,简称EEPROM),可擦除可编程只读存储器(Erasable Programmable Read Only Memory,简称EPROM),可编程只读存储器(Programmable Red-Only Memory,简称PROM),只读存储器(Read-OnlyMemory,简称ROM),磁存储器,快闪存储器,磁盘或光盘。

本申请提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其他的方式实现。以上所描述的装置实施例仅是示意性的,例如,附图中的流程图和框图显示了根据本申请实施例的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以和附图中所标注的发生顺序不同。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这主要根据所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以使用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

另外,在本申请实施例中的各个实施例的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。

本发明提供的这种云会议共享桌面动态编码方法、装置、设备及存储介质,通过采用监控信道状态,实时动态调整与控制采集频率与编码码率等参数,实现了桌面视频可以在任意信道中能及时适应信道变化,同时,保证了桌面数据在信道中可靠传输,使得会议共享桌面效果最优,从而提升了用户云会议中共享桌面的使用体验。

显然,上述实施例仅仅是为清楚地说明所作的举例,而并非对实施方式的限定。对于所属领域的普通技术人员来说,在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。而由此所引伸出的显而易见的变化或变动仍处于本发明创造的保护范围之中。

相关技术
  • 云会议共享桌面动态编码方法、装置、设备及存储介质
  • 云会议共享桌面动态编码方法、装置、设备及存储介质
技术分类

06120113207462