CN105407369A - 一种基于Web应用的终端通信方法与装置 - Google Patents

Abstract

本发明公开了一种基于Web应用的终端音视频数据通信方法和装置，方法包括接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。解决了现有技术中在现有的智能设备中，无法同时兼顾一方面可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的功能。

Description

一种基于Web应用的终端通信方法与装置

技术领域

本发明涉及通信技术领域，尤其涉及一种基于Web应用的终端通信方法与装置。

背景技术

随着移动互联网行业的迅猛发展，智能电视，手机等智能终端成为当前行业的潮流趋势，越来越多的功能也被植入到此类智能终端中，像视频通话、IE浏览、多屏互动等，它们在给用户带来方便的同时也提升了用户的体验。

对于目前的手机和平板电脑（PAD）等小型终端设备，摄像头和麦克风都已经成为标准配置，且手机和PAD等小型终端设备的摄像头和麦克风在日常生活中使用非常方便，用户可以随时随地的通过互联网与其他终端的用户交互多媒体数据，但是由于手机和PAD等小型终端设备的屏幕尺寸限制，相对来说都比较小，如果把小型智能终端的摄像头获取的实时视频流信息应用在互联网的视频通讯中（比如视频电话会议中），会由于显示图像小造成显示图像不清楚，观看效果不佳的缺点。而在现有终端中，智能电视等大型智能设备是具有大屏幕终端设备能力的载体，在电视终端中播放的视频信息，可以更清晰更好的显示视频信息的内容，满足多个人共同观看视频流信息的需求。但是，现在的电视平台，一般只配备有比较基础的联网功能，很少会配置摄像头和麦克风，无法获取实时音视频流的信息，并且有不方便移动的缺点，也不具备和网络终端进行视频通讯的功能，给用户带来了一系列体验上的局限性。

综上，在现有的智能设备中，无法同时兼顾一方面可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的功能。

发明内容

本申请实施例通过提供一种基于Web应用的终端音视频数据通信方法和装置，解决了现有技术中在现有的智能设备中，无法同时兼顾一方面可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的功能。

为此，一方面，本申请实施例提供了一种基于Web应用的终端音视频数据通信方法，应用于电视机中，所述方法包括：

接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；

根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；

通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。

另一方面，本申请实施例一种基于Web应用的终端音视频数据通信装置，应用于电视机中，所述装置包括：

连接请求接收模块，用于接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；

数据通道建立模块，用于根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；

音视频数据接收模块，用于通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。

从上述技术方案可以看出，电视机端通过接收WebRTC服务器转发的携带有第一HTML5应用的身份信息连接请求信息，所述第一HTML5应用为第一终端中的Web应用，并在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用，最后通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示，也就是说，第一HTML5应用和第二HTML5应用与WebRTC服务器进行通信，类似于在第一终端和电视机之间实现一个简单的握手协议，进一步在两个终端设备的HTML5应用之间建立了一个可供数据传输的连接通道，这样，可以把第一终端设备的音视频数据通过此连接通道直接点对点的传输给电视机上，由电视机最终实现该音视频数据的显示，本方案可应用于需要灵活传输音视频数据，且需要大屏显示的业务中，如视频会议业务等，一方面方便用户可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的用户需求，利用电视平台的大屏幕优势，使其具备显示实时音视频流的能力，提升了用户体验。

附图说明

图1为本申请实施例一中基于Web应用的终端音视频数据通信方法的流程图；

图2为本申请实施例一中电视端二维码控制界面示意图；

图3为本申请实施例一中电视平台功能模块示意图；

图4为本申请实施例一中Web应用运行平台功能模块示意图。；

图5为本申请实施例一中浏览器与服务器关系示意图；

图6为WebRTC服务端信令处理过程示意图；

图7为WebRTC数据传输信道进行音视频数据流处理过程示意图；

图8为本申请实施例二中基于Web应用的终端音视频数据通信装置结构示意图。

具体实施方式

本申请实施例通过提供一种基于Web应用的终端音视频数据通信方法和装置，解决了现有技术中在现有的智能设备中，无法同时兼顾一方面可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的功能。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

实施例一

本发明实施例可以应用于具备大屏幕的智能终端中，尤其适用于电视机，在现有终端中，电视机是具有大屏幕终端设备能力的载体，在电视终端中播放的视频信息，可以更清晰更好的显示视频信息的内容，满足多个人共同观看视频流信息的需求。但是，现在的电视平台，很少会配置摄像头和麦克风，无法获取实时音视频流的信息，并且有不方便移动的缺点，也不具备和网络终端进行视频通讯的功能。

图1为本申请实施例一提供的一种基于Web应用的终端音视频数据通信方法，应用于电视机中，本方法包括：

步骤S101：接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；

第一终端可以为智能手机，平板电脑（PAD），电脑等通常具备摄像头和麦克风功能的智能终端设备，还可以包括电视机，机顶盒，家庭网关等任意具有网络接入功能的终端设备，此类设备可以较为方便的开启并使用摄像功能和语音相关功能，其摄像头和麦克风都已经成为标准配置，但是手机和PAD等终端设备的屏幕较小，如果把摄像头获取的实时视频流信息应用在互联网的视频通讯中（比如视频电话会议中），会由于显示图像较小而具有显示不清楚，无法观看的缺点。

本发明中，电视机接收网页实时通信WebRTC服务器转发的连接请求消息，该消息可由第一终端中发送，或者由第一终端中的普通应用程序，或者网页应用程序发送，或者由其他第三方终端或者服务器发送，在此不做限制。

WebRTC（WebReal-TimeCommunication——网页实时通信）是一个基于浏览器的实时多媒体通信技术。该项技术旨在使Web浏览器具备实时通信能力，无需依赖任何第三方插件。该项技术将Web浏览器打造成一个适用于在所有用户设备（比如移动智能终端和个人电脑等）间进行实时的音视频和数据通信的通用平台。

现有技术中，基于Web浏览器的多媒体通信服务是构建在特定的浏览器插件（如AdobeFlashPlayer）之上的，因为浏览器所依赖的HTTP协议是一种无连接状态的协议——即浏览器与服务器建立连接，下载文件，断开连接，再显示接收到的文件。因此，浏览器不能与服务器实时动态地交换数据。无连接状态的HTTP协议导致需要实时通信的服务（如聊天等）只能采取定时访问服务器的方法（即轮询方式）来实现。然而，在用户访问量增多时，这种方式严重的消耗服务器端资源，进而严重的影响服务器的性能。

WebRTC服务器可以是一个单一的服务器，也可以为由几个功能服务器共同组成的服务器端，即可以为多个不同的Web服务器的组合，以实现不同浏览器，不同网络，不同的web应用之间的通信，完成协议转换，消息转换，路由寻址，建立连接，页面优化，加速，信息添加等功能。

由WebRTC服务器发送给电视机的连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用。例如，电视机接收到的连接请求消息中包括“webqq.webrtcfromiphone”，其表明是苹果手机iphone中的网页应用webqq发给电视机的一个请求连接的消息。此类请求消息中携带的身份信息可以为各种类型的适合于电视机进行解析的标识，字符等。此身份信息可以由厂商制定，或由使用者自定义。

步骤S102：根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；

此步骤类似于一个简单的握手协议，第一HTML5应用和第二HTML5应用均可以与WebRTC服务器进行通信，相当于使第一终端和电视机在服务器端进行注册，告知WebRTC服务器将要进行通信的两端的身份等属性信息。进而在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，作为WebRTC数据连接信道的技术特性，其将设备采集到的音视频数据在加密的情况下采用SRTP协议进行传输，以确保信息在传输过程中的安全性。另外，WebRTC采用STUN、TURN和ICE等协议栈对VoIP网络中的防火墙或者NAT进行穿透。其中，STUN可以处理大部分NAT穿透问题；TURN是STUN协议的一个增强版，专门用于处理对称形NAT穿透问题；ICE是一个整合了STUN和TURN的框架，为VoIP或视频通话配置以及媒体传输提供可靠的服务。也就是说，第一终端设备可以为与电视机处于相同局域网下，例如同一个房间内的智能终端，如用户可在电视机前，使用手机的摄像头和麦克风，将手机端采集到的音视频流通过WebRTC信道传输给电视机端进行显示，第一终端也可以是网络端的设备，如在不同地区的用户A和B，用户A面前有电视机，异地的用户B使用智能手机，则用户B通过终端采集的音视频数据流可以在WebRTC信道的协助下，穿透不同网络之间设置的防火墙等网络系统，传输给用户A面前的电视机的Web应用中，实现在电视机端显示音视频流数据。

步骤S103：通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。

在软件实现上，我们的方法中主要集成了WebRTC服务端单元。包括房间服务器部分、信令服务器部分和STUN/TURN/ICE服务器部分。负责用户发现及通信；负责传递信令（signaling）来建立信道，在浏览器点对点之间传递流数据之前完成信息的交换；负责NAT/防火墙穿越；由于浏览器本身不支持相互之间直接建立信道进行通信，都是通过服务器进行中转。比如现在有两个客户端，甲和乙，他们俩想要通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过也是一样。这样甲与乙之间的一次消息要通过两段信道。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。WebRTC技术应运而生。WebRTC是一个开源项目，旨在使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间（peer-to-peer）的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频流数据。

从上述实施例可知，电视机端通过接收WebRTC服务器转发的携带有第一HTML5应用的身份信息连接请求信息，所述第一HTML5应用为第一终端中的Web应用，并在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用，最后通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示，也就是说，第一HTML5应用和第二HTML5应用与WebRTC服务器进行通信，类似于在第一终端和电视机之间实现一个简单的握手协议，进一步在两个终端设备的HTML5应用之间建立了一个可供数据传输的连接通道，这样，可以把第一终端设备的音视频数据通过此连接通道直接点对点的传输给电视机上，由电视机最终实现该音视频数据的显示，本方案可应用于需要灵活传输音视频数据，且需要大屏显示的业务中，如视频会议业务等，一方面方便用户可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的用户需求，利用电视平台的大屏幕优势，使其具备显示实时音视频流的能力，提升了用户体验。

WebRTC支持点对点通讯，但是WebRTC仍然需要服务端，因为:

1，为了协调通讯过程客户端之间需要交换元数据，如一个客户端找到另一个客户端以及通知另一个客户端开始通讯。

2，需要处理NAT或防火墙，这是公网上通讯首要处理的问题。

可选的，本申请实施例中在步骤S101之前还包括步骤：接受用户的触发指令，并根据所述第二HTML5应用的URL地址生成二维码信息，所述二维码信息用于供所述第一终端扫描打开所述第一终端中的第一HTML5应用，并触发所述第一HTML5应用向所述WebRTC服务器发送连接请求信息。

在电视终端的web应用运行平台，会把HTML5应用在电视终端中显示出来，通过在HTML5应用中集成二维码的功能，将HTML5应用对应的URL生成二维码信息。手机或者PAD等本地设备端进行二维码扫描后，连接到webrtc服务端。这样，就不需要用户在客户端浏览器地址栏内输入网页地址，方便用户操作，对不具备二维码扫描的终端设备，比如电脑，可以在浏览器中输入提示的URL，连接到webrtc服务端。

二维码可以存储很多信息如网址、文本信息、特定代码等，本实施例是将HTML5应用的URL信息存储在二维码中，用户扫描二维码后便可以在小型智能终端如手机中打来HTML5应用，可参考图2所示的二维码控制界面。

示例的，用户触发在电视机端的Web应用A启动，其启动界面可生成存储有应用A的URL地址的二维码，用户通过手机扫描该二维码，可在手机端相应的打开与应用A相关联的应用B，也就是本申请实施例中的第一HTML5应用，同时触发第一HTML5应用与WebRTC服务器进行通信，向所述WebRTC服务器发送连接请求信息

可选的，如图3，4所示的电视平台和Web应用运行平台功能模块示意图，电视机中预先构建有Web应用运行平台，所述电视机基于所述Web应用运行平台构集成所述第二HTML5应用，所述第二HTML5应用是基于HTML5标准的Web应用，所述第二HTML5应用在电视桌面上以图标形式显示，并可以本地应用相同的启动方式运行。

本申请实施例所述的电视平台包括但不限于android系统和linux系统，需要连接的客户端终端包括但不限于是android系统、linux系统、iOS系统、windows系统的电脑、电视、手机、PAD等，只需客户端终端设备包括支持webrtc的浏览器。

电视机的Web应用运行平台采用crosswalk架构，将chromium浏览器引擎打包到所述HTML5应用中，所述chromium浏览器引擎可随chromium浏览器内核的升级进行更新。

web应用运行平台是指能够支撑HTML5应用运行的平台或者运行环境。web应用运行平台是HTML5应用在终端上展现及执行的环境，不限于crosswalk架构，可以是操作系统HTML5运行环境、浏览器、浏览器引擎等。浏览器内核是web应用运行平台的核心。我们方案中实现的web应用运行平台引用chromium内核对应用做渲染和操作的支持，同时添加了对应用打包和管理功能，使HTML5应用能够在电视平台中像运行电视平台中的应用一样运行起来。

其中Web应用运行平台模块除了核心的WebRTC服务端单元，还包括web应用管理单元和chromium内核管理单元；

web应用管理单元，负责提供对应用的打包和管理等功能，使HTML5应用能够在电视平台中像运行电视平台中的应用一样运行起来，并且使HTML5应用在电视平台中有可以和本地的应用相同的启动方式运行；负责应用生命周期的管理和设备的API的扩展功能；负责扩展集成webrtc服务端单元；

chromium内核管理单元，引用chromium内核，把HTML5应用加载并在电视平台中渲染和显示出来；本模块可以随着chromium内核的升级及时更新，以提供对HTML5应用更好的操作和性能上的支持；本模块脱离开平台浏览器内核版本的限制，使chromium内核以动态库的形式打包在应用中，解决了以前的HTML5应用要在不同的平台适应不同版本的浏览器内核的限制。

可选的，接收网页实时通信WebRTC服务器转发的连接请求信息的步骤具体为：

所述第一HTML5应用与所述WebRTC服务器建立网页套接字协议（WebSocket）信令传输通道；

所述第一HTML5应用经由所述WebSocket信令传输通道将所述连接请求信息推送至所述WebRTC服务器；

所述WebRTC服务器与第二HTML5应用之间建立WebSocket信令传输通道，并将所述第一HTML5应用发送的连接请求信息转发给所述电视机中的第二HTML5应用。

WebSocket作为HTML5一种协议方式，实现了浏览器与服务器的双向通讯。在WebSocketAPI中，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。我们利用了WebSocket技术的特性，实现了信令数据的交互，方便用户快速交互一些数据量较小的信令等。当然，用户也可以使用常用的AJAX轮询的信令传输方式，在此不做限制。

可选的，所述方法进一步包括：

当根据所述第一HTML5应用的身份信息判断不接受所述连接请求时，所述WebRTC服务器将所述拒绝连接的信息经所述WebSocket信令传输通道发送给所述第一终端。

可选的，在完成所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息的步骤之后包括：

关闭与所述WebRTC服务器之间建立的所述WebSocket信令传输通道，以及关闭在所述第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道。

WebRTC的音视频数据从连接的客户端的数量角度来区分，可以分为一对一模式和多人模式。

对于一对一模式，该模式是最简单的应用模式。如图5，首先，基于WebRTC的Web应用通过Web服务器来进行信令解析。然后，每个浏览器将本地采集到的音视频数据发送给对端浏览器。最后，每个浏览器对本地和对端的多媒体数据进行处理和显示。

如图5，对于多人模式，相比较于一对一模式，多人模式较为复杂。该模式与一对一模式不同的是，每个浏览器将本地采集到的音视频数据广播给其余所有浏览器。在实际中，由于终端的处理能力，电池续航能力以及网络带宽的限制，WebRTC能够根据实际情况支持有限数量的人同时进行音视频服务。

在前述实施例内容的基础上，本申请还提供一种可选的应用场景，首先如图6和图7所示，为本实施例的交互数据的终端之间的信令交互处理流程，如果手机、PAD、电脑以及网络端音视频数据等终端设备需要和电视机端进行数据交互，首先他们需要和电视中的Web应用运行平台端上集成的WebRTC服务端进行通信，在该WebRTC服务器注册上自己的身份属性信息，告诉电视端是哪些终端设备想要发送音视频数据过来，电视端接收相应的请求后，电视端可以和手机、PAD等这些终端设备之间建立WebRTC数据连接信道，后续的音视频数据流可通过WebRTC数据连接信道传输给电视平台进行显示。

实施例二

基于相同的发明构思，本申请还提供一种基于Web应用的终端音视频数据通信装置，应用于电视机中，图8示出了本实施例中的装置包括：

连接请求接收模块201，用于接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；

数据通道建立模块202，用于根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；

音视频数据接收模块203，用于通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。

从上述实施例可知，电视机端通过接收WebRTC服务器转发的携带有第一HTML5应用的身份信息连接请求信息，所述第一HTML5应用为第一终端中的Web应用，并在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用，最后通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示，也就是说，第一HTML5应用和第二HTML5应用与WebRTC服务器进行通信，类似于在第一终端和电视机之间实现一个简单的握手协议，进一步在两个终端设备的HTML5应用之间建立了一个可供数据传输的连接通道，这样，可以把第一终端设备的音视频数据通过此连接通道直接点对点的传输给电视机上，由电视机最终实现该音视频数据的显示，本方案可应用于需要灵活传输音视频数据，且需要大屏显示的业务中，如视频会议业务等，一方面方便用户可以随时随地方便的发送音视频流信息给网络侧的其他终端，另一方面同时又满足大屏幕观看实时视频和进行音视频通信的用户需求，利用电视平台的大屏幕优势，使其具备显示实时音视频流的能力，提升了用户体验。

可选的，本实施例的装置还包括：

二维码生成模块，用于接受用户的触发指令，并根据所述第二HTML5应用的URL地址生成二维码信息，所述二维码信息用于供所述第一终端扫描打开所述第一终端中的第一HTML5应用，并触发所述第一HTML5应用向所述WebRTC服务器发送连接请求信息。

可选的，接收模块203包括：

第一信令通道建立模块，用于在所述第一HTML5应用与所述WebRTC服务器之间建立网页套接字协议（WebSocket）信令传输通道；

信息推送模块，用于使所述第一HTML5应用经由所述WebSocket信令传输通道将所述连接请求信息推送至所述WebRTC服务器；

第一信令通道建立模块，用于在所述WebRTC服务器与第二HTML5应用之间建立WebSocket信令传输通道，并将所述第一HTML5应用发送的连接请求信息转发给所述电视机中的第二HTML5应用。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发

明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种基于Web应用的终端音视频数据通信方法，应用于电视机中，其特征在于，所述方法包括：

接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；

根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；

通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。

2.如权利要求1所述的基于Web应用的终端音视频数据通信方法，其特征在于，所述接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息的步骤之前还包括：

接受用户的触发指令，并根据所述第二HTML5应用的URL地址生成二维码信息，所述二维码信息用于供所述第一终端扫描打开所述第一终端中的第一HTML5应用，并触发所述第一HTML5应用向所述WebRTC服务器发送连接请求信息。

3.如权利要求2所述的基于Web应用的终端音视频数据通信方法，其特征在于，所述电视机中预先构建有Web应用运行平台，所述电视机基于所述Web应用运行平台构集成所述第二HTML5应用，所述第二HTML5应用是基于HTML5标准的Web应用，所述第二HTML5应用在电视桌面上以图标形式显示，并可以本地应用相同的启动方式运行。

4.如权利要求3所述的基于Web应用的终端音视频数据通信方法，其特征在于，所述电视机的Web应用运行平台采用crosswalk架构，将chromium浏览器引擎打包到所述HTML5应用中，所述chromium浏览器引擎可随chromium浏览器内核的升级进行更新。

5.如权利要求4所述的基于Web应用的终端音视频数据通信方法，其特征在于，所述接收网页实时通信WebRTC服务器转发的连接请求信息的步骤具体为：

所述第一HTML5应用与所述WebRTC服务器建立网页套接字协议（WebSocket）信令传输通道；

所述第一HTML5应用经由所述WebSocket信令传输通道将所述连接请求信息推送至所述WebRTC服务器；

所述WebRTC服务器与第二HTML5应用之间建立WebSocket信令传输通道，并将所述第一HTML5应用发送的连接请求信息转发给所述电视机中的第二HTML5应用。

6.如权利要求5所述的基于Web应用的终端音视频数据通信方法，其特征在于，所述方法进一步包括：

当根据所述第一HTML5应用的身份信息判断不接受所述连接请求时，所述WebRTC服务器将所述拒绝连接的信息经所述WebSocket信令传输通道发送给所述第一终端。

7.如权利要求5所述的基于Web应用的终端音视频数据通信方法，其特征在于，在完成所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息的步骤之后包括：

关闭与所述WebRTC服务器之间建立的所述WebSocket信令传输通道，以及关闭在所述第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道。

8.一种基于Web应用的终端音视频数据通信装置，应用于电视机中，其特征在于，所述装置包括：

连接请求接收模块，用于接收网页实时通信WebRTC服务器转发的连接请求信息，所述连接请求信息携带有第一HTML5应用的身份信息，所述第一HTML5应用为第一终端中的Web应用；

数据通道建立模块，用于根据所述第一HTML5应用的身份信息判断是否接受其连接请求，若是，则在第二HTML5应用与所述第一HTML5应用之间建立WebRTC数据连接信道，所述第二HTML5应用为所述电视机中的Web应用；

音视频数据接收模块，用于通过所述建立的WebRTC数据连接信道接收所述第一HTML5应用发送的音视频数据信息并显示。

9.如权利要求8所述的基于Web应用的终端音视频数据通信装置，其特征在于，所述装置还包括：

二维码生成模块，用于接受用户的触发指令，并根据所述第二HTML5应用的URL地址生成二维码信息，所述二维码信息用于供所述第一终端扫描打开所述第一终端中的第一HTML5应用，并触发所述第一HTML5应用向所述WebRTC服务器发送连接请求信息。

10.如权利要求9所述的基于Web应用的终端音视频数据通信装置，其特征在于，所述连接请求接收模块包括：

第一信令通道建立模块，用于在所述第一HTML5应用与所述WebRTC服务器之间建立网页套接字协议（WebSocket）信令传输通道；

信息推送模块，用于使所述第一HTML5应用经由所述WebSocket信令传输通道将所述连接请求信息推送至所述WebRTC服务器；

第一信令通道建立模块，用于在所述WebRTC服务器与第二HTML5应用之间建立WebSocket信令传输通道，并将所述第一HTML5应用发送的连接请求信息转发给所述电视机中的第二HTML5应用。