CN110430383A - 终端、信令服务器、音视频通信方法及计算机存储介质 - Google Patents

Abstract

本公开提供了一种终端、信令服务器、音视频通信方法及计算机存储介质。所述方法包括发出音视频邀请至多个接听终端；获取预测接听终端的音视频处理引擎类型；在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至所述预测接听终端，并接收所述预测接听终端所发送的要通信的音视频内容；在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，当该接起的接听终端的音视频处理引擎类型与所述预测接听终端的音视频处理引擎类型一致时，在所述邀请方终端本地播放所述接起的接听终端所发送的要通信的音视频内容。本公开提高了音视频通话中终端上首帧显示速度。

Description

终端、信令服务器、音视频通信方法及计算机存储介质

技术领域

本公开涉及音视频通讯，特别涉及一种终端、信令服务器、音视频通信方法及计算机存储介质。

背景技术

实时音视频通讯为用户的生活提供了极大的便利。实时音视频通讯的多方视频通讯必须使用同一个音视频处理引擎，这样在更换或增加音视频底层引擎时，需要所有的终端进行升级，否则存在无法使用的风险。

在相关技术中，通过将终端中的引擎进行升级，以向下兼容多个未升级的引擎，以达到升级的终端和未升级终端可以实现音视频通讯的目的。具体是，例如，终端A具有升级引擎，同时兼容引擎e1、引擎e2，终端B具有未升级引擎，只有引擎e1，即终端A需要切换到引擎e1才能与终端B通讯。但是在终端A邀请终端B进行视频通话时，无法预先获知终端B有没有升级，从而不知道该用哪个引擎进行通讯，因而也就无法在被叫接听之前这个响铃阶段进行引擎的初始化、以预先完成音视频的处理流程，这样大大降低了在通讯连接成功后，终端上首帧显示速度。

发明内容

本公开的一个目的在于提高音视频通话中终端上首帧显示速度；

为解决上述技术问题，本公开采用如下技术方案：

本公开提出一种音视频通讯方法，所述方法由音视频通讯的邀请方终端执行，所述方法包括：

发出音视频邀请至受邀账号，所述受邀账号绑定多个接听终端；

获取所述多个接听终端中预测接听终端的音视频处理引擎类型；

在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至所述预测接听终端，并接收所述预测接听终端所发送的要通信的音视频内容；

在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

当该接起的接听终端的音视频处理引擎类型与所述预测接听终端的音视频处理引擎类型一致时，在所述邀请方终端本地播放所述接起的接听终端所发送的要通信的音视频内容。

可选的，所述在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至所述预测接听终端，并接收所述预测接听终端所发送的要通信的音视频内容的步骤包括：

在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎类型相同的音视频处理引擎；

推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器将该音视频内容下发至所述预测接听终端，并从所述媒体服务器接收所述预测接听终端发送的要通信的音视频内容。

可选的，所述推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器转发至所述预测接听终端，并从所述媒体服务器接收所述预测接听终端发送的要通信的音视频内容的步骤包括：

推送所述邀请方终端要通信的音视频内容到与预测接听终端的音视频处理引擎类型对应的媒体服务器；并从该媒体服务器上接收所述预测接听终端发送的要通信的音视频内容。

可选的，在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型之后，所述方法还包括：

当该接起的接听终端的音视频处理引擎类型与所述预测接听终端的音视频处理引擎类型不一致时，将所述邀请方终端本地启动的音视频处理引擎切换为与该接起的接听终端的音视频处理引擎类型相同的引擎，以推送邀请方终端要通信的音视频内容到接起的接听终端；并接收所述接起的接听终端所发送的要通信的音视频内容(并在本地进行播放)；

在所述邀请方终端本地播放所述接起的接听终端所发送的要通信的音视频内容。

可选的，所述将所述邀请方终端本地启动的音视频处理引擎切换为与该接起的接听终端的音视频处理引擎类型相同的引擎，以推送邀请方终端要通信的音视频内容到接起的接听终端；并接收所述接起的接听终端所发送的要通信的音视频内容的步骤包括：

在所述邀请方终端本地启动与所述接起的接听终端的音视频处理引擎类型相同类型的音视频处理引擎；

推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器转发至所述接起的接听终端；从所述媒体服务器接收所述接起的接听终端发送的要通信的音视频内容。

可选的，所述推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器转发至所述接起的接听终端；从所述媒体服务器接收所述接起的接听终端发送的要通信的音视频内容包括：

推送邀请方终端要通信的音视频内容到与该接起的接听终端的音视频处理引擎类型对应的媒体服务器；并从该媒体服务器接收所述接起的接听终端发送的要通信的音视频内容。

可选的，所述预测接听终端是由在所述邀请方终端和所述多个接听终端之间通信的信令服务器通过以下方式预测的：

接收所述多个接听终端接收到所述音视频邀请后反馈的音视频处理引擎类型；

将最先接收到的音视频处理引擎类型来自的接听终端作为所述预测接听终端。

可选的，所述预测接听终端是由在所述邀请方终端和所述多个接听终端之间通信的信令服务器通过以下方式预测的：

接收所述多个接听终端接收到所述音视频邀请后反馈的接听终端加速度；

将反馈的接听终端加速度最大的接听终端作为所述预测接听终端。

可选的，所述预测接听终端是由在所述邀请方终端和所述多个接听终端之间通信的信令服务器通过以下方式预测的：

接收所述多个接听终端接收到所述音视频邀请后反馈的接起音视频邀请的次数；

根据本公开的另一方面，提出一种终端音视频通讯方法，所述方法由在所述邀请方终端和所述多个接听终端之间通信的信令服务器执行；所述方法包括：

接收到邀请方终端向受邀账号发出的音视频邀请，推送音视频邀请至与该受邀账号绑定的多个接听终端；

根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端；

将该预测接听终端的引擎类型发送至所述邀请方终端；

在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

将该接起的接听终端的音视频处理引擎类型发送至所述邀请方终端。

可选的，所述根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端包括：

接收所述多个接听终端接收到所述音视频邀请后反馈的音视频处理引擎类型；

将最先接收到的音视频处理引擎类型来自的接听终端作为所述预测接听终端。

可选的，所述根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端包括：

接收所述多个接听终端接收到所述音视频邀请后反馈的接听终端加速度；

将反馈的接听终端加速度最大的接听终端作为所述预测接听终端。

可选的，所述根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端包括：

接收所述多个接听终端接收到所述音视频邀请后反馈的接起音视频邀请的次数；

将反馈的接起音视频邀请的次数最大的接听终端作为所述预测接听终端。

根据本公开的再一方面，提出一种音视频通讯方法，其特征在于，所述方法由接听终端执行；邀请方终端和所述接听终端之间具有用于通信的信令服务器；所述方法包括：

接收到所述邀请方终端发送的音视频邀请；

发送所述接听终端本地的音视频处理引擎类型至信令服务器，并推送该接听终端要通信的音视频内容至媒体服务器；

当该接听终端本地具有与所述邀请方终端的引擎类型相同的音视频处理引擎类型时，接收所述邀请方终端发送的要通信的音视频内容；

响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器；

当该接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型相同时，在该接听终端本地播放所述邀请方终端发送的要通信的音视频内容。

可选的，所述响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器之后还包括：

当该接听终端的音视频处理引擎类型与预测的接听终端的音视频处理引擎类型不相同时，待所述邀请方终端切换音视频引擎类型后，接收所述邀请方终端要通信的音视频内容；

在该接听终端本地播放所述邀请方发送的要通信的音视频内容。

可选的，所述接听终端内具有加速度传感器；所述发送所述接听终端本地的音视频处理引擎类型至信令服务器包括：

上传所述加速度传感器检测的运动加速度，以及接听终端本地的音视频处理引擎类型；其中，所述信令服务器根据所述接听终端的加速度在多个所述接听终端中确定一个所述预测接听终端。

可选的，所述接听终端内保存有接起音视频邀请的次数；所述发送所述接听终端本地的音视频处理引擎类型至信令服务器包括：

上传保存的接起音视频邀请的次数，以及所述接听终端本地的音视频处理引擎类型；其中，所述信令服务器根据所述接起音视频邀请的次数在多个所述接听终端中确定一个预测接听终端；

所述响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎至信令服务器，并在本地播放所述邀请方终端所发送的要通信的音视频内容的步骤之后还包括：

更新所保存的接起音视频邀请的次数。

根据本公开的另一方面提出一种终端，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的音视频通讯程序，所述处理器执行所述音视频通讯程序时实现所述的音视频通讯方法。

根据本公开的另一方面提出一种信令服务器，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的音视频通讯程序，所述处理器执行所述音视频通讯程序时实现所述的音视频通讯方法。

根据本公开的另一方面提出一种计算机存储介质，其存储有计算机程序代码，当其被计算机的处理单元执行时，实现由邀请方终端、信令服务或由接听终端所对应的所述的音视频通讯方法。

本实施例通过预测接听终端的设置，以使邀请方终端可以根据预测接听终端的引擎设定一个先行引擎，从而实现与预测接听终端互换音视频内容的目的，为用户最终在该预测接听终端上接起该音视频邀请完成了预先的音视频信息处理以及交换的工作，提高了通讯效率，使得音视频通讯的邀请方以及接起的接听终端双方播放对方所传输的音视频内容的首帧时间得到了有效的缩短，特别是对于接起的接听终端，用户在接起音视频邀请后，几乎无需等待即可以从接起的终端上看到邀请方终端所传输来的音视频内容，由此大大提高了用户体验。

附图说明

图1A为一个环境或智能电视实例的第一个视图；

图1B为一个环境或智能电视实例的第二个视图；

图2为一个智能电视实例的第一个视图；

图3是一个智能电视硬件实例的方框图；

图4是一个智能电视软件和/或固件实例的方框图；

图5是一个智能电视软件和/或固件实例的第二个方框图；

图6是一个智能电视软件和/或固件实例的第三个方框图；

图7是一个内容实数据服务实例的方框图；

图8是一个智能电视屏幕实例的正视图；

图9是针对内容/筒仓选择器的一个用户界面的直观形象实例；

图10是一个示例性的C/S通信框架；

图11是本公开音视频通讯方法的一应用场景实施例；

图12是由邀请方终端所执行的音视频通讯方法一实施例流程图；

图13是由信令服务器所执行的音视频通讯方法一实施例流程图；

图14是由接听终端所执行的音视频通讯方法一实施例流程图。

具体实施方式

在以下描述中，阐述了大量特定细节以提供对本公开实施例的更透彻说明。然而，对于本领域技术人员显而易见的是，在实现本公开实施例而可以不用这些特定细节。

本公开说明书中使用的术语仅出于描述特定实施例的目的，并且不是要限制本公开。如在本公开的说明书和权利要求中使用的那样，除非上下文另外特别指示，否则单数形式“一个”、“一种”和“该”也旨在包括复数形式。还应理解，这里使用的术语“和/或”指的是并且包括相关联地列出的项中的一个或多个的任意和所有可能的组合。还应理解，在本说明书中使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、元件和/或部件的存在，但不排除一个或多个其它特性、整数、步骤、操作、元件、部件和/或它们的组的存在或添加。

并且包括相关联地列出的项中的一个或多个的任意和所有可能的组合。还应理解，在本说明书中使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、元件和/或部件的存在，但不排除一个或多个其它特性、整数、步骤、操作、元件、部件和/或它们的组的存在或添加。

本公开提出一种音视频通讯方法以及终端，该终端可以是是智能终端或通信终端。该终端或通信终端包括但不限于被设置成经由有线线路连接，如经由公共交换电话网络(public switched telephonenetwork，PSTN)、数字用户线路(digital subscriberline，DSL)、数字电缆、直接电缆连接，以及/或另一数据连接/网络和/或经由例如，针对蜂窝网络、无线局域网(wireless local area network，WLAN)、诸如手持数字视频广播(digital video broadcasting handheld，DVB-H)网络的数字电视网络、卫星网络、调幅-调频(amplitude modulation-frequency modulation，AM-FM)广播发送器，以及/或另一通信终端的无线接口接收/发送通信信号的装置。被设置成通过无线接口通信的通信终端可以被称为“无线通信终端”、“无线终端”以及/或“智能终端”。智能终端的示例包括，但不限于卫星或蜂窝电话；可以组合蜂窝无线电电话与数据处理、传真以及数据通信能力的个人通信系统(personal communication system，PCS)终端；可以包括无线电电话、寻呼机、因特网/内联网接入、Web浏览器、记事簿、日历以及/或全球定位系统(global positioningsystem，GPS)接收器的个人数字助理(Personal Digital Assistant，PDA)；以及常规膝上型和/或掌上型接收器或包括无线电电话收发器的其它电子设备。

术语“网页电视”是通过万维网播送的原始电视内容。主要的网页电视分销商有YouTube、Myspace、Newgrounds、Blip.tv和Crackle等。

“网络电视”(也称为互联网电视、在线电视)是通过互联网传送电视内容的数字分配。不应将网络电视与网页电视和互联网协议电视(IPTV)混淆，网页电视是各种不同的公司和个人创建的短小节目或视频，互联网协议电视是电视广播商使用的新兴的互联网技术标准。互联网电视是一个通用术语，是指通过视频流技术在互联网上传送电视节目和其他视频内容，一般由大型传统电视广播商使用。但不是指用于传送内容的技术(见互联网协议电视)。

“互联网协议电视”(IPTV)是指使用互联网协议组在互联网等分组交换网络上传送电视服务的系统，而不是通过传统的地面、卫星信号和有线电视格式传送。IPTV服务可以归为三大组：直播电视，有或没有和目前电视节目相关的互动性；时移电视：节目重温(重播数小时或数天前的电视节目)，重新播放(从头开始播放当前的电视节目)；以及视频点播(VOD)：浏览视频目录，该目录与电视节目编排无关。IPTV与互联网电视有着明显的不同，前者有着持续的标准化过程(例如欧洲电信标准协会)和对用户电信网络有利的部署方案，通过机顶盒或其他客户端设备为终端用户场所提供高速访问通道。

“智能电视”有时称为混合型电视，描述了在电视或机顶盒中整合互联网和Web2.0及以上的功能，以及计算机部分功能和这些电视机/机顶盒技术融合的趋势。与传统电视接收机和机顶盒相比，更加侧重于在线互动媒体、互联网电视、机顶盒内容以及点播式流媒体，较少侧重于或改进传统广播媒体。

“电视”是一种电信介质、设备(或装置)或一系列相关的设备、节目和/或传输设备，用于传输和接收单色(黑白)或彩色的动态影像，或有或没有声音伴随。电视最常用于显示广播电视信号。广播电视系统一般在54–890MHz频带中指定的频道上通过有线或无线电传播。没有调谐器的视觉显示设备应称为视频监视器，而不是电视。电视和其他监视器或显示器的不同之处在于，用户在观看媒体时和电视保持的距离，以及电视具有调谐器其他接收广播电视信号的电路。

本申请中使用的术语“计算机可读媒体”是指参与提供执行指令给处理器的任何有形的存储和/或传输媒体。这种媒体有多种形式，包括但不限于非易失性媒体、易失性媒体和传输媒体。非易失性媒体包括NVRAM、磁盘或光盘等。易失性媒体包括动态存储器，如主存储器。一般形式的计算机可读媒体包括软磁盘、软盘、硬盘、磁带或任何其他磁性介质、磁光介质、光盘、任何其他光学介质、穿孔卡、纸带、任何其他带有一定孔图的物理介质、RAM(随机存储器)、PROM(可编程只读存储器)和EPROM(可擦除可编程只读存储器)、FLASHEPROM、固态介质如内存卡，任何其他内存芯片或内存匣、下文所述的载波或计算机可读取的任何其他介质。电子邮件的数字文件附件或其他自含信息档案或档案集被视为相当于有形存储介质的分配介质。当计算机可读媒体被配置为数据库时，应该理解，数据库可以是任何类型的数据库，如关系型、层级型、面向对象型和/或类似的类型。相应地，本申请中被视为包括有形存储介质或分配介质和现有技术认可的对等物和后续开发媒体，本申请中的软件实施保存在这些介质中。

本申请中使用的术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件和软件的组合，能够执行与该元件相关的功能。此外，虽然本申请按照示范性实例来介绍，但应理解，可以就这些申请的各个方面单独提出权利要求。

本申请中使用的术语“确定”、“计算”和“计算机计算”及其变通说法，可互换使用，并包括任何类型的方法论、过程、数学运算或技巧。

此后，当本公开提到“选择”、“被选择”“将选择”或“正选择”GUI中的用户界面元素时，这些属于应该被理解为包括使用鼠标或其他输入设备，在用户界面元素之上点击或者“悬停”，或使用一个或者多个手指或触针在用户界面元素上触摸屏幕、敲击或做出手势动作。用户界面元素可以是虚拟按钮、菜单按钮、选择器、开关、滑动条、橡皮擦、旋钮、缩略图、链接、图标、单选按钮、复选框和接收来自用户输入的任何其他机制。

智能电视(TV)环境：

参考图1A和1B所示的智能电视100的一些实施例。智能电视100可用于娱乐、商业应用、社交互动、内容创建和/或消费，和/或，还包括用于组织和控制与智能电视100进行通信的一个或多个其他设备。因此可以理解为，智能电视可以用于增强用户互动体验，无论是在家中还是工作场所。

在一些实例中，智能电视100可以通过配置来接收和理解各种用户和/或设备输入。例如，用户可通过一个或多个物理或电子控件和智能电视100互动，这些控件可包括按钮、开关、触摸屏/区(如电容式触摸屏、电阻式触摸屏等)和/或与智能电视100关联的其他控件。在某些情况中，智能电视100可包含一个或多个互动控件。附加地或选择性地，上述一个或多个控件可以和遥控器相关联。遥控器可以通过有线和/或无线信号和智能电视100通信。因此可以理解为，遥控器可以通过射频(RF)、红外线(IR)和/或特定的无线通信协议(如蓝牙TM、Wi-Fi等)工作。在某些情况中，可以配置上述物理或电子控件(如编程)，以适合用户的喜好。

可选地，可以使用智能电话、平板电脑、计算机、笔记本电脑、上网本和其他智能设备以控制智能电视100。例如，使用在智能设备上运行的应用程序控制智能电视100。该应用程序通过配置可以在与智能电视100关联的屏幕上，在直观的用户界面(UI)中为用户提供各种智能电视100控制。用户在UI上的选项输入可通过配置，凭借应用程序使用一个或多个与智能设备关联的通信功能，从而控制智能设备100。

智能电视100可配置通过各种输入设备接收输入，包括但绝不限于视频、音频、无线电、光、触觉及其组合。而且，这些输入设备可以通过配置使智能电视100看到和识别用户手势并作出反应。例如，用户可以会话方式和智能电视100讲话。智能电视100就像是智能设备的智能私人助手和音控导航应用程序(如苹果的Siri、安卓的Skyvi、Robin、Iris和其他应用程序)一样接收和理解语音命令。

此外，智能电视100可配置为一个通信设备，它可以通过许多不同方式(包括有线108或无线112方式、蜂窝式网络116)，建立网络连接104和使用电话线路120连接电话公司运营的电话网络。这些连接104使智能电视100能够访问一个或多个通信网络。通信网络包含任何已知的通信介质或通信媒体的集合，可以使用任何类型的协议在端点之间传送信息或信号。通信网络可包含有线和/或无线通信技术。互联网是通信网络132的一个例子，它和许多计算机、计算机网络和全球各地的其他通信设备一同构成了互联网协议(IP)网络，通过许多电话系统和其他方式实现互联。

在某些实例中，智能电视100可配备多种通信工具。多种通信工具可允许智能电视100通过局域网(LAN)124、无线局域网(WLAN)128和其他网络132进行通信。这些网络可以作为冗余连接以确保网络接入。换言之，如果一个连接中断，智能电视100将使用另一个连接路径重新建立和/或维持网络连接104。而且，智能电视100还使用这些网络连接104发送和接收信息，以及电子节目指南(EPG)136互动，接收软件更新140，联系客户服务144(如获取帮助或服务等)和/或访问远程储存的数字媒体库148。此外，这些连接还允许智能电视100打电话、发送和/或接收电子邮件信息、发送和/接收文本消息(如电子邮件和即时消息)，使用互联网搜索引擎进行网上冲浪、通过博客服务发博客，以及连接/与社交媒体网站和/或社交网络服务维护的在线社区(如Facebook、Twitter、LinkedIn、Pinterest、GooglePlus、MySpace等)互动。当这些网络连接104和智能电视100的其他组件(下文将更加详细说明)组合使用时，我们还可以在智能电视100上召开视频电话会议、电子会议和进行其他类型的通信。智能电视100可以使用连接的摄像头、麦克风和其他传感器捕获和储存图像和声音。

附加地或选择性地，智能电视100可以创建和保存智能电视100的关联屏幕上显示的媒体、图像和数据的屏幕截图。

如图1B所示，智能电视100可以和其他电子设备168通过有线108和/或无线112连接进行互动。如本申请所述，智能电视100的组件允许设备100连接到设备168，包括但不限于DVD播放器168a、蓝光播放器168b、便携式数字媒体设备168c、智能电话168d、平板设备168e、个人计算机168f、外置分线盒168g、键盘168h、定位装置168i、打印机168j、游戏控制器和/或游戏手柄168k、卫星碟168l、外置显示设备168m和其他通用串行总线(USB)、局域网(LAN)、蓝牙TM、高清多媒体接口(HDMI)组件设备和/或无线设备。当连接到外置分线盒168g或卫星碟168l时，智能电视100可以访问更多媒体内容。

此外，如下文详述，智能电视100可接收电视台的数字和/或模拟信号广播。它可以作为一个或多个有线电视、互联网电视、互联网协议电视、卫星电视、网页电视和/或智能电视工作。智能电视100还可以配置为用于控制并与其他智能组件互动，如安全系统172、门禁/门控器176、远程视频摄像头180、照明系统184、恒温控制器188、冰箱192和其他装置。

智能电视：

图2说明了智能电视100的组件。如图2所示，智能电视100可由与框架208连接的可移动基底或支架204支撑。框架208包围着显示屏212的边缘，而不遮掩其正面。显示屏212可包含液晶显示屏(LCD)、等离子屏幕、发光二级管(LED)屏幕或其他类型的屏幕。

智能电视100可包含整合式扬声器216和至少一个麦克风220。在一些实例中，框架208的第一个区包含水平手势捕获区224，第二个区包含垂直手势捕获区228。手势捕获区224和228包含能通过识别用户手势来接收输入的区，在某些例子中，用户根本不需要实际触摸智能电视100的屏幕212的表面。但是手势捕获区224和228不包含可以执行显示功能或能力的像素。

在一些实例中，添加一个或多个图像捕获设备232(如摄像头)以捕获静止和/或视频图像。图像捕获设备232可以包含或连接其他元件，如闪光或其他光源236和测距设备240以辅助图像捕获设备的聚焦。此外，智能电视100还可以使用麦克风220、手势捕获区224和228、图像捕获设备232和测距设备240识别各个用户。附加地或选择性地，智能电视100可以学习和记住各个用户的喜好。在某些实例中，学习和记忆(例如识别和调出储存的信息)可能与用户识别相关。

在一些实例中，还可以设置一个红外发送器与接收器244通过遥控设备(此处未显示)或其他红外设备连接智能电视100。附加性地或选择性地，遥控设备可以通过射频、光和/或红外线以外的其他方式发送无线信号。

在一些实例中，音频插座248隐藏在可折或可移动面板的后面。音频插座248含有一个尖头圆形套管(TRS)连接器，例如允许用户使用耳机、头戴式耳机或其他外置音频设备。

在一些实例中，智能电视100还包含数个按钮252。例如，图2显示了智能电视100顶部的按钮252，这些按钮也可以位于其他位置。如图所示，智能电视100包含六个按钮252(从a到f)，可以为特定输入配置。例如，第一个按钮252可以配置为开/关按钮，用于控制整个智能电视100的系统电源。按钮252可以一起或单独配置以控制智能电视100的多个方面。某些非限制性例子包括但不限于整个系统音量、亮度、图像捕获设备、麦克风和视频会议的召开/结束。不同于独立的按钮，两个按钮可以组合成一个波动按钮。这种波动按钮在某些情况中非常有用，如控制音量或亮度等功能。

在某些实例中，可以使用一个或多个按钮252支持不同的用户命令。例如，正常按下的持续时间一般少于1秒，类似于快速输入。中等按下的持续时间一般为1秒或以上但不超过12秒。长按的持续时间一般为12秒或以上。按钮的这种功能一般视智能电视100上激活的应用程序而定。例如在视频会议应用程序中，根据特定的按钮，正常、中等或长按可能意味着结束视频会议、增加或减少音量、提高输入响应速度和开关麦克风静音。取决于特定的按钮，正常、中等或长按还可以控制图像捕获设备232增加或减少缩放、拍照或录像。

硬件功能：

图3说明了依照本申请的实例的智能电视100的一些组件。智能电视100包含一个显示屏304。

可以使用一个或多个显示控制器316控制显示屏304的操作。显示控制器316可以控制显示屏304的操作，包括输入和输出(显示)功能。显示控制器316还可以控制显示屏304的操作并和其他输入互动，如红外线和/或无线电输入信号(例如门禁/门控制器、警报系统组件等)。依照其他一些实例，显示控制器316的功能可能会纳入其他组件中，如处理器364。

处理器364可包含一个执行应用程序设计或指令的通用可编程处理器或控制器依照至少某些实例，处理器364包含多个处理器核心和/或执行多个虚拟处理器。依照其他一些实例，处理器364可能包含多个物理处理器。作为一个具体例子，处理器364可包含特别配置的专用集成电路(ASIC)或其他集成电路、数字信号处理器、控制器、硬接线电子或逻辑电路、可编程逻辑设备或门阵列、专用计算机等。处理器364一般用于运行程序码或指令以执行智能电视100的各种功能。

为支持连接功能或能力，智能电视100可包含一个编码/解码和/或压缩/解压模块366，以接收和管理数字电视信息。编码/解码压缩/解压模块366可以解压和/或解码从公共电视链发出的或在私人电视网中的，通过天线324、I/O模块348、无线连接模块328和/或其他无线通信模块332接收的模拟和/数字信息。电视信息可以发送到显示屏304和/或接收模拟或数字接收信号的附属的扬声器。任何编码/解码和压缩/解压均可基于多种格式执行(如音频、视频和数据)。加密模块324与编码/解码压缩/解压模块366通信，使得用户或供应商接收或发送的所有数据得以保密。

在一些实例中，智能电视100包含额外的或其他无线通信模块332。例如，其他无线通信模块332可包含Wi-Fi,、蓝牙TM、WiMax、红外线或其他无线通信链接。无线连接模块328和其他无线通信模块332可各自与一个共用或专用的天线324和一个共用或专用的I/O模块348相互连接。

在一些实例中，为支持通信功能或能力，智能电视100可包含无线连接模块328。例如，无线连接模块328可包含GSM、CDMA、FDMA和/或模拟蜂窝电话收发器，能够通过蜂窝网络传输语音、多媒体和/或数据。

可以添加输入/输出模块348和关联的端口，以便通过有线网络或链接与其他通信设备、服务器和/或外围设备等支持通信。输入/输出模块348的例子包括以太网端口、通用串行总线(USB)端口、ThunderboltTM或Light Peak接口、电气与电子工程师协会(IEEE)1394端口或其他接口。

可以添加音频输入/输出接口/设备344，以输出模拟音频到互连扬声器或其他设备，以及接收来自连接的麦克风或其他设备的模拟音频输入。例如，音频输入/输出接口/设备344可包含一个关联的放大器和模数转换器。选择性地或附加地，智能电视100可包含一个整合的音频输入/输出设备356和/或连接外置扬声器或麦克风的音频插座。例如，添加一个整合的扬声器和整合麦克风，为近端谈话或扬声器电话操作提供支持。

可以添加端口接口352。端口接口352包含外围或通用端口，为设备100连接到其他设备或组件(如坞站)提供支持，互连后这些设备或组件可能会也可能不会为设备100提供额外的或不同的功能。除支持设备100和其他设备或组件之间交换通信信号外，对接端口136和/或端口接口352还可以供电给设备100或从设备100中输出电源。对接端口352还包含一个智能元件，其包括控制智能电视100和连接的设备或元件之间通信或其他互动的对接模块。对接模块可以和软件应用程序互动，以遥控其他设备或组件(如媒体中心、媒体播放器和计算机系统)。

智能电视100还可包含存储器308，以便处理器364执行应用程序设计或指令，以及用于临时或长期储存程序指令和/或数据。例如，存储器308可包含RAM、DRAM、SDRAM或其他固态存储器。在一些实例中，添加数据存储器312。类似于存储器308，数据存储器312可包含一个或多个固态存储器。在一些实例中，数据存储器312可包含一个硬盘驱动器或其他随机存储器。

例如，硬件按钮358可以用于某些控制操作。可以添加一个或多个图像捕获接口/设备340(如摄像头)以捕获静止和/或视频图像。在一些实例中，图像捕获接口/设备340可以包含一个扫描器、代码阅读器或动作传感器。图像捕获接口/设备340可以包含或连接其他元件，如闪光或其他光源。图像捕获接口/设备340可以和用户ID模块350互动，该模块帮助识别智能电视100用户的身份。

智能电视100还可以包含全球定位系统(GPS)接收器336。根据本公开的一些实例，GPS接收器336可以进一步包含GPS模块，以提供绝对定位信息给智能电视100的其他组件。因此可以理解为，其他卫星定位系统接收器可以代替或和GPS一起使用。

智能电视100的组件可以通过主电源和/或电源控制模块360取电。例如，电源控制模块360包含一个电池、交流到直流变换器、电源控制逻辑和/或互连智能电视100和外置电源的端口。

固件和软件：

图4显示了软件系统组件和模块400的一个实例。软件系统400可能包含一个或多个层次，包括但不限于操作系统内核404、一个或多个库408、一个应用程序框架412和一个或多个应用程序416。一层或多层404-416可以互相通信，以执行智能电视100的功能。

操作系统(OS)内核404包含允许软件和智能电视100关联的硬件互动的主要功能。内核404可以包含一系列软件，用以管理计算机硬件资源并为其他计算机程序或软件代码提供服务。操作系统内核404是操作系统的主要组件，充当应用程序和使用硬件组件完成的数据处理之间的中间人。部分操作系统内核404可包含一个或多个设备驱动器420。设备驱动器420可以是操作系统中的任何一个代码，用以帮助操作或控制连接到或和智能电视关联的设备或硬件。驱动器420可以包含操作视频、音频和/或其他智能电视100的多媒体组件的代码。驱动器的示例包括显示屏、摄像头、Flash、Binder(IPC)、键盘、WiFi和音频驱动器。

库408可以包含软件系统400操作期间访问和执行的代码或其他组件。库408可能包含但不限于一个或多个操作系统运行时间库424、一个电视系统超文本应用程序语言(HAL)库428、和/或数据服务库432。操作系统运行时间库424可能包含操作系统内核404要求的代码和软件系统400运行期间执行的其他操作系统功能。该库可以包含软件系统400运行期间启动的代码。

电视服务超文本应用程序语言428可以包含电视服务要求的代码，由应用程序框架412或应用程序416执行。电视服务HAL库428特定于控制不同智能电视功能的智能电视100操作。此外，电视服务HAL库428还可以由除超文本应用程序语言以外的其他类型的应用程序语言或不同代码类型或代码格式的实例组成。

数据服务库432可以包含一个或多个组件或代码，用以执行实现数据服务功能的组件。数据服务功能可以在应用程序框架412和/或应用程序层416中执行。图6显示了可能包括在内的数据服务功能和组件类型的实例。应用程序框架412可以包含关于提供功能的总体抽象概念，该功能可以通过一个或多个应用程序416选择，以为这些应用程序提供特定的应用程序功能或软件。因此，框架412可包含一项或多项不同的服务，或是可通过应用程序416访问以提供两个或两个以上应用程序上的一般功能的其他应用程序。例如，这种功能包括一个或多个视窗或面板、平面、活动、内容和资源的管理。应用程序框架412可包含但不限于一个或多个电视服务434、电视服务框架440、电视资源444和用户界面组件448。

电视服务框架440可以为不同的电视服务提供额外的抽象概念。电视服务框架440允许和电视功能相关的服务的常规访问和操作。电视服务436是在电视服务框架440中提供的一般服务，电视服务框架440可以通过应用程序层416中的应用程序进行访问。电视资源444提供用于访问电视资源的代码，这些资源包括任何类型的储存内容、视频、音频或其他智能电视100提供的功能。电视资源444、电视服务436和电视服务框架440为执行各种伴随智能电视100的电视功能服务。

一个或多个用户界面组件448可以为智能电视100的显示提供一般组件。用户界面组件448可以作为一般组件通过应用程序框架412提供的各种应用程序访问。可以访问用户界面组件448，为如图5所述的面板和筒仓提供服务。

应用程序层416既包含也可执行和智能电视100相关的应用程序。应用程序层416可能包含但不限于一个或多个直播电视应用程序452、视频点播应用程序456、媒体中心应用程序460、应用程序中心应用程序464和用户界面应用程序468。直播电视应用程序452可以通过不同的信号源提供直播电视。例如，直播电视应用程序452可以使用来自有线电视、无线广播、卫星服务或其他类型的直播电视服务的输入提供电视。然后直播电视应用程序452可在智能电视100的显示屏上显示多媒体演示或直播电视信号的视频和音频演示。

视频点播应用程序456可以提供来自不同储存源的视频。不同于直播电视应用程序452，视频点播456提供来自某些储存来源的视频显示。视频点播源可以和用户或智能电视或某些其他类型的服务关联。例如，视频点播456可以从以云技术储存的iTunes库、从包含已存视频节目的本地硬盘存储器或某些其他来源提供。

媒体中心应用程序460可以提供各种媒体演示所需的应用程序。例如，媒体中心460可以为不同于直播电视或视频点播但用户仍可访问的图像或音频的显示提供服务。媒体中心460可以通过访问不同的来源获得在智能电视100上显示的媒体。

应用程序中心464可以提供、储存和使用应用程序。应用程序可以是一种游戏、生产力应用程序或某些和计算机系统或其他设备普遍相关的但可以在智能电视中运行的其他应用程序。应用程序中心464可从不同来源获得这些应用程序，将它们储存在本地存储器中，然后在智能电视100上为用户执行这些应用程序。

用户界面应用程序468可为与智能电视100关联的特定用户界面提供服务。这些用户界面可以包含图5所述的筒仓和面板。用户界面软件500的一个实例如图5所示。此处的应用程序框架412包含一个或多个代码组件，可帮助控制用户界面事件，同时应用程序层416中的一个或多个应用程序影响着智能电视100的用户界面的使用。应用程序框架412可以包含一个筒仓切换控制器504和/或输入事件发送器508。应用程序框架412中的代码组件可能比图5所示的更多或更少。筒仓切换控制器504包含管理一个或多个筒仓之间的切换的代码和语言。筒仓可以是智能电视上垂直的用户界面功能，包含用户可用信息。切换控制器504可以在用户界面发生事件时管理两个筒仓之间的切换。输入事件发送器508可以接收用户界面的事件信息，这些事件信息来自操作系统，然后发送到输入事件发送器508。这些事件信息可以包含遥控器或电视上的按钮选择或其他类型的用户界面输入。然后，输入事件发送器可以将这些事件信息发送至筒仓管理器532或面板管理器536(视事件类型而定)。筒仓切换控制器504可以和筒仓管理器532互动以影响筒仓的更改。应用程序框架416可以包含用户界面应用程序468和/或筒仓应用程序512。应用程序框架416可包含的控制智能电视100所必须的用户界面应用程序可以比图5所示的更多或更少。用户界面应用程序可以包含筒仓管理器532、面板控制器536和一种或多种面板516至528。筒仓管理器532管理筒仓的显示和/或功能。筒仓管理器532可以接收或发送来自筒仓切换控制器504或输入事件发送器508的信息，以更改显示的筒仓和/或决定筒仓接收的输入类型。

面板管理器536可以在用户界面中显示面板，以管理这些面板之间的切换或影响在面板中接收的用户界面输入。因此，面板管理器536可以和不同用户界面面板通信，如全局面板516、音量面板520、设置面板524和/或通知面板528。面板管理器536可以显示这些类型的面板，具体取决于来自输入事件发送器508的输入。全局面板516可能包含和主屏幕相关的信息或用户的最高层级信息。音量面板520显示的信息和音频音量控件或其他音量设置相关。设置面板524显示的信息和音频或视频设置或智能电视100的其他可设置特性相关。通知面板528可以提供和用户通知相关的信息。这些通知可能和诸如视频点播显示、收藏、目前提供的节目等或其他信息相关。通知的内容和媒体或某些类型的设置或操作或智能电视100相关。面板管理器536可以和筒仓应用程序512的面板控制器552通信。

面板控制器552可控制上述几种类型中的某些面板。因此，面板控制器552可以和顶面板应用程序540、应用程序面板544和/或底面板548通信。这几种面板在智能电视100的用户界面中显示时各不相同。因此，面板控件可基于系统配置或当前使用的显示屏类型而定，将面板516至528设置成一定的显示方向(由顶面板应用程序540、应用程序面板544或底面板应用程序548决定)。

图6是数据服务432与数据管理操作的一个实例。数据管理600可包含和不同类型的数据关联的一个或多个代码组件。例如，数据服务432中可以有数个代码组件，可执行视频点播、电子节目指南或媒体数据并与之相关。数据服务432的组件类型可能比图6所示的更多或更少。每种不同类型的数据都可能包含数据模型604-612。这些数据模型决定着数据服务要储存什么信息以及将如何储存这些信息。因此，数据模型可以管理任何数据，不论它们来自哪里以及它们将如何在智能电视系统中被接收和管理。因此，数据模型604、608和/或612可以提供转化能力或影响数据从一种形式转化成另一种可供智能电视100使用的形式的能力。

各种不同的数据服务(视频点播、电子节目指南、媒体)都有一种数据子服务620、624和/或628，用于和一个或多个内部和/或外部内容提供器616通信。数据子服务620、624和628与内容提供器616通信以获取数据，然后将其储存在数据库632、636和640中。子服务620、624和628可以与内容提供器通信，启动或启用一个或多个源插件644、648和652以与内容提供器通信。对于各个内容提供器616，其源插件644、648和652也有所不同。因此，如果数据有多个内容源，每个数据子服务620、624和628可以决定，然后启用或启动不同的源插件644、648和/或652。此外，内容提供器616还可以为资源仲裁器656和/或缩略图缓存管理器660提供信息。资源仲裁器656可以和数据服务432之外的资源664通信。因此，资源仲裁器656可以和云存储器、网络存储器或资源664中的其他类型的外置存储器通信。然后，信息将通过内容提供器模块616提供给数据子服务620、624、628。类似地，缩略图缓存管理器包含来自数据子服务620、624、628其中之一的缩略图信息，并将信息储存在缩略图数据库666中。而且，缩略图缓存管理器660还可以从缩略图数据库666中提取或检索信息以提供给数据子服务620、624、628其中之一。

图7显示的是示范性内容聚合结构1300。该结构可包含一个用户界面和内容聚合层1304和1308。用户界面层1304可包含一个电视应用程序1312、媒体播放器1316和应用程序1320。电视应用程序1312使观众可以观看通过恰当的传送媒介(如电缆、卫星和/或互联网)接收到的频道。媒体播放器1316可观看通过恰当的传送媒介(如互联网)接收到的其他类型的媒体。应用程序1320包含其他与电视相关(预安装)的应用程序，如内容查看、内容搜索、设备查看和设置算法，还可以和媒体播放器1316协作以给观众提供信息。

内容源层1308作为数据服务包含一个内容源服务1328、内容聚合服务1332和内容展示服务1336。内容源服务1328管理内容源调查器，包括本地和/或网络文件系统、数字网络设备管理器(其通过已知技术，如多路广播通用的即插即用或UPnP发现技术，发现手持式或非手持式设备(例如数字媒体服务器、播放器、渲染器、控制器、打印机、上传器、下载器、网络连接功能和互操作单元)，并对发现的每个设备检索、分析和加密设备描述符，通知新发现设备的内容源服务，以及提供和之前发现的设备有关的信息，如索引)、互联网协议电视或IPTV、数字电视或DTV(包括高清和增强电视)、第三方服务(如上文引用的服务)和应用程序(如安卓应用程序)。

内容源调查器可以追踪内容源，一般配置为二进制。内容源服务1328可启动内容源调查器并维护开放和持久的通信通道。通信包括查询或命令和响应对。内容聚合服务1332管理内容元数据获取器，如视频、音频和/或图像元数据获取器。内容展示服务1336提供内容索引界面，如安卓应用程序界面和数字设备界面。

内容源服务1328可发送送往和接收来自内容聚合服务1332的通信1344。通信包含关于最新和已删除的数字设备和/或内容和搜索查询和结果的通知。内容聚合服务1332可发送送往和接收来自内容展示服务1336的通信1348，包括设备和/或内容查找通知，感兴趣内容的咨询和通知以及搜索查询和结果。

执行搜索时，尤其是用户正在搜索或浏览内容时，内容展示服务1336可接收来自用户界面层1300的用户请求，从而打开插座并将该请求发送至内容聚合服务1332。内容聚合服务1332首先返回来自本地数据库1340的结果。本地数据库1340包含索引或数据模型和已编入索引的元数据。内容源服务1328进一步发出对于所有内容源调查器和其他数据管理系统的搜索并浏览请求。所述结果将被发送至内容聚合服务1332，其更新数据库1340以反映进一步搜索结果，并通过之前打开的插座，将原始内容聚合数据库搜索结果和反映更多内容源服务搜索结果的数据更新结果提供给内容展示服务1336。然后内容展示服务1336将该结果提供给用户界面层1300的一个或多个组件以向观众展示。当搜索阶段结束后(例如搜索阶段被用户或用户的操作终止)，用户界面层1300将断开插座的连接。如图所示，媒体可以从内容聚合服务1332直接提供到媒体播放器1316以向用户显示。

如图8中，视频内容(如电视节目、视频、电视等)在屏幕212的正面显示。视窗1100遮掩在屏幕212的部分，其余部分显示的视频内容，也可以使屏幕212显示视频内容的部分沿着视窗1100的高度变化时向上或向下移动，和/或压缩，还可以的是，窗1100叠加在视频内容上，视窗1100的高度变化不会影响视频内容的显示位置。

视窗1100可包含一项或多项信息，如：与目前显示图像和/或内容相关的面板推荐栏、详细信息(例如标题、日期/时间、音频/视频指示符、评定等级和风格等)、热键栏、浏览请求和/或搜索请求相关的信息输入栏。

在一些实例中，视窗1100包含与内容相关的恰当信息(如名称、持续时间和/或余下的内容浏览时间)、设置信息、电视或系统控制信息、应用程序(激活)图标(如：预安装和/或下载的应用程序)、应用程序中心、媒体中心、网页浏览器、输入源的信息。

如图9是针对内容/筒仓选择器的一个用户界面的直观形象实例。该直观形象1400中包含一个内容源选择器1404。内容源选择器1404包含一个或多个筒仓1408至1424的图标。

内容源选择器1404可包含两个或多个代表不同筒仓的图标1408至1424。例如，图标1408至1420代表不同的内容应用程序筒仓。不同的内容应用程序筒仓可能包含一个直播电视筒仓，由图标1408表示。直播电视筒仓是广播电视信号应用程序的逻辑表示形式，该应用程序可提供电视内容给电视100的用户。视频点播(VOD)筒仓是用图标1412表示。VOD筒仓提供访问可选择和可按需提供给用户的视频或其他类型的媒体的路径。媒体中心筒仓由图标1416表示。媒体中心筒仓包含提供由用户开发或储存的图像和/或电影的应用程序。媒体中心为用户提供了一种使用智能电视100储存其媒体的方式。应用程序筒仓由图标1420表示。应用程序筒仓提供游戏和其他可在电视上访问和使用的用户应用程序等。输入源筒仓1424可以是任何类型通过输入端口或其他电气连接方式与电视100连接的设备或其他储存机制，如：HDMI等其他输入接口，或输入接口集合筒仓。

C/S通信系统

图10是一种示例性的C/S通信系统，包括终端(手机、遥控器、PAD等移动终端，或/和，智能电视、空调、冰箱等PC终端)、网络和服务器，终端与服务器通过接入网络传输数据，接入网络可以是蜂窝网(4G、5G等)、局域网或城域网，在家庭环境中，通过路由器搭建局域网以实现多终端之间互联互通，是提高用户体验的一种有效途径。

终端中存储的本地内容与之间存在一一对应的相互映射关系，本地URL经过域名解析器(例如：路由器或DNS服务器)转换为目标URL，，存储目标网络资源的设备包括其他分布式终端或服务器，并且基于应答机制向发送目标URL地址的终端反馈目标网络地址。

为了提高PC终端与服务器直接的通信效率，在至少两个终端之间互联互通的过程中，移动终端能够作为PC终端的数据传输桥梁，一种方式即为：移动终端中的应用程序通过识别PC终端上显示的二维码在两者之间建立绑定关系，基于该绑定关系从接入网络中接收与PC终端中应用程序相关联的本地内容，也可以基于HTTP协议将从PC终端接收的本地内容上传到服务器；另一种方式为：基于MQTT协议在PC终端中配置代理服务器，利用该代理服务器在PC终端和移动终端之间相互传输本地内容或/网络内容，以使移动终端代替PC终端与服务器之间数据交互，可以在PC终端配置较低的情形下，提高PC终端的数据船速效率。

在上述方式中，移动终端可以从PC终端处接收本地统一资源定位符(为了便于描述，下称本地URL地址)，经过域名解析器(例如：DNS服务器或者路由器等)转换本地URL地址为目标URL地址，在接入网络中的访问路径下请求与目标URL对应的目标网络内容，服务器基于应答机制向移动终端或与其绑定的PC终端反馈目标网络内容。

以分布式部署的多个服务器，可以包括第三方服务器相关联的第一服务器和为用户提供终端服务的第二服务器，终端可以直接通过目标URL地址访问第一服务器，也可以先访问第二服务器，第二服务器与第一服务器之间通信交互，以使得第二服务器接收第一服务器处的网络内容并反馈给终端。

在一些实施例中，不同终端基于同一接入网络互联互通，如：电视及手机接入相同的无线网络；或者，基于不同接入网络建立绑定关系，如：电视接入无线网络且手机接入蜂窝网络。

云服务平台

图11是一种示例性的云服务平台，在终端和服务器通信交互的访问路径中可以包括：在终端中的应用程序、网络优化系统、内容管理系统、云存储系统和第三方服务系统，在终端上运行时，终端通过接收用户针对应用程序时所展示的用户图形界面上界面元素的输入，并响应于该输入沿着访问路径向至少部分系统传输请求包，以及接收与请求包对应的目标网络内容，将目标网络内容显示在界面元素中，便于用户查看，其中，应用程序可以是第三方应用程序或者终端中的预安装程序。

接收并响应于触发第三方应用程序(如微信或淘宝)所输入的指令，通过HTTP协议封装请求包，请求包在接入网络中传输效率的需求，促使网络优化系统不可或缺，尤其是在分布式终端集中请求的情形下，可以降低系统崩溃的几率；在网络优化系统中可以包括CDN(内容分发网络)加速服务器和/或负载均衡服务器等。

CDN加速服务器基于用户应用程序中输入要访问的域名，应用程序向本地DNS请求对该域名解析，本地DNS将请求转发到主DNS，主DNS根据导流分发策略确定出适合于终端的CDN服务器，并将解析的IP地址发送给终端，终端以该IP地址向与其对应的CND节点请求对应的网络内容；负载均衡服务器遵循预置的分流策略对请求分流，在分布式业务服务器上分摊执行业务数据，提供扩展服务器带宽、吞吐量/数据运算能力，增强网络灵活性和可用性。

为用户提供丰富化服务内容的内容管理系统，可以包括应用管理系统、会员管理系统、支付系统等，应用管理系统存储与第三方应用程序相关联的应用内容，如：包流量值、包名、服务商信息等，会员管理系统可以存储用于开通/管理与虚拟商品相关联服务的会员内容，该会员内容可以包括会员等级、账户、用户增长值等，支付系统可以为用户提供转账服务、充值服务、支付渠道和/或支付帐号管理服务及其对应的支付产品。

云存储系统包括非易失性的云数据库和易失性的云缓存，可以通过云缓存直接读取或者从云数据库中查询内容管理系统中预存的网络内容，云缓存中存储的数据结构如KV结构，以集群方式或主从方式部署可以兼容Redis协议，克服数据丢失和服务中断，也可以在云缓存出现异常时重新创建，从云数据库中重新读取。

以下对本公开的音视频通讯方法的应用场景做出说明。

在终端(如电视、手机等)内装载有音视频处理引擎，音视频处理引擎包括终端的音视频采集、编解码、传输、显示播放等软件代码。多个终端之间可以通过信令服务器进行信号交互，其中信令服务器用于在多个终端之间传输通信所需的信令，信令通常需要在通信网络的不同环节(基站、移动台和移动控制交换中心等)之间传输，各环节进行分析处理并通过交互作用而形成一系列的操作和控制，其作用是保证终端之间的信息的能够有效且可靠的传输。多个终端之间可以通过媒体服务器进行音视频资源的传输。

不同类型的音视频处理引擎之间是无法进行通讯的，比如音视频处理引擎(以下简称引擎)E1与引擎E2，它们之间是不能进行实时音视频通讯的。如果终端D1使用了引擎E1，终端D2使用引擎E2，那么会导致终端D1与终端D2是无法进行实时音视频通讯。

这种引擎不兼容的情况经常会发生，例如首先在终端上使用引擎E1，但随着业务不断的扩展、产品的升级，引擎E1已无法满足要求，因此开发商开发出功能更完备、性能更优的引擎E2。

然而引擎E1已经在大量的终端上使用，而且短时间内也无法把所有的终端的软件都升级到引擎E2，就会存在一段时间(甚至长时间，因为有些终端由于某种原因，永远无法升级到引擎E2)，有些终端使用引擎E1,有些终端使用引擎E2，如果保障每个终端都可以与其它终端进行实时音视频通话，要考虑E1和E2的兼容处理。

做了兼容处理后的音视频处理引擎里集成了引擎E1与E2，因此该音视频处理引擎里能够同时兼容引擎E1与引擎E2。如果终端D1升级了该音视频处理引擎，那么它具备与没有升级软件的终端D2(只具有引擎E1，使用引擎E1进行通讯)，与升了级的终端D3(具有引擎E1与引擎E2，优先使用引擎E2进行通讯)，这样就保证了进行了软件升级与没有进行软件升级的终端都可以通讯。

然而，这种对不同类型的音视频处理引擎的兼容处理，会导致性能优化受到限制。比如升了级的终端D1，其具有引擎E1与引擎E2，在邀请接听终端进行音视频通话时，因为无法知晓对方有没有升级以及引擎类型，从而不知道该用哪个引擎进行通讯，也就无法在接听终端接起音视频邀请之前这个响铃阶段进行引擎的初始化、并推送音视频流到媒体服务器上，而只有等到对方接听后，对方反馈自身的引擎类型才知道该使用哪一个引擎与对方进行通讯。特别是如果被叫的账号在多个接听终端上均有登录，因此在邀请方终端发出音视频邀请后，这些接听终端都会响铃，而这些接听终端有些是升级了音视频处理引擎，一些没有升级，邀请方终端无法知晓最终接起音视频邀请的接听终端时哪一个，因此这样造成邀请方终端会更加困惑于应使用哪种引擎通讯。

本公开提出一种音视频通讯方法，目的是为了在解决或减少上述应用场景中，音视频通话中终端上首帧显示速度变慢发生的情况。需要说明的是，在下述实施例中，涉及到邀请方终端、接听终端、信令服务器为主体所执行的一些步骤，为了更加便于理解本方案的发明构思，特将三者的实施例合并在一起进行阐述。

请参阅图11和图12，本公开所提出音视频通讯方法中，以下步骤由音视频通讯的邀请方终端执行，方法包括：

S100，发出音视频邀请至受邀账号，受邀账号绑定多个接听终端；

受邀账号一般为虚拟账号，其可以在多个不同类型的接听终端上同时登录。每个接听终端至少具有一个引擎的类型(当某个接听终端做了兼容处理后，可能会具有两种或以上引擎类型供选择使用)。

在本实施例中，邀请方终端发出的音视频邀请可以直接发送给多个接听终端，也可以通过信令服务器发送。通过信令服务发送音视频邀请的速度更快，且信号传输更稳定。请参阅图13，具体的，以下方法由信令服务器执行。

S200，接收到邀请方终端向受邀账号发出的音视频邀请，推送音视频邀请至与该受邀账号绑定的多个接听终端。

信令服务器在获取到邀请方终端向某一账号发出了音视频邀请后，会向与该账号绑定或处于登陆状态的接听终端发送音视频邀请。

在本实施例中，信令服务器还会将邀请方终端音视频处理引擎的升级信息发送至所有的接听终端。当邀请方终端音视频处理引擎未进行升级时，以引擎E1进行工作，此时接听终端中若有已经升级的接听终端(即可以以引擎E1和引擎E2工作)，则此时接听终端会立刻调整自己的引擎类型，以E1工作，以准备与邀请方终端进行通讯；当邀请方终端音视频处理引擎已进行升级时，可以以引擎E1和引擎E2工作，但是E2为高级版本，则默认以较高版本的引擎E2工作；此时接听终端中若有已经升级的接听终端(即可以以引擎E1和引擎E2工作)，则此时接听终端会预先调整自己的引擎类型，以引擎E2工作，以准备与邀请方终端进行通讯.。

在此举例说明，邀请方终端为手机D1，该手机D1为升级过后的音视频处理引擎，包括了引擎E1和引擎E2。受邀方终端有两个，分别为手机D2和电视D3，该手机D2具有引擎E1，电视D3具有升级过后的音视频处理引擎，包括了引擎E1和引擎E2。在邀请方终端手机D1发出音视频邀请后，信令服务器会将邀请方终端手机的音视频处理引擎的升级情况发送至所有的接听终端，此时手机端D2只能仍旧保持引擎E1工作，电视端D3切换至引擎E2工作。

请参阅图14，对应于步骤S100和S200，由接听终端执行以下步骤；

S300，接收到所述邀请方终端发送的音视频邀请；

S310，发送所述接听终端本地的音视频处理引擎类型至信令服务器，并推送该接听终端要通信的音视频内容至媒体服务器。

接听终端接收到由信令服务器转发或直接由邀请方终端推送的音视频邀请后，会发出响铃、振动、声光等形式的提醒标识，以通知用户接听。几乎同时会将自身的音视频处理引擎类型发送至信令服务器或直接发送给接听终端。并且该接听终端会启动音视频处理引擎，以开始预先进行音视频采集的工作。例如打开摄像头进行图像采集，在将所采集的图像进行编码，上传至媒体服务器；或打开麦克风，以开始对周围的声音进行录音，并将所收集的录音进行编码后上传至媒体服务器。

请参阅图11，例如，接听终端手机D2和接听终端电视D3在接收到邀请方终端手机D1发出的视频邀请后，手机D2和电视D3会开始响铃，两者在响铃后或响铃时分别会将自己的音视频处理引擎类型发送给信令服务器。同时手机D2和电视D3会启动摄像头和麦克风，以开始进行图像采集和声音采集，并将采集到的音视频内容进行编码，然后上传至媒体服务器。

在本实施例中，不同的接听终端分别对应传输至不同的媒体服务器，当然也可以是均传输至同一个媒体服务器。可选的，同时手机D2和电视D3在启动摄像头和麦克风，以分别开始进行图像采集和声音采集，并将采集到的音视频内容进行编码后，然后分别独立上传至两个媒体服务器。

请参阅图12。S110，获取多个接听终端中预测接听终端的音视频处理引擎类型；

预测接听终端是在该音视频邀请被某一接听终端接起之前，由邀请方终端或信令服务器所预测的最终可能会被用户接起该音视频邀请所在的接听终端。实际上，预测接听终端是使用与最可能接起的接听终端同样的引擎类型的所有接听终端，所以预测接听终端可以是一个或多个。

在一实施例中，预测接听终端是由在邀请方终端和多个接听终端之间通信的信令服务器通过以下方式预测的：

接收多个接听终端接收到音视频邀请后反馈的音视频处理引擎类型；

将最先接收到的音视频处理引擎类型来自的接听终端作为预测接听终端。

请参阅图13，相对应于信令服务器执行的步骤：

S210，根据多个接听终端的反馈，确定多个接听终端中的一个预测接听终端；

其中，根据多个接听终端的反馈，确定多个接听终端中的一个预测接听终端包括：

接收多个接听终端接收到音视频邀请后反馈的音视频处理引擎类型；

将最先接收到的音视频处理引擎类型来自的接听终端作为预测接听终端。

每个接听终端在接收到信令服务器推送的音视频邀请后，会发出响铃、振动、声光等形式的提醒标识，以通知用户接听。于此同时，接听终端会发送自身的音频处理引擎类型至信令服务器，由于每个终端的类型、位置、网络信号强度的不同，传输至信令服务器的时间会有差距，因此信令服务器将最先接收到的音视频处理引擎类型来自的接听终端作为预测接听终端。由于用户可能会在最先响铃(当然也可以是震动、声光等形式的提醒信号，以下均以响铃为例说明)接听终端进行接听音视频邀请，因此本实施例能够通过预判用户的行为趋势，以确定最为可能被用户所接听的预测接听终端，提高了确定预测接听终端的准确性。

在另一实施例中，信令服务器接收多个接听终端接收到音视频邀请后反馈的接听终端加速度；

将反馈的接听终端加速度最大的接听终端作为预测接听终端。

相对应于信令服务器执行的步骤：

根据多个接听终端的反馈，确定多个接听终端中的一个预测接听终端包括：

接收多个接听终端接收到音视频邀请后反馈的接听终端加速度；

将反馈的接听终端加速度最大的接听终端作为预测接听终端。

相应于接听终端执行的步骤：

接听终端内具有加速度传感器；发送接听终端本地的音视频处理引擎类型至信令服务器包括：

上传加速度传感器检测的运动加速度，以及接听终端本地的音视频处理引擎类型；其中，信令服务器根据接听终端的加速度在多个接听终端中确定一个预测接听终端。

在本实施例中，类似手机、平板电脑等便携式接听终端通常会被用户随身携带，或正在使用。因此当用户运动时或使用该接听终端时，会使得接听终端产生一加速度。当某一接听终端被用户随身携带或在手中使用的期间接收到音视频邀请，则有非常大的概率被用户接听。因此本实施例通过预判用户的对接听终端的使用习惯，以确定最为可能被用户所接听的预测接听终端，提高了确定预测接听终端的准确性。

具体的，本实施例中，信令服务器可以在多个接听终端中选择具有最大加速度的接听终端作为预测接听终端。当所有接听终端的加速度均为0时，可以通过上一实施例中，选择最先接收到的加速度所对应的接听终端作为预测接听终端。

在此需要说明的是，对应于上述接听终端执行的步骤中，接听终端在接收到音视频邀请后，可以仅上传自身的加速度信号。待信令服务器确认了预测接听终端后，再通知该预测接听终端上传自身所使用的音视频引擎类型。上述接听终端同时上传加速度信号和音视频引擎类型，可以使得信令服务器在根据加速度确定了预测接听终端后，可以直接提取该预测接听终端所对应的音视频引擎类型发送给邀请方终端，从而提高了信息处理效率。

在又一实施例中，信令服务器接收多个接听终端接收到音视频邀请后反馈的接起音视频邀请的次数；

将反馈的接起音视频邀请的次数最大的接听终端作为预测接听终端。

相对应于信令服务器执行的步骤：

根据多个接听终端的反馈，确定多个接听终端中的一个预测接听终端包括：

接收多个接听终端接收到音视频邀请后反馈的接起音视频邀请的次数；

将反馈的接起音视频邀请的次数最大的接听终端作为预测接听终端。

相应于接听终端执行的步骤：

接听终端内保存有接起音视频邀请的次数；发送接听终端本地的音视频处理引擎类型至信令服务器包括：

上传保存的接起音视频邀请的次数，以及接听终端本地的音视频处理引擎类型；其中，信令服务器根据接起音视频邀请的次数在多个接听终端中确定一个预测接听终端；

并且当用户最终选择了在该接听终端上接听邀请方终端发送的音视频邀请后，则更新所保存的接起音视频邀请的次数，具体的，在先前音视频邀请的次数的基础上进行加1。

在本实施例中，根据用户的在接听音视频邀请的习惯，以进行预测接听终端的确定。例如用户可能因为电视的显示面更大而更喜欢在电视上接听音视频邀请，因此每次当多个接听终端均响铃时，用户会特地选择在电视上进行接听。因此本实施例中，通过在接听终端上保存接起音视频邀请的次数，以探知用户的接听习惯，从而预测用户在接听音视频邀请时的行为趋势，以确定最为可能被用户所接听的预测接听终端，提高了确定预测接听终端的准确性。

具体的，本实施例中，信令服务器可以在多个接听终端中选择具有最多的接起音视频邀请的次数的接听终端作为预测接听终端。当有两个或两个以上的接听终端具有等量的最多音视频邀请的次数时，可以通过之前一实施例中，选择最先接收到的音视频邀请的次数所对应的接听终端作为预测接听终端。

在此需要说明的是，在以上实施例中，均可以由邀请方终端直接与多个接听终端进行通讯，并由邀请方终端来选择预测接听终端。

请参阅图11，再次回到邀请方终端所执行的步骤：

步骤S120，在邀请方终端本地启动与预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至预测接听终端，并接收预测接听终端所发送的要通信的音视频内容。

请参阅图12，对应于信令服务器所执行的步骤：

步骤S220，将该预测接听终端的引擎类型发送至邀请方终端。

在本实施例中，当信令服务器确认了预测接听终端后，会将预测接听终端的引擎类型发送至邀请方终端，在邀请方终端本地启动与预测接听终端的音视频处理引擎相同类型的音视频处理引擎。需要注意的是，此时各个接听终端还处于响铃阶段，用户还未在任何一个接听终端上接听音视频邀请。

请参阅图13，对应于接听终端所执行的步骤:

步骤S320，当该接听终端本地具有与所述邀请方终端的引擎类型相同的音视频处理引擎类型时，接收所述邀请方终端发送的要通信的音视频内容；邀请方终端初始化引擎完成后，会将要通信的音视频内容发送至预测接听终端。在此邀请方终端可以直接发送通信的音视频内容至预测接听终端。在一可选的实施例中，邀请方终端将要通信的音视频内容发送至媒体服务器，媒体服务器在接收到该音视频内容后，会下发至具有与所述邀请方终端的引擎类型相同的音视频处理引擎类型的接听终端。并且媒体服务器也会将预测接听终端所发送的要通信的音视频内容下发到邀请方终端。

具体的，在邀请方终端本地启动与预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至预测接听终端，并接收预测接听终端所发送的要通信的音视频内容的步骤包括：

在邀请方终端本地启动与预测接听终端的音视频处理引擎类型相同的音视频处理引擎；

推送邀请方终端要通信的音视频内容至媒体服务器，并通过媒体服务器转发至预测接听终端；从媒体服务器接收预测接听终端发送的要通信的音视频内容。

请参阅图11，例如当预测接听终端为电视D3，其使用的音视频引擎为引擎E1，此时邀请方终端D1也会相应启动引擎E1。并且基于引擎E1推送邀请方终端要通信的音视频内容至媒体服务器，而接听终端电视D3、手机D2在接收到音视频邀请的时候，就已经开始上传要通信的音视频内容至媒体服务器，因此媒体服务器会将作为预测接听终端的电视D3所发送的通信的音视频内容下发到邀请方终端。

请参阅图11，在上述实施例已说明，不同的接听终端可以将自身所要通信的音视频内容上传分别上传至不同的媒体服务器，例如电视D3将其所要通信的音视频内容上传至媒体服务器S1、电视D3将其所要通信的音视频内容上传至媒体服务器S2。当信令服务器确认预测接听终端为电视D3后，邀请方终端会将其所要通信的音视频内容上传至媒体服务器S1，此时媒体服务器S1认为邀请方终端D1，接听终端电视D3已经加入了同一个虚拟房间，就会把任何一方的所要通信的音视频内容转发给另外一方。邀请方终端D1，接听终端电视D3收到对方的音视频内容后，均会启动解码程序，对音视频内容进行解码。

具体的，推送邀请方终端要通信的音视频内容至媒体服务器，并通过媒体服务器转发至预测接听终端；从媒体服务器接收预测接听终端发送的要通信的音视频内容的步骤包括：

推送邀请方终端要通信的音视频内容到与预测接听终端的音视频处理引擎类型对应的媒体服务器；并从该媒体服务器上接收预测接听终端发送的要通信的音视频内容。

基于以上实施例的内容可以看出，要邀请方终端发出音视频邀请，且用户未在任一接听终端上接起该音视频邀请之前，邀请方终端和预测接听终端之间已经完成了音视频内容的交换。因此本实施例通过预测接听终端的设置，以使邀请方终端可以根据预测接听终端的引擎设定一个先行引擎，从而实现与预测接听终端互换音视频内容的目的，为用户最终在该预测接听终端上接起该音视频邀请完成了预先的信息处理、交换工作，提高了通讯效率。

请参阅图14，当用户从多个接听终端中的某一个接起邀请方终端发送的音视频邀请后，由接听终端所执行的步骤：

步骤S330，响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器；当该接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型相同时，在该接听终端本地立即播放所述邀请方终端发送的要通信的音视频内容。

请参阅图13，相应于信令服务器所执行的步骤：

S230，在音视频邀请被多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

S240，将该接起的接听终端的音视频处理引擎类型发送至邀请方终端。

请参阅图12，相应于邀请方终端所执行的步骤：

S140，当该接起的接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型一致时，在邀请方终端本地立即播放接起的接听终端所发送的要通信的音视频内容。

在本实施例中，当用户在某个接听终端上接起了音视频邀请后，该接起的接听终端会发送自身的音视频处理引擎类型至信令服务器，信令服务器会将该接起的接听终端的音视频处理引擎类型发送给邀请方终端，邀请方终端在比对了当前的使用的音视频引擎类型和接起的接听终端的音视频处理引擎类型后，会有两种情况：相同和不相同。相同代表用户在预测接听终端上或在与预测接听终端引擎类型相同的接听终端上接听了音视频邀请，不相同代表用户在与预测接听终端引擎类型不同的接听终端上接听音视频邀请。

例如，当最终用户是在预测接听终端上接听了音视频邀请，在用户接起该音视频邀请的同时，由于邀请方终端所发送来的音视频内容已经在该预测接听终端上了，并预测接听终端已经对邀请方终端所发送来的音视频内容完成了解码，因此该预测接听终端可以直接设置视频窗口，显示邀请方终端传输过来的视频内容，同时打开扬声器，播放邀请方终端传输过来的音频内容。本实施例实现了在接起音视频邀请的瞬间，就能够立刻播放对方传输过来的音视频内容，提高了首帧显示速度，提高了用户体验。

请参阅图12。但是最终用户不是在预测接听终端上接听了音视频邀请时，且该接起的接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型不一致时，以下由邀请方终端执行的步骤：

S141，将邀请方终端本地启动的音视频处理引擎切换为与该接起的接听终端的音视频处理引擎类型相同的引擎，以推送邀请方终端要通信的音视频内容到接起的接听终端；并接收接起的接听终端所发送的要通信的音视频内容；

在邀请方终端本地播放接起的接听终端所发送的要通信的音视频内容。

请参阅图14，同时在接听终端(显然该接听终端并非为预测接听终端)执行的步骤：

当该接听终端的音视频处理引擎类型与预测的接听终端的音视频处理引擎类型不相同时，待所述邀请方终端切换音视频引擎类型后，接收所述邀请方终端要通信的音视频内容；

在该接听终端本地播放所述邀请方发送的要通信的音视频内容。

请参阅图10，例如，预测接听终端为电视D3，其音视频引起为引擎E2，而最终接起的接听终端为手机D2，具有引擎E1，由于邀请方终端D1使用的引擎与手机D2不一致，邀请方终端D1需要临时切换到引擎E1：释放引擎E2使用的资源、初始化引擎E1、推送音视频内容到媒体服务器，手机D2接收邀请方终端D1的音视频内容，同时邀请方终端D1接收手机D2所传输的音视频数据，最终邀请方终端D1、接起的接听终端手机D2开始在本地播放对方所发送的音视频内容。

同样的，如果接听终端手机D2为预测接听终端，而接起的接听终端为电视D3，邀请方终端在电视D3接听之前是使用引擎E1,D3接听之后，邀请方终端D1也需要临时切换到引擎E2上：释放引擎E1使用的资源、初始化引擎E2、推送音视频内容到媒体服务器，电视D3接收邀请方终端D1的音视频内容，同时邀请方终端D1接收电视D3所传输的音视频数据，最终邀请方终端D1、接起的接听终端电视D3开始在本地播放对方所发送的音视频内容。

本实施例通过预测接听终端的设置，以使邀请方终端可以根据预测接听终端的引擎设定一个先行引擎，从而实现与预测接听终端互换音视频内容的目的，为用户最终在该预测接听终端上接起该音视频邀请完成了预先的音视频信息处理以及交换的工作，提高了通讯效率，使得音视频通讯的邀请方以及接起的接听终端双方播放对方所传输的音视频内容的首帧时间得到了有效的缩短，特别是对于接起的接听终端，用户在接起音视频邀请后，几乎无需等待即可以从接起的终端上看到邀请方终端所传输来的音视频内容，由此大大提高了用户体验。

下面进一步描述本公开的装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

首先本公开提出一种终端，该终端可以是显示装置或手机。其中，终端可以执行邀请方终端的步骤和/或接听终端的步骤。本实施例中，该终端能够作为邀请方终端也能够作为接听终端。具体的，以邀请方终端来说，终端包括：

推收模块，用于发出音视频邀请至受邀账号，受邀账号绑定多个接听终端；

获取模块，用于获取多个接听终端中预测接听终端的音视频处理引擎类型；

引擎设置模块，用于在邀请方终端本地启动与预测接听终端的音视频处理引擎相同类型的音视频处理引擎；推收模块还用于推送邀请方终端要通信的音视频内容至预测接听终端，并接收预测接听终端所发送的要通信的音视频内容；

获取模块还用于在音视频邀请被多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

比对模块，用于接起的接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型是否一致。可以理解的是，比对模块可以根据实际情况比对两种音视频处理引擎类型是否相同。

播放模块，用于当该接起的接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型一致时，在邀请方终端本地播放接起的预测接听终端所发送的要通信的音视频内容。

进一步的，以接听终端来说，终端包括：

推收模块，用于接收所述邀请方终端发送的音视频邀请；

推收模块还用于发送所述接听终端本地的音视频处理引擎类型至信令服务器，并推送该接听终端要通信的音视频内容至媒体服务器；

比对模块，用于比对该接听终端本地具有与所述邀请方终端的引擎类型是否相同；

推收模块用于当该接听终端本地具有与所述邀请方终端的引擎类型相同的音视频处理引擎类型时，接收所述邀请方终端发送的要通信的音视频内容；

推收模块还用于响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器；

播放模块用于当该接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型相同时，在该接听终端本地播放所述邀请方终端发送的要通信的音视频内容。

本公开还提出一种信令服务器，包括：

收发模块，用于接收邀请方终端向受邀账号发出的音视频邀请，推送音视频邀请至与该受邀账号绑定的多个接听终端；

预测接听终端预测模块，用于根据多个接听终端的反馈，确定多个接听终端中的一个预测接听终端；

收发模块还用于将该预测接听终端的引擎类型发送至邀请方终端；

收发模块还用于在音视频邀请被多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

收发模块还用于将该接起的接听终端的音视频处理引擎类型发送至邀请方终端。

需要注意的是，上述功能模块并非一定是功能实体，也不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本公开还提出一种计算机可读存储介质20的示意图。计算机可读存储介质可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本公开中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该计算机可读介质实现上述实施例中的音视频通讯方法。

虽然已参照几个典型实施方式描述了本公开，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本公开能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施方式不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (20)

1.一种音视频通讯方法，其特征在于，所述方法由音视频通讯的邀请方终端执行，所述方法包括：

发出音视频邀请至受邀账号，所述受邀账号绑定多个接听终端；

获取所述多个接听终端中预测接听终端的音视频处理引擎类型；

在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至所述预测接听终端，并接收所述预测接听终端所发送的要通信的音视频内容；

在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

当该接起的接听终端的音视频处理引擎类型与所述预测接听终端的音视频处理引擎类型一致时，在所述邀请方终端本地播放所述接起的接听终端所发送的要通信的音视频内容。

2.根据权利要求1所述的方法，其特征在于，所述在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎相同类型的音视频处理引擎，以推送邀请方终端要通信的音视频内容至所述预测接听终端，并接收所述预测接听终端所发送的要通信的音视频内容的步骤包括：

在所述邀请方终端本地启动与所述预测接听终端的音视频处理引擎类型相同的音视频处理引擎；

推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器将该音视频内容下发至所述预测接听终端，并从所述媒体服务器接收所述预测接听终端发送的要通信的音视频内容。

3.根据权利要求2所述的方法，其特征在于，所述推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器转发至所述预测接听终端，并从所述媒体服务器接收所述预测接听终端发送的要通信的音视频内容的步骤包括：

推送所述邀请方终端要通信的音视频内容到与预测接听终端的音视频处理引擎类型对应的媒体服务器；并从该媒体服务器上接收所述预测接听终端发送的要通信的音视频内容。

4.根据权利要求1至3任意一项所述的方法，其特征在于，在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型之后，所述方法还包括：

当该接起的接听终端的音视频处理引擎类型与所述预测接听终端的音视频处理引擎类型不一致时，将所述邀请方终端本地启动的音视频处理引擎切换为与该接起的接听终端的音视频处理引擎类型相同的引擎，以推送邀请方终端要通信的音视频内容到接起的接听终端；并接收所述接起的接听终端所发送的要通信的音视频内容；

在所述邀请方终端本地播放所述接起的接听终端所发送的要通信的音视频内容。

5.根据权利要求4所述的方法，其特征在于，所述将所述邀请方终端本地启动的音视频处理引擎切换为与该接起的接听终端的音视频处理引擎类型相同的引擎，以推送邀请方终端要通信的音视频内容到接起的接听终端；并接收所述接起的接听终端所发送的要通信的音视频内容的步骤包括：

在所述邀请方终端本地启动与所述接起的接听终端的音视频处理引擎类型相同类型的音视频处理引擎；

推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器转发至所述接起的接听终端；从所述媒体服务器接收所述接起的接听终端发送的要通信的音视频内容。

6.根据权利要求5所述的方法，其特征在于，所述推送邀请方终端要通信的音视频内容至媒体服务器，并通过所述媒体服务器转发至所述接起的接听终端；从所述媒体服务器接收所述接起的接听终端发送的要通信的音视频内容包括：

推送邀请方终端要通信的音视频内容到与该接起的接听终端的音视频处理引擎类型对应的媒体服务器；并从该媒体服务器接收所述接起的接听终端发送的要通信的音视频内容。

7.根据权利要求1所述的方法，其特征在于，所述预测接听终端是由在所述邀请方终端和所述多个接听终端之间通信的信令服务器通过以下方式预测的：

接收所述多个接听终端接收到所述音视频邀请后反馈的音视频处理引擎类型；

将最先接收到的音视频处理引擎类型来自的接听终端作为所述预测接听终端。

8.根据权利要求1所述的方法，其特征在于，所述预测接听终端是由在所述邀请方终端和所述多个接听终端之间通信的信令服务器通过以下方式预测的：

接收所述多个接听终端接收到所述音视频邀请后反馈的接听终端加速度；

将反馈的接听终端加速度最大的接听终端作为所述预测接听终端。

9.根据权利要求1所述的方法，其特征在于，所述预测接听终端是由在所述邀请方终端和所述多个接听终端之间通信的信令服务器通过以下方式预测的：

接收所述多个接听终端接收到所述音视频邀请后反馈的接起音视频邀请的次数；

将反馈的接起音视频邀请的次数最大的接听终端作为所述预测接听终端。

10.一种终端音视频通讯方法，其特征在于，所述方法由在所述邀请方终端和所述多个接听终端之间通信的信令服务器执行；所述方法包括：

接收到邀请方终端向受邀账号发出的音视频邀请，推送音视频邀请至与该受邀账号绑定的多个接听终端；

根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端；

将该预测接听终端的引擎类型发送至所述邀请方终端；

在所述音视频邀请被所述多个接听终端中的一个接听终端接起后，获取该接起的接听终端的音视频处理引擎类型；

将该接起的接听终端的音视频处理引擎类型发送至所述邀请方终端。

11.根据权利要求10所述的方法，其特征在于，所述根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端包括：

接收所述多个接听终端接收到所述音视频邀请后反馈的音视频处理引擎类型；

将最先接收到的音视频处理引擎类型来自的接听终端作为所述预测接听终端。

12.根据权利要求10所述的方法，其特征在于，所述根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端包括：

接收所述多个接听终端接收到所述音视频邀请后反馈的接听终端加速度；

将反馈的接听终端加速度最大的接听终端作为所述预测接听终端。

13.根据权利要求10所述的方法，其特征在于，所述根据多个接听终端的反馈，确定所述多个接听终端中的一个预测接听终端包括：

接收所述多个接听终端接收到所述音视频邀请后反馈的接起音视频邀请的次数；

将反馈的接起音视频邀请的次数最大的接听终端作为所述预测接听终端。

14.一种音视频通讯方法，其特征在于，所述方法由接听终端执行；邀请方终端和所述接听终端之间具有用于通信的信令服务器；所述方法包括：

接收到所述邀请方终端发送的音视频邀请；

发送所述接听终端本地的音视频处理引擎类型至信令服务器，并推送该接听终端要通信的音视频内容至媒体服务器；

当该接听终端本地具有与所述邀请方终端的引擎类型相同的音视频处理引擎类型时，接收所述邀请方终端发送的要通信的音视频内容；

响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器；

当该接听终端的音视频处理引擎类型与预测接听终端的音视频处理引擎类型相同时，在该接听终端本地播放所述邀请方终端发送的要通信的音视频内容。

15.根据权利要求14所述的方法，其特征在于，所述响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器之后还包括：

当该接听终端的音视频处理引擎类型与预测的接听终端的音视频处理引擎类型不相同时，待所述邀请方终端切换音视频引擎类型后，接收所述邀请方终端要通信的音视频内容；

在该接听终端本地播放所述邀请方发送的要通信的音视频内容。

16.根据权利要求14所述的方法，其特征在于，所述接听终端内具有加速度传感器；所述发送所述接听终端本地的音视频处理引擎类型至信令服务器包括：

上传所述加速度传感器检测的运动加速度，以及接听终端本地的音视频处理引擎类型；其中，所述信令服务器根据所述接听终端的加速度在多个所述接听终端中确定一个所述预测接听终端。

17.根据权利要求14所述的方法，其特征在于，所述接听终端内保存有接起音视频邀请的次数；所述发送所述接听终端本地的音视频处理引擎类型至信令服务器包括：

上传保存的接起音视频邀请的次数，以及所述接听终端本地的音视频处理引擎类型；其中，所述信令服务器根据所述接起音视频邀请的次数在多个所述接听终端中确定一个预测接听终端；

所述响应于用户在本地接起所述音视频邀请，发送接听终端本地的音视频处理引擎类型至信令服务器，并在本地播放所述邀请方终端所发送的要通信的音视频内容的步骤之后还包括：

更新所保存的接起音视频邀请的次数。

18.一种终端，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的音视频通讯程序，所述处理器执行所述音视频通讯程序时实现如权利要求1-9中任意一项所述的音视频通讯方法，或实现如权利要求14-17中任意一项所述的音视频通讯方法。

19.一种信令服务器，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的音视频通讯程序，所述处理器执行所述音视频通讯程序时实现如权利要求10-13中任意一项所述的音视频通讯方法。

20.一种计算机存储介质，其特征在于，其存储有计算机程序代码，当其被计算机的处理单元执行时，实现如权利要求1-9中任意一项所述的音视频通讯方法，或实现如权利要求10-13中任意一项所述的音视频通讯方法，或如14-17中任意一项所述的音视频通讯方法。