一种网络直播数据的管理方法以及相关装置与流程
本申请涉及互联网技术领域，尤其涉及一种网络直播数据的管理方法以及相关装置。
背景技术：
随着互联网技术的发展，网络直播间以新颖的形式、丰富的内容吸引了越来越多用户。通常不同的网络直播间用于播放不同的直播内容，终端通过接入到不同的网络直播间，可满足用户的不同观看需求。
一般，为了丰富网络直播的内容，可以将终端与其他终端的交互过程进行视频推流，例如：将当前多人视频通话的内容进行直播推流，即经过转码或多路流混流后，分发到内容分发网络(contentdeliverynetwork，cdn)，然后用户通过信息传输协议拉流观看。
但是，由于涉及多个终端的视频推流，对于某一视频源的网络波动可能对整个直播过程产生影响，容易造成直播延迟，且当某一视频源故障时甚至可能造成直播推流阻塞，影响多终端融合的网络直播过程的稳定性。
技术实现要素：
有鉴于此，本申请提供一种网络直播数据的管理方法，可以有效避免由于多个媒体内容之间的参数差异或网络环境差异，造成的网络直播延迟，提高网络直播过程的稳定性。
本申请第一方面提供一种网络直播数据的管理方法，所述方法应用于网络直播系统中，所述网络直播系统包括数据接入设备、多点控制设备和直播设备，所述方法具体包括：
接收数据接入设备发送的推流请求，所述推流请求包括推流参数，所述推流参数基于所述数据接入设备中待发送的推流数据的媒体内容特征确定，所述推流数据包括至少二个数据来源的媒体内容数据；
根据所述推流参数确定目标端口，所述目标端口用于适配于所述媒体内容特征；
通过所述目标端口接收所述数据接入设备发送的所述推流数据；
向直播设备推送所述推流数据，以使得所述直播设备进行网络直播过程中媒体内容播放。
可选的，在本申请一些可能的实现方式中，所述接收所述数据接入设备发送的推流请求之前，所述方法还包括：
按照预设周期获取负载信息，所述负载信息用于指示异常情况；
若所述负载信息不满足预设条件，则根据所述负载信息确定发生异常的地址信息，所述预设条件基于连接情况以及负载情况确定；
根据所述地址信息进行地址切换，以使得所述负载信息满足所述预设条件。
可选的，在本申请一些可能的实现方式中，所述根据所述推流参数确定目标端口，包括：
接收所述数据接入设备发送的混流请求；
根据所述混流请求确定空闲端口集合，所述空闲端口集合包含所述目标端口；
根据所述推流参数确定所述空闲端口集合中的所述目标端口。
可选的，在本申请一些可能的实现方式中，所述向直播设备推送所述推流数据，包括：
确定所述推流数据的媒体内容类型；
根据所述媒体内容类型对所述推流数据进行分类；
对分类后的所述推流数据分别转换至对应的目标格式，并推送至所述直播设备。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
接收所述直播设备发送的目标参数，所述目标参数基于直播过程的媒体内容特征确定；
根据所述目标参数对所述推流数据进行更新。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
接收所述数据接入设备发送的页面布局参数，所述页面布局参数用于指示所述数据接入设备中至少二个终端设备的页面分布情况；
根据所述页面布局参数对所述推流数据进行更新。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
获取策略调度设备发送的目标密钥，所述目标密钥用于指示所述直播设备的地址；
根据所述目标密钥对所述推流数据进行加密。
本申请第二方面提供另一种数据管理的方法，可以应用于网络直播系统中，所述网络直播系统包括数据接入设备、多点控制设备和直播设备，具体包括：
接收至少二个数据来源发送的推流数据；
根据所述推流数据确定对应的推流参数；
向多点控制设备发送所述推流参数，所述推流参数用于指示所述多点控制设备确定目标端口；
接收所述多点控制设备发送的目标端口的信息；
通过所述目标端口发送所述推流数据。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
根据所述推流数据向所述多点控制设备发送混流请求，所述混流请求用于指示所述多点控制设备确定空闲端口集合；
接收所述多点控制设备发送的空闲端口集合；
根据所述空闲端口集合进行端口同步。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
获取所述终端设备的用户类型；
根据所述用户类型确定接入所述目标端口的终端设备。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
获取所述终端设备发送的页面布局参数；
向所述多点控制设备发送所述页面布局参数，以使得所述多点控制设备对所述推流数据进行更新
本申请第三方面提供一种控制服务器，所述控制服务器应用于网络直播系统中，所述控制服务器具体包括：
调度模块，用于接收数据接入设备发送的推流请求，所述推流请求包括推流参数，所述推流参数基于所述数据接入设备中待发送的推流数据的媒体内容特征确定，所述推流数据包括至少二个数据来源的媒体内容数据；
适配模块，用于根据所述推流参数确定目标端口，所述目标端口用于适配于所述媒体内容特征；
媒体内容模块，用于通过所述目标端口接收所述数据接入设备发送的所述推流数据；
推流模块，用于向直播设备推送所述推流数据，以使得所述直播设备进行网络直播过程中媒体内容播放。
可选的，在本申请一些可能的实现方式中，所述调度模块，还用于按照预设周期获取负载信息，所述负载信息用于指示异常情况；
所述调度模块，还用于若所述负载信息不满足预设条件，则根据所述负载信息确定发生异常的地址信息，所述预设条件基于连接情况以及负载情况确定；
所述调度模块，还用于根据所述地址信息进行地址切换，以使得所述负载信息满足所述预设条件。
可选的，在本申请一些可能的实现方式中，所述适配模块，具体用于接收所述数据接入设备发送的混流请求；
所述适配模块，具体用于根据所述混流请求确定空闲端口集合，所述空闲端口集合包含所述目标端口；
所述适配模块，具体用于根据所述推流参数确定所述空闲端口集合中的所述目标端口。
可选的，在本申请一些可能的实现方式中，所述推流模块，具体用于确定所述推流数据的媒体内容类型；
所述推流模块，具体用于根据所述媒体内容类型对所述推流数据进行分类；
所述推流模块，具体用于对分类后的所述推流数据分别转换至对应的目标格式，并推送至所述直播设备。
可选的，在本申请一些可能的实现方式中，所述方法还包括：
所述调度模块，还用于接收所述直播设备发送的目标参数，所述目标参数基于直播过程的媒体内容特征确定；
所述媒体内容模块，还用于根据所述目标参数对所述推流数据进行更新。
可选的，在本申请一些可能的实现方式中，所述调度模块，还用于接收所述数据接入设备发送的页面布局参数，所述页面布局参数用于指示所述数据接入设备中至少二个终端设备的页面分布情况；
所述媒体内容模块，还用于根据所述页面布局参数对所述推流数据进行更新。
可选的，在本申请一些可能的实现方式中，其特征在于，所述网络直播系统还包括策略调度设备，所述调度模块，还用于获取策略调度设备发送的目标密钥，所述目标密钥用于指示所述直播设备的地址；
所述推流模块，还用于根据所述目标密钥对所述推流数据进行加密。
本申请第四方面提供一种网络设备，可以应用于网络直播系统中，所述网络设备具体包括：
接入模块，用于接收至少二个数据来源发送的推流数据；
流控模块，用于根据所述推流数据确定对应的推流参数；
所述流控模块，还用于向所述多点控制设备发送所述推流参数，所述推流参数用于指示所述多点控制设备确定目标端口；
所述流控模块，还用于接收所述多点控制设备发送的目标端口的信息；
所述接入模块，还用于通过所述目标端口发送所述推流数据。
可选的，在本申请一些可能的实现方式中，所述流控模块，还用于根据所述推流数据向所述多点控制设备发送混流请求，所述混流请求用于指示所述多点控制设备确定空闲端口集合；
所述流控模块，还用于接收所述多点控制设备发送的空闲端口集合；
所述接入模块，还用于根据所述空闲端口集合进行端口同步。
可选的，在本申请一些可能的实现方式中，所述接入模块，还用于获取所述终端设备的用户类型；
所述接入模块，还用于根据所述用户类型确定接入所述目标端口的终端设备。
可选的，在本申请一些可能的实现方式中，所述接入模块，还用于获取所述终端设备发送的页面布局参数；
所述接入模块，还用于向所述多点控制设备发送所述页面布局参数，以使得所述多点控制设备对所述推流数据进行更新。
本申请第五方面提供一种计算机设备，包括：存储器、处理器以及总线系统；所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行上述第一方面或第一方面任一项所述的网络直播数据的管理方法，或上述第二方面或第二方面任一项所述的网络直播数据的管理方法。
本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任一项所述的网络直播数据的管理方法，或上述第二方面或第二方面任一项所述的网络直播数据的管理方法。
从以上技术方案可以看出，本申请实施例具有以下优点：
通过多点控制设备接收数据接入设备发送的推流请求，并确定基于数据接入设备中来自多个终端的推流数据的媒体内容特征设定的推流参数；然后多点控制设备根据推流参数确定目标端口，目标端口用于适配于媒体内容特征；进而多点控制设备通过目标端口接收数据接入设备发送的推流数据并向直播设备推送推流数据，以使得直播设备进行网络直播过程中媒体内容播放。从而实现了多终端媒体内容的融合并进行网络直播的过程，由于在推流过程中对多终端的媒体内容进行了针对性的端口选择，使得多终端的媒体内容可以很好的融合并适配于直播设备，减少了网络波动造成的直播延迟，且避免了由于偶发状况造成的直播推流阻塞，提高了网络直播过程的稳定性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为数据管理系统运行的网络架构图；
图2为本申请实施例提供的一种网络直播的系统架构图；
图3为本申请实施例提供的一种数据管理的方法的流程图；
图4为本申请实施例提供的另一种数据管理的方法的流程图；
图5为本申请实施例提供的一种控制服务器的结构示意图；
图6为本申请实施例提供的一种网络设备的结构示意图；
图7为本申请实施例提供的另一种网络直播的系统框架图；
图8为本申请实施例提供的一种负载均衡的交互示意图；
图9为本申请实施例提供的一种多终端媒体内容混流的交互示意图；
图10为本申请实施例提供的一种多终端媒体内容推流的交互示意图；
图11为本申请实施例提供的另一种多终端媒体内容推流的交互示意图；
图12为本申请实施例提供的另一种数据管理的方法的流程图；
图13为本申请实施例提供的一种网络直播页面的更新示意图；
图14为本申请实施例提供的另一种终端设备的结构示意图；
图15为本申请实施例提供的另一种控制服务器的结构示意图。
具体实施方式
本申请实施例提供了一种网络直播数据管理的方法以及相关装置，可以应用于包含媒体内容播放功能的系统或程序中，通过多点控制设备接收数据接入设备发送的推流请求，并确定基于数据接入设备中来自多个终端的推流数据的媒体内容特征设定的推流参数；然后多点控制设备根据推流参数确定目标端口，目标端口用于适配于媒体内容特征；进而多点控制设备通过目标端口接收数据接入设备发送的推流数据并向直播设备推送推流数据，以使得直播设备进行网络直播过程中媒体内容播放。从而实现了多终端媒体内容的融合并进行网络直播的过程，由于在推流过程中对多终端的媒体内容进行了针对性的端口选择，使得多终端的媒体内容可以很好的融合并适配于直播设备，减少了网络波动造成的直播延迟，且避免了由于偶发状况造成的直播推流阻塞，提高了网络直播过程的稳定性。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先，对本申请实施例中可能出现的一些名词进行解释。
多点控制单元(multipointcontrolunit，mcu)：视频会议系统的核心部分，其主要功能是为用户提供群组会议、多组会议的连接服务。
选择转发单元(selectiveforwardingunit，sfu)：选择转发单元，对音视频数据纯转发，不涉及音视频数据格式、参数等转换及合并，由观看端收到数据后处理。
软件开发工具包(softwaredevelopmentkit，sdk)：辅助开发某一类软件的相关文档、范例和工具的集合。
混流：描述视频和音频数据流的控制、同步以及混合方式，即将视频和音频数据合并。
推流：指的是把采集阶段封包好的内容数据传输到制定设备的过程。
应理解，本申请提供的数据管理方法可以应用于包含网络直播功能的系统或程序中，例如直播平台，具体的，数据管理系统可以运行于如图1所示的网络架构中，如图1所示，是数据管理系统运行的网络架构图，如图可知，数据管理系统可以提供与多个终端设备的媒体内容交互，终端通过网络建立与服务器的连接，进而中转推流至目标终端，以进行网络直播；可以理解的是，图1中示出了多种终端设备，在实际场景中可以有更多或更少种类的终端设备参与到数据管理的过程中，具体数量和种类因实际场景而定，此处不做限定，另外，图1中示出了一个服务器，但在实际场景中，也可以有多个服务器的参与，特别是在多内容应用交互的场景中，具体服务器数量因实际场景而定。
应当注意的是，本实施例提供的数据管理方法也可以离线进行，即不需要服务器的参与，此时终端在本地与其他终端进行连接，进而进行终端之间的数据管理的过程。
可以理解的是，上述数据管理系统可以运行于个人移动终端，例如：作为游戏平台这样的应用，也可以运行于服务器，还可以作为运行于第三方设备以提供数据管理，以得到终端设备的数据管理处理结果；具体的数据管理系统可以是以一种程序的形式在上述设备中运行，也可以作为上述设备中的系统部件进行运行，还可以作为云端服务程序的一种，具体运作模式因实际场景而定，此处不做限定。
随着互联网技术的发展，网络直播间以新颖的形式、丰富的内容吸引了越来越多用户。通常不同的网络直播间用于播放不同的直播内容，终端通过接入到不同的网络直播间，可满足用户的不同观看需求。
一般，为了丰富网络直播的内容，可以将终端与其他终端的交互过程进行视频推流，例如：将当前多人视频通话的内容进行直播推流，即经过转码或多路流混流后，分发到内容分发网络，然后用户通过信息传输协议拉流观看。
但是，由于涉及多个终端的视频推流，对于某一视频源的网络波动可能对整个直播过程产生影响，容易造成直播延迟，且当某一视频源故障时甚至可能造成直播推流阻塞，影响多终端融合的网络直播过程的稳定性。
针对上述问题，可以利用人工智能的方法进行解决。随着人工智能技术研究和进步，人工智能技术在多个领域展开研究和应用，例如常见的智能家居、智能穿戴设备、虚拟助理、智能音箱、智能营销、无人驾驶、自动驾驶、无人机、机器人、智能医疗、智能客服等，相信随着技术的发展，人工智能技术将在更多的领域得到应用，并发挥越来越重要的价值。
而在网络直播过程中，可以基于人工智能进行多终端的直播参数获取并调节，从而提高网络直播过程的稳定性。具体的，基于上述问题，本申请提出了一种数据管理的方法，该方法应用于图2所示的数据管理的流程框架中，如图2所示，为本申请实施例提供的一种网络直播的系统架构图，下面对图中出现的相关设备进行说明：
接口机：用于中转终端设备发送的音视频数据及视频过程中的信令。
流控机：用于实时调节视频过程中的各项音视频参数和音频选路。
配置中心：包含所有机器的位置分布以及实时负载情况，同步到信息中心。
策略调度服务器：负责请求的鉴权、签名加密、安全确认等业务。根据用户位置信息以及机器的位置、负载信息就近分配接口机、流控机。同房间同运营商用户尽量聚集到相同的接口机。
查询服务：包括但不限于查询用户资料、关系链、备注、分组、群关系链、用户产生的信息等。
登录服务：用于快速完成帐号集成接入音视频或即时通信云服务而提供的通用帐号登录组件。
信令服务器：主要负责web侧用户的接入、登录；信令的透传；中转服务器的分配；音视频初始参数的协商下发、连接通道的协商及安全参数的协商下发。
中转服务器：首先，用于面向web用户模拟网页即时通讯与web建立直连，包括互动式连接的建立，数据包传输层安全性协议密钥的协商，安全实时传输协议音视频数据的中转传输及基于rtcp协议的音视频质量控制。其次，用于面向接口机模拟成sdk用户，与现有互动直播系统建立连接，包括进入房间、数据传输等。然后，用于将web和sdk用户的进出房间、状态通知等信令衔接起来。进而将web和sdk用户的双方的音视频数据转码、转封装进行衔接。从而换取统一的标识id，兼容互动直播的房间管理和账号系统。
本申请实施例提供的网络直播数据的管理方法涉及了包括接口机、多点控制设备以及直播设备中的中转服务器的交互过程，即相当于在接口机与中转服务器之间添加了多点控制设备以对网络直播过程中的媒体数据进行管理。
可以理解的是，本申请所提供的方法可以为一种程序的写入，以作为硬件系统中的一种处理逻辑，也可以作为一种数据管理装置，采用集成或外接的方式实现上述处理逻辑。作为一种实现方式，该数据管理装置通过多点控制设备接收数据接入设备发送的推流请求，并确定基于数据接入设备中来自多个终端的推流数据的媒体内容特征设定的推流参数；然后多点控制设备根据推流参数确定目标端口，目标端口用于适配于媒体内容特征；进而多点控制设备通过目标端口接收数据接入设备发送的推流数据并向直播设备推送推流数据，以使得直播设备进行网络直播过程中媒体内容播放。从而实现了多终端媒体内容的融合并进行网络直播的过程，由于在推流过程中对多终端的媒体内容进行了针对性的端口选择，使得多终端的媒体内容可以很好的融合并适配于直播设备，减少了网络波动造成的直播延迟，且避免了由于偶发状况造成的直播推流阻塞，提高了网络直播过程的稳定性。
结合上述流程架构，下面将对本申请中数据管理的方法进行介绍，本申请实施例提供的方案涉及人工智能的机器学习、语音学习等技术，具体通过如下实施例进行说明。请参阅图3，图3为本申请实施例提供的一种数据管理的方法的流程图，应用于网络直播系统中，网络直播系统包括数据接入设备、多点控制设备和直播设备，本申请实施例至少包括以下步骤：
301、数据接入设备根据推流数据获取推流参数。
本实施例中，推流数据包括至少二个数据来源的媒体内容数据，例如：推流数据为三人视频通话的媒体内容数据；而推流参数基于媒体内容数据的特征确定的参数，例如：音频的格式、声道数、音频码率等，或视频的编码格式、分配率、码率、多路画面的排版等参数。另外，数据来源可以是终端设备实时获取的音频、视频等媒体形式，例如手机实时录取的视频；数据来源也可以是网络中的数据资源进行的转发，例如多个不同网站的视频内容，具体形式因实际场景而定。
可以理解的是，具体的推流参数可以是上述事例中的一种或多种的组合，也可以根据推流数据所处的应用场景设定，例如：若推流数据为多人音频通话的内容，则推流参数则为音频的格式、声道数、音频码率；具体的参数形式因实际场景而定，此处不做限定。
通过对于推流参数的获取，可以更好的了解不同终端媒体内容之间的参数差异，进而可以针对性的进行端口选择，从而保证了网络直播过程中多终端媒体内容的结合。
本实施例中，网络直播的过程可以是基于人工智能进行机器学习的过程，即一旦推流数据接入，则根据预设的分析模型对推流数据中的各项参数进行提取，例如：网络直播的需求为高音质，则根据机器学习分析出推流参数应包括音频的格式、声道数、音频码率，并提取具体数据。应理解，在下述实施例的过程中，也可以为机器学习的过程。
302、数据接入设备向多点控制设备发送推流请求。
本实施例中，推流请求中包含了推流参数。
303、多点控制设备接收推流请求并获取推流参数。
304、多点控制设备根据推流参数适配目标端口。
本实施例中，多点控制设备可以根据全局的负载信息和请求来源的位置信息分配数据适配设备、音频处理设备、视频处理设备、推流设备，并向这些设备发送分配端口请求，数据适配设备、音频处理设备、视频处理设备、推流设备在本地建立会话，并分配目标端口。
可选的，多点控制设备关联了网络直播系统中的多个数据适配设备、音频处理设备、视频处理设备、推流设备，在确定目标端口之前，多点控制设备会收集上述关联设备的负载情况，具体可以包括cpu使用率、cpu核数、入流量、出流量、入流数、出流数等，然后根据预设条件选择对应的设备，例如：推流参数中指示需求的关联设备的cpu使用率小于50％，则多点控制设备遍历关联设备中cpu使用率小于50％的设备，并确定该设备的地址以及对应的端口。
可以理解的是，上述关联设备也可以是集成于多点控制设备中的设备，具体的设备形式因实际场景而定，此处不做限定。
通过对于目标端口的确定，保证了网络直播过程中的网络流畅度，即根据不同终端需求的媒体内容参数选择了对应的端口，以实现多终端的媒体内容融合并推流的过程。
305、多点控制设备向数据接入设备发送目标端口信息。
本实施例中，根据上述步骤304中确定的目标端口，确定对应的端口标识以及端口对应的设备地址信息，以打包为目标端口信息，并向数据接入设备发送。
306、多点控制设备与数据接入设备同步目标端口，以建立连接。
本实施例中，同步目标端口的过程即根据端口标识进行端口的选择，以及根据设备地址信息确定对应设备的过程，确定端口以及设备之后即可建立连接。
307、数据接入设备向多点控制设备发送推流数据。
本实施例中，基于上述步骤306中建立的端口连接，数据接入设备向多点控制设备发送推流数据。
308、多点控制设备向直播设备发送推流数据。
本实施例中，在多点控制设备向直播设备发送推流数据之前，还可以确定推流数据的媒体内容类型，例如音频或视频；然后根据媒体内容类型对推流数据进行分类，并对分类后的推流数据分别转换至对应的目标格式，并推送至直播设备。例如：目标格式要求的音频数据格式为mp3，视频数据格式为flv，则对推流数据进行分类为音频数据和视频数据后，分别转换至目标格式。
可以理解的是，媒体内容分类的过程可以是基于语音识别进行的，即通过自动的识别出推流数据中音频的部分，并切换至相应的格式，从而保证了推流过程的针对性。
309、直播设备根据推流数据进行媒体内容的播放。
本实施例中，推流至直播设备的推流数据为融合了至少二个终端设备的媒体内容的数据，其中，媒体内容之间可以是并列的，也可以是层叠的，还可以是相应于用户对于直播设备关联的播放页面的触发情况进行的媒体内容切换，例如：直播设备关联与h5页面，则根据用户在h5页面对于媒体内容的选择情况播放对应的媒体内容。
结合上述实施例可知，通过多点控制设备接收数据接入设备发送的推流请求，并确定基于数据接入设备中来自多个终端的推流数据的媒体内容特征设定的推流参数；然后多点控制设备根据推流参数确定目标端口，目标端口用于适配于媒体内容特征；进而多点控制设备通过目标端口接收数据接入设备发送的推流数据并向直播设备推送推流数据，以使得直播设备进行网络直播过程中媒体内容播放。从而实现了多终端媒体内容的融合并进行网络直播的过程，由于在推流过程中对多终端的媒体内容进行了针对性的端口选择，使得多终端的媒体内容可以很好的融合并适配于直播设备，减少了网络波动造成的直播延迟，且避免了由于偶发状况造成的直播推流阻塞，提高了网络直播过程的稳定性。
上述实施例介绍了数据管理的过程，下面，结合游戏应用作为具体场景进行介绍，请参阅图4，图4为本申请实施例提供的另一种数据管理的方法的流程图，应用于网络直播系统中，网络直播系统包括数据接入设备、多点控制设备和直播设备，本申请实施例至少包括以下步骤：
401、多点控制设备周期性进行负载均衡。
本实施例中，多点控制设备进行负载均衡的过程即按照预设周期获取控制模块的负载信息，负载信息用于指示控制模块的异常情况；若负载信息不满足预设条件，则根据负载信息确定发生异常的控制模块；然后对发生异常的控制模块进行模块切换，以使得负载信息满足预设条件。例如：预设条件为与多点控制设备与关联设备之间的响应延迟小于10毫秒，则检测响应延迟小于10毫秒的关联设备。
可以理解的是，关联设备可以是通过网络与多点控制设备进行关联，并进行功能实现的；关联设备也可以是多点控制设备本地的多个集成设备，具体的关联形式因实际场景而定。
402、数据接入设备向多点控制设备发送混流请求。
本实施例中，由于一般网络直播中的媒体内容为视频与音频的结合内容，为保证视频与音频的对应关系，可以进行混流过程。
403、多点控制设备确定空闲端口集合。
本实施例中，在混流的过程中可以确定多点控制设备的空闲端口集合，即可用的关联设备以及对应的端口。
404、数据接入设备根据推流数据获取推流参数。
405、数据接入设备向多点控制设备发送推流请求。
本实施例中，发送推流请求的过程可以复用混流过程的会话，并且如果用户是混流和推流都需要的，两个请求可以合并为一个请求。
406、多点控制设备接收推流请求并获取推流参数。
407、多点控制设备根据推流参数适配目标端口。
本实施例中，目标端口的选择可以基于混流过程中确定的空闲端口集合进行，从而减小了端口判断的范围，提高了目标端口确定的效率。
408、多点控制设备向数据接入设备发送目标端口信息。
409、多点控制设备与数据接入设备同步目标端口，以建立连接。
410、数据接入设备获取终端设备的用户类型，以确定对应的目标端口。
411、数据接入设备向多点控制设备发送推流数据。
本实施例中，步骤408-步骤411与图3所述实施例中的步骤305-步骤308相似，相关特征可以进行参考，此处不做赘述。
412、多点控制设备将推流数据调整为目标格式以及目标页面布局。
本实施例中，目标格式以及目标页面布局可以是直播设备发送的，也可以是多点控制设备的历史数据处理记录中记录的。若目标格式以及目标页面布局可以是直播设备发送的，则接收直播设备发送的目标参数，目标参数基于直播过程的媒体内容特征确定，然后根据目标参数对推流数据进行更新。
可选的，目标格式以及目标页面布局也可以是数据接入设备关联的终端设备设定的，具体的，多点控制设备接收数据接入设备发送的页面布局参数，页面布局参数用于指示数据接入设备中至少二个终端设备的页面分布情况；然后根据页面布局参数对推流数据进行更新，例如：画中画、四宫格、九宫格等页面布局方式。从而灵活的将多个终端的媒体内容数据进行了融合，提高了网络直播的丰富度。
可以理解的是，目标参数的作用对象可是音频、视频或音频视频的结合；例如在语音直播的场景中，目标参数为音频格式信息；在远程桌面等只有视频的场景中，目标参数为视频格式信息；而在网络直播的场景中，则目标参数则包含了音频格式信息和视频格式信息。通过对对于目标参数针对性的设置，使得在不同的场景中都可以保证直播过程的正常进行。
另外，对于页面布局参数，其作用对象可是音频、视频或音频视频的结合；例如对于音频的混音、视频的“画中画”等应用，提高了直播过程的灵活性。
在另一种可能的场景中，对于目标参数或页面布局参数的作用对象也可以是基于人工智能分析得到的，例如：网络直播系统自动分析推流数据的类型，根据语音识别确定推流数据为音频，则自动提取目标参数中对应于音频的部分，并进行相关的设定。
413、多点控制设备向直播设备发送调整后的推流数据。
本实施例中，为保证推流过程的保密性，可以对推流数据进行加密，其中，加密的过程可以是基于策略调度设备发送的目标密钥，该目标密钥用于指示多点控制设备与直播设备的对应关系，从而为推流数据设置目标密钥。
414、直播设备根据推流数据进行媒体内容的播放。
结合上述实施例可见，在基于服务器sfu方案的trtc基础上，本申请提供的网络直播数据的管理方法可以通过多点控制设备来推送rtmp流或hls流到直播系统，从而实现实时多人通话过程中同时直播。进一步的，由于相关端口的配置以及关联设备的选择，从而获得更低延迟的直播，经统计可得通过rtmp、hls等格式推流并观看可以实现1～3秒延迟，通过h5页面的观看可以实现0.5～1秒的延迟。由于多点控制设备对于推流过程的适配性，在弱网场景可以获得更好的直播体验，且可以灵活定制分辨率、码率、帧率、画面布局，提高直播内容的丰富度。
为了更好的实施本申请实施例的上述方案，下面对上述网络直播数据的管理方法中的相关装置进行进一步的说明。请参阅图5，图5为本申请实施例提供的一种控制服务器的结构示意图，相当于上述实施例中的多点控制设备，控制服务器500包括：
调度模块501，用于接收数据接入设备发送的推流请求，所述推流请求包括推流参数，所述推流参数基于所述数据接入设备中待发送的推流数据的媒体内容特征确定，所述推流数据包括至少二个数据来源的媒体内容数据；
适配模块502，用于根据所述推流参数确定目标端口，所述目标端口用于适配于所述媒体内容特征；
媒体内容模块503，用于通过所述目标端口接收所述数据接入设备发送的所述推流数据；
推流模块504，用于向直播设备推送所述推流数据，以使得所述直播设备进行网络直播过程中媒体内容播放。
可选的，在本申请一些可能的实现方式中，所述调度模块501，还用于按照预设周期获取负载信息，所述负载信息用于指示异常情况；
所述调度模块501，还用于若所述负载信息不满足预设条件，则根据所述负载信息确定发生异常的地址信息，所述预设条件基于连接情况以及负载情况确定；
所述调度模块501，还用于根据所述地址信息进行地址切换，以使得所述负载信息满足所述预设条件。
可选的，在本申请一些可能的实现方式中，所述适配模块502，具体用于接收所述数据接入设备发送的混流请求；
所述适配模块502，具体用于根据所述混流请求确定空闲端口集合，所述空闲端口集合包含所述目标端口；
所述适配模块502，具体用于根据所述推流参数确定所述空闲端口集合中的所述目标端口。
可选的，在本申请一些可能的实现方式中，所述推流模块504，具体用于确定所述推流数据的媒体内容类型；
所述推流模块504，具体用于根据所述媒体内容类型对所述推流数据进行分类；
所述推流模块504，具体用于对分类后的所述推流数据分别转换至对应的目标格式，并推送至所述直播设备。
可选的，在本申请一些可能的实现方式中，所述调度模块501，还用于接收所述直播设备发送的目标参数，所述目标参数基于直播过程的媒体内容特征确定；
所述媒体内容模块503，还用于根据所述目标参数对所述推流数据进行更新。
可选的，在本申请一些可能的实现方式中，所述调度模块501，还用于接收所述数据接入设备发送的页面布局参数，所述页面布局参数用于指示所述数据接入设备中至少二个终端设备的页面分布情况；
所述媒体内容模块503，还用于根据所述页面布局参数对所述推流数据进行更新。
可选的，在本申请一些可能的实现方式中，所述网络直播系统还包括策略调度设备，所述调度模块501，还用于获取策略调度设备发送的目标密钥，所述目标密钥用于指示所述直播设备的地址；
所述推流模块504，还用于根据所述目标密钥对所述推流数据进行加密。
通过多点控制设备接收数据接入设备发送的推流请求，并确定基于数据接入设备中来自多个终端的推流数据的媒体内容特征设定的推流参数；然后多点控制设备根据推流参数确定目标端口，目标端口用于适配于媒体内容特征；进而多点控制设备通过目标端口接收数据接入设备发送的推流数据并向直播设备推送推流数据，以使得直播设备进行网络直播过程中媒体内容播放。从而实现了多终端媒体内容的融合并进行网络直播的过程，由于在推流过程中对多终端的媒体内容进行了针对性的端口选择，使得多终端的媒体内容可以很好的融合并适配于直播设备，减少了网络波动造成的直播延迟，且避免了由于偶发状况造成的直播推流阻塞，提高了网络直播过程的稳定性。
本申请还提供一种网络设备，即上述实施例中的数据接入设备，可以应用于网络直播系统中，请参阅图6，图6为本申请实施例提供的一种网络设备的结构示意图，所述网络设备600具体包括：
接入模块601，用于接收至少二个数据来源发送的推流数据；
流控模块602，用于根据所述推流数据确定对应的推流参数；
所述流控模块602，还用于向所述多点控制设备发送所述推流参数，所述推流参数用于指示所述多点控制设备确定目标端口；
所述流控模块602，还用于接收所述多点控制设备发送的目标端口的信息；
所述接入模块601，还用于通过所述目标端口发送所述推流数据。
可选的，在本申请一些可能的实现方式中，所述流控模块602，还用于根据所述推流数据向所述多点控制设备发送混流请求，所述混流请求用于指示所述多点控制设备确定空闲端口集合；
所述流控模块602，还用于接收所述多点控制设备发送的空闲端口集合；
所述接入模块601，还用于根据所述空闲端口集合进行端口同步。
可选的，在本申请一些可能的实现方式中，所述接入模块601，还用于获取所述终端设备的用户类型；
所述接入模块601，还用于根据所述用户类型确定接入所述目标端口的终端设备。
可选的，在本申请一些可能的实现方式中，所述接入模块601，还用于获取所述终端设备发送的页面布局参数；
所述接入模块601，还用于向所述多点控制设备发送所述页面布局参数，以使得所述多点控制设备对所述推流数据进行更新。
上述实施例介绍了网络设备和控制服务器的功能组成，下面结合具体的网络直播系统框架对网络设备和控制服务器中各功能模块的交互情况进行说明，请参阅图7，图7为本申请实施例提供的另一种网络直播的系统框架图，与图2所示的网络直播的系统框架相比，相当于将图2中的多点控制设备划分为了调度模块、适配模块、音频模块、视频模块以及推流模块。
具体的，在图7所示的系统框架中，调度模块定期收集适配模块、音频模块、视频模块以及推流模块的负载信息、地理位置信息、机器死活状态，用于指导这些模块的分配及发生死机是动态切换机器。接收流控模块的申请混流或推流请求，依据请求信息中的地理位置信息，就近负载均衡分配适配模块、音频模块、视频模块以及推流模块的对应的执行设备，并向执行设备请求分配端口后，返回结果到流控。
对于适配模块，具体用于定期上报负载信息给调度模块。从调度模块收到分配请求后，分配端口并在本地建立会话，之后接收从接口机发送过来的数据，处理后分发到后端的音频模块、视频模块。
对于音频模块，具体用于对多路音频进行选路，依据直播方的需要做音频混流及转码成直播方需要的音频格式。
对于视频模块，具体用于依据直播方需要做选路及排版，并按直播方需求转码为相应的视频格式，分辨率、帧率、码率。
对于推流模块，具体用于将音频模块和视频模块处理后的音视频数据，封装成rtmp流，并推送的直播系统。
下面结合图7所示的网络直播的系统框架，对图3或图4中涉及的网络直播数据管理的方法对应的模块交互过程进行说明。如图8所示，为本申请实施例提供的一种负载均衡的交互示意图。具体的，适配模块、音频模块、视频模块、推流模块周期性向调度模块上报负载信息，例如：每秒都进行负载信息的上传，其中，负载信息包括：cpu使用率、cpu核数、入流量、出流量、入流数、出流数；然后调度模块接收四个模块的负载信息以及配置的各机器地理位置信息，从而实时掌握全局各模块各地域的负载情况。
进一步的，适配模块、音频模块、视频模块、推流模块还可以相互检测到上下游模块连接断开情况；若检测到断开，则上报到调度模块，调度该模块依据机器死活及负载情况指导切换合适的设备。
另外，对于推流数据的混流过程如图9所示，为本申请实施例提供的一种多终端媒体内容混流的交互示意图。包括如下步骤：
901、流控机发起混流指令到调度模块。
902、调度模块分配端口，即调度模块依据全局的负载信息和请求来源的位置信息分配数据适配设备，并向该设备发送分配端口请求，数据适配机器在本地建立该用户的会话，并分配空闲端口，结果返回给调度模块。
903、调度模块将分配的适配模块端口信息以及设备的ip信息返回给流控机。
904、流控机将适配模块发送的端口信息以及设备的ip信息同步到接口机。
905、接口机得到适配模块的端口信息以及设备的ip信息后建立与适配模块的连接，并发送数据。
另外，在推流过程中，具体的模块交互过程如图10所示，为本申请实施例提供的一种多终端媒体内容推流的交互示意图。包括如下步骤：
1001、流控发送推流指令到调度模块，并写入相应的推流参数，如音频的音频格式、声道数、音频码率等，或视频的编码格式、分配率、码率、多路画面的排版等参数。
1002、调度模块模块依据全局的负载信息和请求来源的位置信息分配数据适配、音频处理、视频处理、推流机器，并向这些机器发送分配端口请求，数据适配、音频处理、视频处理、推流机器在本地建立该用户的会话，并分配空闲端口，结果返回给调度模块。
可以理解的是，如果该用户在适配模块已经存在上行混流的会话，这里会复用上行的会话，并且如果用户是混流和推流都需要的，两个请求可以合并为一个请求。音频处理和视频模块在建立本地会话的同时，保存相关音视频参数。
1003、调度模块模块将分配的数据适配、模块的端口信息以及设备的ip信息返回给流控。
1004、流控将适配模块的端口信息以及设备的ip信息同步到接口机。
本实施例中，图中示出了两个接口机，在实际场景中可以有更多或更少的接口机参与，具体的可以参考与网络设备关联的终端设备的数量设定接口机的数量；也可以根据终端设备对应的用户类型确定接口机的数量，具体的设定规则因实际场景而定，此处不做限定。
1005、接口机得到适配模块的端口信息以及设备的ip信息后建立与适配模块的连接，并发送数据。
1006、调度模块模块将分配的音频处理和视频处理的端口信息以及设备的ip信息同步到适配模块，将推流模块端口信息以及设备的ip信息同步到音频处理和视频模块。
1007、适配模块拿到音频处理和视频处理的端口信息以及设备的ip信息后与音频处理和视频处理的设备建立连接，并发送音视频数据。
1008、推流模块与直播设备建立连接，收到了音频模块和视频模块的数据后，推流rtmp数据到直播系统。
可以理解的是，适配模块可支持标准的rtp协议，也可以支持各类私有音视频传输协议。服务器mcu推流出的流格式不局限于rtmp、hls。
可选的，考虑到与网络设备关联的终端设备可能是主播也可能是观众，即主播需要进行数据推流，而观众不需要，如图11所示，为本申请实施例提供的另一种多终端媒体内容推流的交互示意图。图中包括一个3人实时多人音视频通话房间为例说明上行数据处理过程，对应的接口机上有a、b、c三个用户端口，其中a、b有上行数据，即为主播；c是观众用户，不需要进行数据推流。即该过程包括：
1101、接口机获取用户的类型。
1102、接口机根据用户类型分配端口，以与适配模块进行连接。
1103、适配模块接收到a、b各自发送的上行音视频数据后对数据包排序及丢包恢复，之后解出音频帧并逐帧传给音频模块并附带音频参数如音频格式、声道数等，解出视频帧并逐帧传递给视频模块，并附带编码格式、分配率等视频参数。适配模块需要接收处理不同协议的数据，如标准的rtp数据，或私有的udp音视频数据。音频模块收到音频数据后依据保存的推流参数做混音、转码，之后发送到推流模块。视频模块接收到视频数据后依据保存的推流参数做画面布局，并按直播需要的分辨率、码率、帧率混流，之后发送到推流模块。
1104、推流模块收到音视频数据后将其封装成rtmp格式，推流到直播系统。
通过上述实施例可见，本申请提供的网络直播数据管理的方法可以将实时多人音视频通话的产品同时推流到直播系统，使用直播服务。且在直播业务中，也可以采用实时多人通话的客户端来做直播的采集和推流，以获取更佳的推流延迟和弱网推流效果。推流可灵活定制分辨率、码率、帧率、画面布局。
上述实施例中的方法和装置具体应用于多终端媒体内容融合的网络直播场景中，在该场景中，用户可以灵活的加入多终端媒体内容交互过程，例如：多人视频通话的过程，然后将该视频通话内容推流至网络直播系统，以便于对网络直播过程中的媒体内容进行更新。如图12所示，为本申请实施例提供的另一种数据管理的方法的流程图，图中第一终端为准备加入直播间并进行媒体内容推流的终端，该直播间中第二终端的媒体内容正在推流至第三终端进行播放，其中，第一终端和第二终端可以通过客户端sdk进行网络直播媒体内容的生成，而第三终端可以通过h5页面进行网络直播的收看。具体的，上述过程包括如下步骤：
1201、第二终端与第三终端建立了媒体内容的第一连接。
本实施例中，第二终端与第三终端建立的第一连接即第三终端正在播放第二终端推送的媒体内容。
1202、第一终端向第二终端发送加入请求。
本实施例中，第一终端向第二终端发送加入请求可以包括第一终端的推流参数，即第一终端中媒体内容的特征参数，例如：画面分辨率、码率、帧率、画面布局等。
1203、第二终端向控制服务器申请混流。
1204、第二终端确定适配的目标端口。
1205、第二终端与第一终端进行配置并同步目标端口，以建立第二连接。
1206、第二终端向第三终端发送推流数据。
1207、第一终端、第二终端与第三终端之间建立媒体内容第三连接。
本实施例中，步骤1203-步骤1207的内容与图4所示实施例的步骤404-413类似，相关特征可以进行参考，此处不做赘述。
1208、第三终端根据推流数据进行媒体内容的播放。
在一种可能的场景中，第三终端的页面变化情况如图13所示，图13为本申请实施例提供的一种网络直播页面的更新示意图，图中左侧为第三终端与第二终端建立第一连接时的直播界面，在经过上述实施例中第一终端的媒体内容加入后，由于在推流数据中包括了页面布局参数，直播界面可以进行重新排布，即得到如图13右侧的直播界面，从而实现了多终端媒体内容的融合过程并推流至直播系统进行播放，保证了直播页面的媒体内容的丰富度，且在添加媒体内容时具有良好的稳定性。
本申请实施例还提供了一种终端设备，如图14所示，是本申请实施例提供的另一种终端设备的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、个人数字助理(personaldigitalassistant，pda)、销售终端(pointofsales，pos)、车载电脑等任意终端设备，以终端为手机为例：
图14示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图14，手机包括：射频(radiofrequency，rf)电路1410、存储器1420、输入单元1430、显示单元1440、传感器1450、音频电路1460、无线保真(wirelessfidelity，wifi)模块1470、处理器1480、以及电源1490等部件。本领域技术人员可以理解，图14中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
下面结合图14对手机的各个构成部件进行具体的介绍：
rf电路1410可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1480处理；另外，将设计上行的数据发送给基站。通常，rf电路1410包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(lownoiseamplifier，lna)、双工器等。此外，rf电路1410还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(globalsystemofmobilecommunication，gsm)、通用分组无线服务(generalpacketradioservice，gprs)、码分多址(codedivisionmultipleaccess，cdma)、宽带码分多址(widebandcodedivisionmultipleaccess,wcdma)、长期演进(longtermevolution，lte)、电子邮件、短消息服务(shortmessagingservice，sms)等。
存储器1420可用于存储软件程序以及模块，处理器1480通过运行存储在存储器1420的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1420可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1420可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
输入单元1430可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1430可包括触控面板1431以及其他输入设备1432。触控面板1431，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1431上或在触控面板1431附近的操作，以及在触控面板1431上一定范围内的隔空触控操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1431可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1480，并能接收处理器1480发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1431。除了触控面板1431，输入单元1430还可以包括其他输入设备1432。具体地，其他输入设备1432可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元1440可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1440可包括显示面板1441，可选的，可以采用液晶显示器(liquidcrystaldisplay，lcd)、有机发光二极管(organiclight-emittingdiode，oled)等形式来配置显示面板1441。进一步的，触控面板1431可覆盖显示面板1441，当触控面板1431检测到在其上或附近的触摸操作后，传送给处理器1480以确定触摸事件的类型，随后处理器1480根据触摸事件的类型在显示面板1441上提供相应的视觉输出。虽然在图14中，触控面板1431与显示面板1441是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1431与显示面板1441集成而实现手机的输入和输出功能。
手机还可包括至少一种传感器1450，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1441的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1441和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。
音频电路1460、扬声器1461，传声器1462可提供用户与手机之间的音频接口。音频电路1460可将接收到的音频数据转换后的电信号，传输到扬声器1461，由扬声器1461转换为声音信号输出；另一方面，传声器1462将收集的声音信号转换为电信号，由音频电路1460接收后转换为音频数据，再将音频数据输出处理器1480处理后，经rf电路1410以发送给比如另一手机，或者将音频数据输出至存储器1420以便进一步处理。
wifi属于短距离无线传输技术，手机通过wifi模块1470可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图14示出了wifi模块1470，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。
处理器1480是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1420内的软件程序和/或模块，以及调用存储在存储器1420内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1480可包括一个或多个处理单元；可选的，处理器1480可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1480中。
手机还包括给各个部件供电的电源1490(比如电池)，可选的，电源可以通过电源管理系统与处理器1480逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。
在本申请实施例中，该终端所包括的处理器1480还具有执行如上述数据管理方法的各个步骤的功能。
本申请实施例还提供了一种控制服务器，请参阅图15，图15是本申请实施例提供的另一种控制服务器的结构示意图，该控制服务器1500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)1522(例如，一个或一个以上处理器)和存储器1532，一个或一个以上存储应用程序1542或数据1544的存储介质1530(例如一个或一个以上海量存储设备)。其中，存储器1532和存储介质1530可以是短暂存储或持久存储。存储在存储介质1530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1522可以设置为与存储介质1530通信，在服务器1500上执行存储介质1530中的一系列指令操作。
服务器1500还可以包括一个或一个以上电源1526，一个或一个以上有线或无线网络接口1550，一个或一个以上输入输出接口1558，和/或，一个或一个以上操作系统1541，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。
上述实施例中由模型训练装置所执行的步骤可以基于该图15所示的服务器结构。
本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有数据管理指令，当其在计算机上运行时，使得计算机执行如前述图3至图4所示实施例描述的方法中多点控制设备或数据接入设备所执行的步骤。
本申请实施例中还提供一种包括数据管理指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如前述图3至图4所示实施例描述的方法中多点控制设备或数据接入设备所执行的步骤。
本申请实施例还提供了一种数据管理系统，所述数据管理系统可以包含图5所描述实施例中的控制服务器，或者图6所描述的网络设备。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，数据管理装置，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
- 还没有人留言评论。精彩留言会获得点赞！