CN108337246B - 防止重放延迟的媒体重放设备和媒体服务设备 - Google Patents

Abstract

提供防止重放延迟的媒体重放设备和媒体服务设备。所述媒体重放设备可包括延迟检测模块以检测重放延迟。重放延迟检测可通过单次测量确定由网络、解码和渲染引起的延迟。当发生重放延迟时，可以通过请求服务器提供具有改变的配置文件的媒体数据来消除重放延迟。由于可通过多个重放延迟因素的单次测量来确定重放延迟，因此可以以适合于无插件环境的方式简单并稳定地执行媒体重放。

Description

防止重放延迟的媒体重放设备和媒体服务设备

本申请要求于2017年2月10日提交的第62/457,203号美国临时申请的优先权，于2017年1月20日提交到韩国知识产权局的第10-2017-0009963号韩国专利申请以及于2017年7月11日提交到韩国知识产权局的第10-2017-0087666号韩国专利申请的优先权，所述专利申请的公开通过引用全部合并于此。

技术领域

与示例性实施例一致的设备和方法涉及在web浏览器上重放媒体，更具体地讲，涉及用于确定并预防网络延迟的媒体重放设备和方法。

背景技术

为了使用户通过互联网在web浏览器上重放媒体数据，提供了一种使用将编解码器、解码器、渲染器等写入本地代码中的插件的方法。作为web浏览器插件的代表性示例，ActiveX和Netscape插件应用编程接口(NPAPI)被广泛使用。

ActiveX是由Microsoft使用以下两种技术的组合开发：组件对象模型(COM)和对象链接与嵌入(OLE)。然而，狭义上讲，它表示在作为web浏览器的Internet Explorer中以扩展的形式使用的ActiveX控件。ActiveX用于在Internet Explorer web浏览器中播放媒体。

NPAPI是针对Netscape浏览器开发的应用编程接口(API)，并且在功能上与Internet Explorer的ActiveX相似。NPAPI是针对以插件的形式使用外部应用程序以增强web浏览器的功能而提供的API，并主要被web环境用于其萌芽阶段中。换句话说，它被开发为在早期的网页上播放音乐和视频。例如，有Java Applet、Adobe Flash、Real Player等。

然而，由于插件被黑客用作散布恶意代码的途径，因此web浏览器不再支持插件。就NPAPI而言，制作并发行Chrome的Google在发布Chrome版本45之后不再支持NPAPI。就ActiveX而言，在被用作Windows 10的默认浏览器的Edge版本的发布之后，Microsoft不再支持ActiveX。

作为用于在没有插件的web浏览器上重放媒体的方法，基于超文本标记语言5(HTML5)的视频标签执行解码。当使用视频标签执行解码时，可以以优异的性能处理高分辨率视频和高fps(每秒传输帧数)视频。然而，对由视频标签支持的视频格式有限制，并且视频标签当前仅支持三种格式：MP4、WebM和Ogg。

可通过使用以JavaScript实现的解码器来缓解由于对编解码器格式的限制导致的视频标签的缺点。由于JavaScript解码器可根据视频格式执行解码，因此可以对视频标签不支持的编解码器格式的视频进行解码。因此，在本公开中，媒体重放设备被配置为根据视频编解码器格式选择性地使用视频标签和JavaScript解码器。

在web浏览器上的媒体重放中，除了插件之外，还应该考虑媒体重放延迟。重放延迟可给用户造成不便，并可对用于实时直播视频重放的重放环境和实时信息传输非常重要的视频监控产生负面影响。

web浏览器中的媒体重放的第一延迟因素为由于网络引起的延迟。在移动装置的使用迅速增加的环境中，由于网络带宽和计算装置的不良性能引起的网络延迟成为重放延迟的主要因素。第二延迟因素为当以JavaScript实现解码器时可能发生的延迟。由于JavaScript的动态特性，在高分辨率的视频中，JavaScript解码器的性能可急剧下降，从而导致重放延迟。第三延迟因素为由于渲染引起的延迟。根据计算装置的性能(例如，当中央处理器(CPU)或图形处理器(GPU)不能处理渲染所需的计算量时)可发生渲染延迟。

传统上，作为重放延迟确定方法，已经在连网、解码以及渲染和合成中的每个步骤中测量了延迟时间。通过计算在每个步骤中媒体被输入时与媒体被输出时之间的时间差来计算在每个步骤中的延迟时间。然而，除了上述的网络、解码和渲染之外，该方法还需要测量在每一个其他步骤中的延迟，并且不适用于在应被写入干净和轻量级代码的无插件环境中的媒体重放设备。

因此，可需要设计适用于无插件环境的重放延迟确定方法以及用于在web浏览器上重放视频的延迟消除方法。

发明内容

示例性实施例至少解决上面的问题和/或缺点以及上面未描述的其他缺点。此外，示例性实施例不需要克服上述缺点，并且可不克服上述问题中的任何问题。

一个或多个示例性实施例提供一种用于通过在web浏览器上重放媒体的环境中的一次测量来确定媒体重放的延迟的方法，其中，所述web浏览器具有多个延迟因素，诸如，网络延迟、编码延迟以及渲染延迟。

此外，一个或多个示例性实施例提供一种适合于无插件环境的媒体重放延迟确定方法。

根据示例性实施例的方面，提供一种用于在web浏览器上重放媒体的媒体重放设备，包括：接收单元，被配置为使用支持web服务的通信协议接收在媒体服务设备中产生的媒体数据；第一媒体恢复单元，被配置为通过以脚本编写的解码器对接收的媒体数据进行解码，其中，所述脚本被配置为通过web浏览器解析；渲染器，被配置为执行渲染以显示由解码器解码的媒体数据；延迟检测单元，被配置为通过将包括在媒体数据中的时间戳与媒体数据到达第一媒体恢复单元的时间进行比较，来检测媒体数据的重放延迟；配置文件改变单元，被配置为响应于延迟检测单元检测到重放延迟来请求媒体服务设备发送具有改变的配置文件的媒体数据。

根据另一示例性实施例的方面，提供一种用于向媒体重放设备发送媒体数据的媒体服务设备，所述媒体服务设备包括：模块存储单元，被配置为存储用于在媒体重放设备的web浏览器上重放媒体数据的脚本模块；模块传输单元，被配置为响应于媒体服务设备与媒体重放设备之间的连接被建立，将脚本模块传输到媒体重放设备；打包单元，被配置为将媒体数据打包以产生传输包；web服务器，被配置为建立所述连接并响应于从媒体重放设备接收到请求的配置文件而将传输包发送到媒体重放设备，其中，脚本模块被配置为在没有插件的情况下在媒体重放设备中对媒体数据进行解码，并检测在媒体数据的重放期间发生的重放延迟。

根据示例性实施例，即使使用以JavaScript实现的解码器，也可以防止由于JavaScript的动态性质引起的媒体重放延迟。因此，用户可重放媒体而没有视频的卡顿，并且本公开在由于对编解码器格式的限制而不能使用视频标签的环境中非常有用。

此外，根据示例性实施例，可通过单次测量来确定由于多个延迟因素(诸如，网络延迟、解码延迟和渲染延迟)引起的延迟。因此，可以以适合于无插件环境的方式简单并稳定地执行媒体重放。

附图说明

通过使用附图描述特定的示例性实施例，上面和其他方面将变得更清楚，其中：

图1示出根据示例性实施例的用于媒体重放的系统；

图2是示出针对装置之间的通信分层地定义的TCP/IP 4层模型的示图；

图3示出在媒体服务设备与媒体重放设备之间执行WebSocket连接的处理；

图4示出通过WebSocket连接发送和接收数据的处理的示例；

图5是示出通过网络接口发送的通信包的结构的示图；

图6示出根据示例性实施例的媒体服务设备的配置；

图7示出根据另一示例性实施例的媒体服务设备的配置；

图8示出根据示例性实施例的模块存储单元的脚本模块；

图9示出模块存储单元的脚本模块；

图10示出根据示例性实施例的媒体重放设备的配置；

图11示出在延迟检测模块中确定重放延迟的方法；

图12示出根据另一示例性实施例的媒体重放设备的配置；

图13是示出媒体重放设备的操作处理的流程图；

图14是解释根据示例性实施例的产生以JavaScript实现的脚本模块的处理的示例性示图；

图15是用于实现媒体重放设备的计算装置的示例性示图。

具体实施方式

下面参照附图更加详细地描述示例性实施例。

在下面的描述中，即使在不同的附图中，相同的附图参考标号也用于相同的元件。提供在描述中定义的事物(诸如，详细的构造和元件)以帮助全面理解示例性实施例。然而清楚的是，可在没有那些具体定义的事物的情况下实践示例性实施例。此外，由于公知的功能或构造可能以不必要的细节模糊描述，因此不详细描述它们。

在此使用的术语仅为了描述特定实施例的目的，并不意图限制本公开。如在此使用的，除非上下文清楚地另有指示，否则单数形式也意图包括复数形式。还将理解，当在本说明书中使用术语“包括”时，指定存在阐述的组件，但不排除存在或添加一个或多个其他组件。

当诸如“……中的至少一个”的表述在一列元素之后时，修饰整列元素而不修饰该列中的单个元素。

图1示出根据示例性实施例的用于重放和寻找媒体的系统。图1中示出的系统包括：媒体服务设备110、媒体重放设备120以及连接两个设备110和120的网络430。

媒体服务设备110包括适合于向一个或多个视频重放设备提供计算服务的计算或处理装置。例如，媒体服务设备110包括能够产生或存储视频流并将视频流发送到用户装置的装置(诸如，网络相机、网络视频录像机(NVR)和数字视频录像机(DVR))。媒体服务设备110也可被称为媒体服务系统，其中，服务器和网络相机被包括在媒体服务系统中。

媒体重放设备120包括适合于经由网络430与媒体服务设备110或其他计算用户装置进行交互的计算或处理装置。例如，媒体重放设备120可包括台式计算机、移动电话或智能电话、个人数字助理(PDA)、膝上型计算机和平板计算机。

在媒体重放设备120的请求下，通过网络430发送由媒体服务设备110实时捕捉或存储的媒体。用户可重放或寻找通过在媒体重放设备120的web浏览器210上实现的用户接口发送的媒体。具体地讲，web浏览器210可包括安装在台式计算机或移动电话上的公知的浏览器(诸如，Google Chrome、Microsoft Explorer、Mozilla Firefox和Apple Safari)，并且还可包括使用应用编程接口(API)或web浏览器的资源单独创建的软件应用。

在下文中，将参照图2至图5来描述通过WebSocket协议发送的实时流传输协议(RTSP)和/或实时传输协议(RTP)流。WebSocket可用作媒体服务设备110与媒体重放设备120之间的网络通信方案。

图2是示出针对装置之间的通信而分层次地定义的传输控制协议/互联网协议(TCP/IP)4层模型的示图。所述四层包括：网络接口层21、互联网层22、传输层23和应用层24。由于WebSocket能够在传输层23之上传输消息，因此为了使用WebSocket连接，可必须首先在媒体服务设备110与媒体重放设备120之间建立TCP传输连接。一旦(例如，经由三方握手处理)在媒体服务设备110与媒体重放设备120之间建立WebSocket连接，则通过发送WebSocket包来执行WebSocket通信。下面将参照图3至图5详细描述WebSocket连接和WebSocket包。

图3示出在媒体服务设备110与媒体重放设备120之间执行WebSocket连接的处理。媒体重放设备120请求媒体服务设备110使用WebSocket URI发起WebSocket连接。可使用GetServiceCapabilities命令获得WebSocket URI。例如，WebSocket URI被表示为“ws：//192.168.0.5/webSocketServer”(操作S1000)。

媒体重放设备120可将WebSocket升级请求发送到媒体服务设备110。媒体服务设备120可利用代码101进行响应(操作S1100)，其中，代码101为用于批准协议改变请求的状态码。

在媒体服务设备110与媒体重放设备120之间建立WebSocket连接之后，通过经由WebSocket发送的RTSP/RTP协议替代超文本传输协议(HTTP)/1.1协议来交换数据。图3中的DESCRIBE、SETUP、PLAY、PAUSE和TEARDOWN为RTSP命令。DESCRIBE请求包括统一资源定位符(URL)。对DESCRIBE的响应消息还包括该请求的描述。SETUP请求指定是否应该发送单个媒体流。PLAY请求是用于播放一个或全部媒体流的请求，并可以是多个请求。PAUSE请求是用于暂停一个或全部媒体流的重放的命令。可响应于PLAY请求而重新开始重放。TEARDOWN请求是用于终止会话的命令。可通过TEARDOWN请求停止所有媒体流的重放，并且还释放与该数据相关的所有会话(操作S1200)。

在如下的表1中提供图3中示出的在WebSocket连接处理中从媒体重放设备120发送的请求消息和媒体服务设备110的响应消息的示例。

【表1】

该WebSocket连接是根据遵循HTML5标准的WebSocket协议进行的。具体地讲，由于WebSocket连接持续地支持双向通信，因此可在WebSocket连接不断开的情况下，在媒体服务设备110与媒体重放设备120之间持续地发送和接收数据。

图4示出通过WebSocket连接发送和接收数据的处理的示例。参照图4，首先，媒体重放设备120将TCP/IP连接请求消息发送到媒体服务设备110，并且媒体服务设备110接收该请求消息，并将TCP响应消息(SYN-ACK)发送到媒体重放设备120，从而建立TCP/IP连接。TCP传输连接可由一对本地TCP套接字和远程TCP套接字形成。每个TCP套接字至少由标识符(诸如，端口号和IP地址)定义。可在媒体重放设备120与媒体服务设备110之间建立基于用户数据报协议(UDP)/IP的连接，替代基于TCP/IP的连接。

然后，当通过媒体重放设备120与媒体服务设备110之间的握手处理建立WebSocket连接时，可随后执行它们之间的持续的数据发送/接收。也就是说，媒体重放设备120以传输WebSocket包(socket.send)的形式将媒体流传输请求发送到媒体服务设备110，媒体服务设备110以响应WebSocket包(socket.onMessage)的形式将媒体流发送到媒体重放设备120。这个处理可在媒体重放设备120与媒体服务设备110之间持续执行，直到媒体流传输停止或者完成为止。

图5是示出通过网络接口21发送的通信包的结构的示图。当RTP头44添加到与数据45对应的RTP有效载荷时，RTP有效载荷变为RTP包。RTP包可相当于WebSocket有效载荷，并且WebSocket头43可添加到RTP包以变为WebSocket包。WebSocket包可相当于TCP有效载荷，并且TCP头42添加到WebSocket包以变为TCP包。最后，TCP包相当于IP有效载荷，并且IP头41添加到TCP包，从而完成通信包，即，IP包。在媒体服务设备110和媒体重放设备120二者中执行完成IP包的处理和移除每个头的处理。

由于通过基于HTML5的WebSocket协议来执行媒体服务设备110与媒体重放设备120之间的通信，因此可由能够以HTML5解析的脚本代码来实现执行RTSP/RTP发送/接收控制的模块和解码器。因此，可在没有如常规情况那样单独安装插件的情况下，在HTML5环境的web浏览器中实现使用RTSP/RTP协议的媒体重放。

至此已经描述了媒体服务设备110与媒体重放设备120之间的网络通信方案。在下文中，将参照图6至图15描述媒体服务设备110与媒体重放设备120的配置和操作方法。

图6示出根据示例性实施例的媒体服务设备110的配置。在一个示例性实施例中，媒体服务设备110包括：实时视频相机111、编码器112、打包单元113、web服务器114、模块存储单元115、模块传输单元116和控制单元117。编码器112、打包单元113和控制单元117可被包括在一个或多个处理器中。

实时视频相机111可实时捕捉图像，并且所述捕捉包括执行视频捕捉和音频记录二者的情况以及仅执行视频捕捉的情况。在下文中，在实时视频相机111中仅执行视频捕捉的情况将被描述为示例。

编码器112被配置为对由实时视频相机111捕捉的媒体进行压缩和编码。编码器112的编码不一定使用由嵌入在web浏览器中的解码器支持的特定编解码器来执行，而是可以以任意编解码器格式执行。

打包单元113将编码的媒体数据打包以产生传输包。可通过将视频划分成具有适当长度的块以促进经由网络430的传输或者如果视频短，则通过将控制信息(诸如，接收的地址)共同分配给适当长度的每个数据，来执行打包。在这种情况下，控制信息位于包的头中。传输包为上述WebSocket包的形式。

打包单元113可根据由媒体重放设备120请求的方法来执行视频的打包。将在图12的实施例中描述的媒体重放设备120包括JavaScript解码器和视频标签解码器，其中，JavaScript解码器作为以可由web浏览器解析的脚本编写的解码器，视频标签解码器作为嵌入在web浏览器中的解码器。可根据诸如实时视频的重放、存储的视频的重放、视频的编解码器格式等的因素来选择性地使用解码器。如稍后将参照图12描述的，JavaScript解码器基于逐帧(诸如，按逐帧的单位)执行解码，视频标签解码器基于逐个容器(诸如，按逐个容器的单位)执行解码。因此，媒体重放设备120可根据用于执行解码的解码器向打包单元113请求容器或帧格式的传输包，并且打包单元113可响应于此来执行打包。

web服务器114建立与媒体重放设备120的通信会话。例如，可通过媒体服务设备110的web服务器114与媒体重放设备120之间的握手处理在它们之间建立WebSocket连接。之后，根据媒体重放设备120的请求，通过web服务器114发送由打包单元113产生的传输包。

模块存储单元115可存储在媒体重放设备120中重放和寻找视频所必需的脚本模块。脚本模块作为以可由web浏览器解析的脚本编写的代码的模块，其允许媒体重放设备120在没有安装插件或单独的应用程序的情况下在HTML5环境的web浏览器中重放视频。在一个实施例中，脚本模块可以是以JavaScript编写的代码。稍后将参照图8和图9来描述脚本模块。

模块传输单元116可将存储在模块存储单元115中的脚本模块发送到媒体重放设备120。模块传输单元116响应于经由网络430在媒体重放设备120与媒体服务设备110之间建立的连接而发送脚本模块。

控制单元117可控制媒体服务设备110中的其他配置模块。例如，当媒体重放设备120通过网络430连接到web服务器114时，通过模块传输单元116将存储在模块存储单元115中的脚本模块发送到媒体重放设备120。在这种情况下，控制单元117将信号发送到各个模块或从各个模块接收信号，以控制操作被平稳地执行。

将基于图6的媒体服务设备110的配置模块的描述来描述操作方法。当媒体重放设备120经由网络430连接到web服务器114时，模块传输单元116将存储在模块存储单元115中的脚本模块发送到媒体重放设备120。当脚本模块被安装在媒体重放设备120中时，用户通过用户接口请求媒体重放。因此，媒体服务设备110在编码器112中对由实时视频相机111捕捉的实时实况媒体进行编码，并且在打包单元113中根据帧格式或容器格式将媒体数据打包成传输包，并经由web服务器114将它们传输到媒体重放设备120。

图7示出根据另一个示例性实施例的媒体服务设备110。图6的媒体服务设备110表示使用实时摄像机111发送实时直播视频的实施例，图7的媒体服务设备110表示发送存储在媒体存储单元118中的视频的实施例。

媒体存储单元118包括网络视频录像机(NVR)或个人视频录像机(PVR)。然而，将结合网络视频录像机来描述图7。媒体存储单元118从相机或服务器接收视频，并压缩和存储接收的视频。当存在来自媒体重放设备120的用于传输存储的视频的请求时，媒体服务设备110在打包单元113中将存储在媒体存储单元118中的视频打包，并通过web服务器114发送打包的数据。已经参照图6描述了媒体服务设备110的配置模块之中的打包单元113、web服务器114、模块存储单元115、模块传输单元116和控制单元117，因此，将省略对它们多余的描述。

图8示出根据示例性实施例的模块存储单元115的脚本模块。

图8的脚本模块包括：RTSP/RTP客户端模块121、解包模块122、延迟检测模块123、解码器模块124以及渲染器模块125。在图8的实施例中，以JavaScript实现脚本模块，其中，JavaScript为可通过web浏览器解析的脚本。

RTSP/RTP客户端模块121被配置为支持与媒体服务设备110的RTSP/RTP通信。在现有技术中，可能无法在没有插件的情况下在web浏览器上根据RTSP/RTP协议来处理媒体数据。根据本示例性实施例，即使web浏览器使用HTTP方案，RTSP/RTP客户端模块121也可允许可靠地接收通过RTSP/RTP协议发送的数据。

解包模块122可对从RTSP/RTP客户端模块121发送的包进行解包。解包是打包的相反操作。如果通过将媒体数据划分成具有适当长度的块以形成包来执行打包，则可通过经由将所述块(即，包)再次放在一起而将媒体数据恢复到打包之前的状态来执行解包。

延迟检测模块123可确定视频重放是否被延迟。具体地讲，延迟检测模块123可通过一次测量确定延迟的类型，包括由于多个因素(诸如，由媒体服务设备110与媒体重放设备120之间的网络引起的延迟、由解码器模块124引起的解码延迟以及由渲染器模块125引起的渲染延迟)引起的视频重放的延迟。稍后将参照图11给出它们的详细描述。

解码器模块124可对编码的媒体数据进行解压缩以对编码的媒体数据进行解码。与脚本模块的其他模块类似地，以JavaScript实现解码器模块124。由于以JavaScript实现解码器模块124，因此与嵌入在web浏览器中的解码器不同，可以在不限制编解码器格式的情况下以任意编解码器格式执行解码。还可以基于逐帧执行解码。

如果根据图8的实施例以JavaScript实现解码器模块124，则可由例如下面的表2中示出的代码来表示解码器模块124。

【表2】

渲染器模块125可对解码的媒体进行渲染并将它显示在输出装置(诸如，监视器等)上。渲染器模块125使用web图形库(WebGL)将YUV格式的视频数据转换成RGB格式的视频数据。WebGL是通过JavaScript可用的并允许创建3D图形界面的基于web的图形库。

图9示出根据示例性实施例的模块存储单元115的脚本模块。图9的脚本模块包括：RTSP/RTP客户端模块121、解包模块122和容器创建模块127。此外，在图9的实施例中，可以以JavaScript实现脚本模块。RTSP/RTP客户端模块121和解包模块122是参照图8描述的模块，因此将省略多余的描述。

仔细地参照图9的脚本模块，可以看出，与图8中不同，图9的脚本模块包括容器创建模块127。容器创建模块127可在未基于容器(诸如，未按容器的单位)对媒体数据打包时，通过收集帧来形成容器。

容器可表示数字多媒体容器格式(诸如，由视频标签支持的MPEG-DASH容器)。由于容器创建模块127可以以与视频标签兼容的容器格式配置视频帧，因此即使不以该容器格式从图像捕捉装置发送视频，也可以在没有兼容性问题的情况下使用视频标签。也就是说，它提供了可在不修改之前安装的图像捕捉装置的情况下使用视频标签的环境。

参照图8和图9描述的脚本模块从媒体服务设备110被发送到媒体重放设备120，并提供可在没有插件的情况下在媒体重放设备120的web浏览器210中执行重放媒体的操作的环境。也就是说，脚本模块被安装在媒体重放设备120中以配置用于重放媒体的系统。将参照图10和图12描述具有脚本模块的媒体重放设备120的实施例。

图10示出根据示例性实施例的媒体重放设备120的配置。

图10的媒体重放设备120包括：WebSocket客户端131、RTSP/RTP客户端模块121、解包模块122a和122b、延迟检测模块123a和123b、解码器模块124a和124b、渲染器模块125和画布标签133。在这种情况下，沿箭头从RTSP/RTP客户端模块121到渲染器模块125的模块是通过在媒体重放设备120经由网络430连接到媒体服务设备110之后接收脚本模块而配置的模块。下面将描述图10的媒体重放设备120的操作。

WebSocket客户端131可与媒体服务设备110的web服务器114建立WebSocket连接。媒体重放设备120和媒体服务设备110通过WebSocket客户端131与web服务器114之间的握手分别发送和接收传输包。

RTSP/RTP客户端模块121可支持如在图8的实施例中描述的在用户的web浏览器210中的RTSP/RTP通信。因此，用户可在不安装单独的插件的情况下使用RTSP/RTP协议通过HTML5环境的web浏览器210来重放媒体。

来自RTSP/RTP客户端模块121的视频数据根据编解码器格式被发送到H.264解包模块122a或H.265解包模块122b。如从模块的名称可以看出，H.264解包模块122a可以以H.264编解码器格式将视频解包，H.265解包模块122b可以以H.265编解码器格式将视频解包。即使编解码器格式不同，由于视频重放处理是相同的，所以将基于H.264编解码器格式的视频进行下面的描述。

在H.264解包模块122a中解包的视频被发送到延迟检测模块123a。延迟检测模块123a确定重放延迟，将参照图11对它们进行详细描述。

图11示出在延迟检测模块中确定重放延迟的方法。

这里，重放延迟可包括在从媒体服务设备110到媒体重放设备120的数据传输期间发生的网络延迟、在媒体重放设备120的第一媒体恢复单元143(参见图12)中的解码处理中发生的解码延迟以及在渲染器模块125中发生的渲染延迟。

可在解码器模块124a进行解码之前基于逐帧执行延迟检测。延迟检测模块123a使用帧到达解码器模块124a的时间和该帧的时间戳来确定是否发生延迟。时间戳可指示从媒体服务设备110产生或发送该帧时的时间。在下文中，将详细描述延迟检测方法。

首先，将描述作为第一次到达解码器模块124a的帧的第一帧。当第一帧到达解码器模块124a时的时间为Ta1并且第一帧的时间戳是Tf1时，计算Ta1与Tf1之间的时间差Td1。Td1是用于确定重放延迟的参考值。

Td1＝|Tf1-Ta1|

接下来，后续帧在重放正在进行时到达解码器模块124a的时间被称为Tax，后续帧的时间戳被称为Tfx，其中，后续帧为在第一帧之后的任意帧。计算Tax与Tfx之间的时间差Tdx。

Tdx＝|Tfx-Tax|

通过将Tdx与Td1进行比较来确定延迟检测。作为确定方法，如果Tdx与Td1的值之间的差超过预设的最大延迟时间Td_max，则可确定重放被延迟。最大延迟时间可被初始设置为由用户设置的任意值，然后根据学习自动改变为具有最佳值。

将使用示例来描述上述延迟检测方法。当第一帧到达解码器模块124a的时间为4秒(例如，00:00:04)并且第一帧的时间戳为1秒(例如，00:00:01)时，两个值之间的差Td1为3秒。当重放正在进行时任意后续帧到达解码器模块124a的时间为10秒(例如，00:00:10)并且该后续帧的时间戳为6秒(例如，00:00:06)时，两个值之间的差Tdx变为4秒。当预设的允许的Td_max为5秒时，Tdx与Td1之间的差为4秒-3秒，即，1秒，其未超过Td_max(5秒)。因此，确定未发生重放延迟。

作为另一个确定方法，可基于Tdx与Tdl的值之间的差是否超过最大延迟时间预定次数来检测重放延迟。因此，甚至可以防止重放延迟在短时间内暂时发生的情况被确定为重放延迟。例如，当Td1和Td_max如在上面描述的示例中那样分别为3秒和5秒并且在后续的4帧中Tdx的值分别为4秒、9秒、6秒和6秒时，Tdx与Td1之间的差分别为1秒、6秒、3秒和3秒。当预定次数被设置为3次时，由于Tdx与Td1之间的差超过Td_max的情况是发生一次的6秒的情况，因此确定没有发生重放延迟。

当通过上述方法在解码器进行解码之前执行延迟检测时，可通过单次测量确定由于网络、解码和渲染引起的延迟。这是因为JavaScript的单线程性质。由于以JavaScript实现的解码器模块124a作为单个线程操作，所以在处理当前帧之前可不接受下一帧。因此，如果在解码器模块124a进行解码之前执行延迟检测，则可检测到解码延迟和渲染延迟以及网络延迟。

媒体重放设备120可通过使用执行多线程功能的工作线程(web worker)执行在接收单元中的接收处理、在第一媒体恢复单元143中的解码处理以及在渲染器模块125中的渲染处理。即使在这种情况下，由于每个处理由一个流水线组成，因此延迟检测方法仍然有效。

通过使用图11的延迟检测方法，可通过单次测量来确定由于网络、解码和渲染引起的延迟。因此，可比必须单独测量网络延迟、解码延迟和渲染延迟的传统方法更容易地确定重放延迟。因此，通过使用如上所述的延迟检测方法，可以以适合于无插件环境的方式简单且稳定地执行媒体重放。

返回参照图10，将描述沿着来自延迟检测模块123a的箭头的H.264解码器模块124a。H.264解码器模块124a可对H.264编解码器格式的视频进行解码。在H.264解码器模块124a中，对视频基于逐帧执行解码。

同时，作为执行解码的另一个模块的H.265解码器模块124b可对H.265编解码器格式的视频进行解码。虽然在图10的媒体重放设备120中仅举例说明了H.264和H.265编解码器格式，但是可以以JavaScript实现解码器而不根据视频的编解码器格式。因此，也可以用其他编解码格式执行解码。

在H.264解码器模块124a的情况下，通过渲染器模块125和画布标签133将由H.264解码器模块124a解码的视频显示在web浏览器上。画布标签133是允许2D形状和位图图像被动态渲染的HTML5的元素。也就是说，它可被视为web浏览器上的绘图程序。由于它是大多数最新版本的web浏览器支持的功能，因此可通过以JavaScript实现的解码器基于逐帧处理视频，并通过使用画布标签133将视频显示在web浏览器上。

图12示出根据另一个示例性实施例的媒体重放设备120的配置。

在图12中，沿左下箭头的RTSP/RTP客户端模块121到渲染器模块125为通过从媒体服务设备110接收图8的脚本模块而配置的模块，沿着右下箭头的RTSP/RTP客户端模块121到容器创建模块127为通过接收图9的脚本模块而配置的模块。在图12的实施例中，将重点对媒体重放设备120的操作处理和当重放延迟被确定时的延迟消除方法进行描述。在这种情况下，将要重放的媒体是H.264或H.265的编解码格式的视频。

由WebSocket客户端131和RTSP/RTP客户端模块121构成的接收单元141使用通过WebSocket发送的RTSP/RTP协议从媒体服务设备110接收视频。

根据通过接收单元141接收的视频是被第一媒体恢复单元143还是第二媒体恢复单元144解码，将通过接收单元141接收的视频发送到不同的模块。第一媒体恢复单元143被配置为通过脚本模块的解码器模块124执行解码。也就是说，第一媒体恢复单元143被配置为通过由可以由web浏览器解析的脚本实现的解码器基于逐帧执行解码。第二媒体恢复单元144被配置为通过嵌入在web浏览器中的解码器执行解码。例如，可基于视频是嵌入在web浏览器中的解码器所支持的编解码器格式的视频还是高分辨率视频来确定哪个媒体恢复单元执行解码。稍后参照图13描述确定标准。

首先，将描述由第一媒体恢复单元143执行解码的情况。

根据编解码器格式，在适合的解包模块中将从接收单元141发送的视频解包。解包的视频基于逐帧被发送到延迟检测单元142。延迟检测单元142包括脚本模块的延迟检测模块123，并且通过使用参照图11描述的延迟检测方法来确定是否发生媒体的重放延迟。

当在延迟检测单元142中检测到延迟时，由配置文件改变单元145执行用于向媒体服务设备110请求具有改变的配置文件的媒体数据的操作。也就是说，如果延迟检测单元142检测到重放延迟，则配置文件改变单元145从延迟检测单元142接收指示重放被延迟的信号，并向媒体服务设备110请求改变的配置文件的媒体数据。

仔细参照图12，从延迟检测单元142向接收单元141以虚线绘制箭头。这指示由配置文件改变单元145发送反馈以请求媒体服务设备110改变媒体数据的配置文件。当延迟检测单元142检测到重放延迟时，延迟检测单元142可产生并发送媒体配置文件改变请求。可如上所述通过接收单元141将媒体配置文件改变请求发送到媒体服务设备110，或者可通过直接在配置文件改变单元145中形成单独的通道来执行媒体配置文件改变请求。

可通过改变媒体的配置文件来消除重放延迟。通过改变媒体的配置文件以减少媒体的重量，可使网络中的传输、解码和渲染更轻便。

在这种情况下，媒体的配置文件包括分辨率、帧率和比特率。分辨率表示构成图像的像素的数量并且通常以宽度×长度的形式表示。帧率的单位为每秒帧数(fps)，每秒帧数表示在一秒内重放的图像的数量。比特率的单位为每秒比特数(bps)，每秒比特数表示构成一秒的视频的数据的大小。

媒体的配置文件可被设置为预先设置的多个级别，并且所述多个级别可被配置为使得媒体的所有配置文件元素是变化的或者配置文件元素中的至少一个配置文件元素是变化的。例如，多个级别可被配置为使得分辨率、帧率和比特率都是变化的，或者仅媒体的分辨率被改变。所述多个级别可包括更高级别中的更高分辨率、更高帧率或更高比特率，以及更低级别中的更低分辨率、更低帧率或更低比特率。

媒体数据的配置文件改变表示从当前的配置文件到更低级别或更高级别的配置文件的改变。例如，它可以是将媒体的分辨率提高到更高级别或降低到更低级别并维持纵横比的配置文件改变，或者可以是将分辨率、帧率和比特率都提高到更高级别或都降低到更低级别的改变。

媒体配置文件的所述多个级别可被配置为例如如下面表3中所示。假设当前的配置文件具有1280×720的分辨率、20fps的帧率和2Mbps的比特率，则如下执行根据多个级别的配置文件改变。在改变为更高等级的情况下，分辨率、帧率和比特率都增加，并且当前的配置文件被改变为具有1920×1080的分辨率、30fps的帧率和2.5Mbps的比特率的配置文件。在改变为更低级别的情况下，仅比特率降低到1Mbps。

【表3】

分辨率	帧率	比特率
			2704×1520	30fps	4Mbps
1920×1080	30fps	2.5Mbps
			1280×720	20fps	2Mbps
1280×720	20fps	1Mbps

延迟检测单元142即使在媒体的配置文件被改变之后也可持续地检测重放延迟。在这种情况下，作为用于重放延迟检测的参考的第一帧变为已被改变配置文件的媒体数据的第一帧，并且通过重复参照图11描述的延迟检测方法来检测重放延迟。

如果延迟检测单元142即使在配置文件被改变之后也确定媒体重放仍被延迟，则配置文件改变单元145可请求媒体服务设备110发送具有比改变的配置文件的级别更低的级别的配置文件的媒体数据。

相反，如果在配置文件被改变之后由延迟检测单元142检测到的Tdx与Td1之间的差等于或小于参考值并且持续预定参考时间或更久，则可认为媒体重放被流畅地执行。因此，配置文件改变单元145可请求媒体服务设备110发送具有比改变的配置文件的级别更高的级别的配置文件的媒体数据。在这种情况下，参考值可以是最大延迟时间或小于用户设置的值的值，并且参考时间是用于防止配置文件由于暂时噪声而被改变的最小持续时间。

通过第一媒体恢复单元143对具有通过延迟确定处理已经改变或保留的配置文件的视频帧进行解码。在图12的示例性实施例中，第一媒体恢复单元143被配置使得以JavaScript实现解码器，并且在JavaScript解码器中基于逐帧对视频进行解码，其中，JavaScript是可通过web浏览器解析的脚本。解码的视频经由渲染器模块125和画布标签133被显示在web浏览器上。

接下来，将描述由第二媒体恢复单元144执行解码的情况。

接收单元141沿右箭头将视频发送到解包模块。已经在解包模块中被解包的视频被发送到容器创建模块127。

如参照图9所述，当视频不是以容器格式发送时，容器创建模块127收集帧以创建容器。已经通过容器创建模块127的视频在没有由于容器格式引起的兼容性问题的情况下被发送到MSE(均方误差)134和第二媒体恢复单元144。

MSE 134是为了视频流传输重放而使用HTTP下载创建的用于HTML5的JavaScriptAPI。这种由万维网联盟(W3C)标准化的技术能够在游戏机(诸如，Xbox和PlayStation 4(PS4))或Chromecast浏览器上进行流传输重放。

在图12中，第二媒体恢复单元144包括作为嵌入在web浏览器中的解码器的视频标签模块135。视频标签模块135执行解码和渲染，使得视频被显示在web浏览器上。视频标签模块135也可被称为视频标签播放器。

通过使用作为第二媒体恢复单元144的视频标签模块135的解码器，可以以比由于JavaScript的动态语言特性而具有限制性的解码器模块124的性能更好的性能执行解码。也就是说，可实现高分辨率图像和高每秒帧数(fps)的解码。

虽然在图12中示出延迟检测单元142仅被设置在第一媒体恢复单元143中，但是媒体重放设备120可被配置为使得延迟检测单元142还被设置在第二媒体恢复单元144的解码器之前以检测由于第二媒体恢复单元144的解码器引起的重放延迟，并且在检测到重放延迟时通过请求配置文件已被改变的媒体来防止延迟。

图13是示出根据示例性实施例的媒体重放设备120的操作处理的流程图。更具体地讲，图13示出图12的实施例的媒体重放设备120的操作处理。

确定发送到媒体重放设备120的视频是否具有由视频标签支持的编解码格式和高分辨率(超过全高清(FHD))(操作S2100)。如果以上两个条件都满足，则由于适合于使用具有优异性能的视频标签进行解码，因此通过第二媒体恢复单元144执行解码(操作S2200)。在两个条件之一不满足的情况下，该视频具有视频标签不支持的编解码器格式，或者尽管它具有由视频标签支持的编解码器格式但不是高分辨率视频。在这种情况下，通过以JavaScript实现的第一媒体恢复单元143对视频进行解码(操作S2300)。此后，确定在视频重放正在进行时是否发生延迟(操作S2400)。如果没有发生重放延迟，则在不改变配置文件的情况下通过第一媒体恢复单元143持续执行视频解码(操作S2300)。然而，如果确定已经发生重放延迟，则改变配置文件(操作S2500)，并且通过第一媒体恢复单元143执行视频解码(操作S2300)。

图14示出根据示例性实施例的产生以JavaScript实现的脚本模块的处理。参照图14，可通过使用转换器(诸如，Emscripten)转换以传统的C和C++本地代码编写的源以获得可在浏览器中使用的JavaScript代码来实现以JavaScript实现的脚本模块。

当使用诸如Emscripten的转换器时，可以从传统的本地代码获得以JavaScript实现的解码器或容器。因此，具有可降低编解码器依赖性的优点。

由于使用JavaScript代码替代插件，因此不必担心浏览器的支持中断。此外，不需要担心是否根据浏览器使用ActiveX接口或NPAPI接口。也就是说，具有可降低对浏览器的依赖性的优点。

例如，图1中示出的媒体重放设备120可被实现为图15中示出的计算装置400。计算装置400可以是(但不限于)移动手持装置(例如，智能电话、平板计算机等)、膝上型或笔记本计算机、分布式计算机系统、计算网格或服务器。计算装置400可包括经由总线440彼此通信或与其他元件通信的处理器401、内存403和存储器408。总线440可连接到显示器432、至少一个输入装置433和至少一个输出装置434。

所有这些元件可直接或经由一个或多个接口或适配器连接到总线440。总线440连接到各种各样的子系统。总线440可包括存储器总线、存储器控制器、外围总线、本地总线以及它们的组合。

处理器(例如，中央处理器(CPU))401可选地包括作为用于临时存储指令、数据或计算机地址的本地存储的高速缓存存储器402。处理器401执行存储在计算机可读存储介质(诸如，内存403或存储器408)中的指令(或软件模块)。计算机可读存储介质可存储实现特定实施例的软件模块，并且处理器401可执行存储的软件模块。

内存403可包括：随机存取存储器(RAM)404、只读存储器(ROM)405以及它们的组合。此外，具有启动计算装置400所需的基本例程的基本输入/输出系统(BIOS)406(例如，固件)可被包括在存储器403中。

存储器408用于存储操作系统409、可执行文件(EXEC)410、数据411、API 412等。存储器408可以是硬盘驱动器、光盘驱动器、固态驱动器(SSD)等。

计算装置400可包括输入装置433。用户可经由输入装置433将命令和/或信息输入到计算装置400。输入装置433的示例可包括：键盘、鼠标、触摸板、游戏杆、游戏控制器、麦克风、光学扫描仪和相机。输入装置433可经由包括串行端口、并行端口、游戏端口、通用串行总线(USB)等的输入接口423连接到总线440。

在一些实施例中，计算装置400连接到网络430。计算装置400经由网络430连接到其他装置。在这种情况下，网络接口420从网络430接收以一个或多个包的形式的通信数据，并且计算装置400存储接收到的通信数据以用于处理器401的处理。类似地，计算装置400将发送的以一个或多个包的形式的通信数据存储在内存403中，并且网络接口420将通信数据发送到网络430。

网络接口420可包括：网络接口卡、调制解调器等。网络430的示例可包括互联网、广域网(WAN)、局域网(LAN)、电话网络、直接连接通信等，并且可采用有线和/或无线通信方案。

可通过显示器432显示处理器401对软件模块的执行结果。显示器432的示例可包括：液晶显示器(LCD)、有机发光显示器(OLED)、阴极射线管(CRT)和等离子显示器面板(PDP)。显示器432经由视频接口422连接到总线440，并且显示器432与总线440之间的数据传输可由图形控制器421控制。

除了显示器432之外，计算装置400还可包括至少一个输出装置434(诸如，音频扬声器和打印机)。输出装置434经由输出接口424连接到总线440。例如，输出接口424可以是：串行端口、并行端口、游戏端口、USB等。

虽然不限于此，但是示例性实施例可被实施为计算机可读记录介质上的计算机可读代码。计算机可读记录介质是可存储之后可由计算机系统读取的数据的任何数据存储装置。计算机可读记录介质的示例包括：只读存储器(ROM)、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光学数据存储装置。计算机可读记录介质还可被分布在联网的计算机系统，使得以分布式的方式存储并执行计算机可读代码。此外，示例性实施例可被编写为通过计算机可读传输介质(诸如，载波)发送的计算机程序，并且在执行程序的通用或专用数字计算机中被接收并实现。此外，可理解，在示例性实施例中，上述设备和装置的一个或多个单元可包括电路、处理器、微处理器等，并可执行存储在计算机可读介质中的计算机程序。

前述示例性实施例仅仅是示例性的，不将被解释为限制性的。本教导可被容易地应用于其他类型的设备。此外，示例性实施例的描述意图是说明性的，而不限制权利要求的范围，并且很多替代物、修改和改变对于本领域技术人员来说将是清楚的。

Claims (13)

1.一种用于在web浏览器上重放媒体的媒体重放设备，包括：

接收单元，被配置为使用支持web服务的通信协议接收在媒体服务设备中产生的媒体数据；

第一媒体恢复单元，被配置为通过以脚本编写的解码器对接收的媒体数据进行解码，其中，所述脚本被配置为通过web浏览器解析；

渲染器，被配置为执行渲染以显示由解码器解码的媒体数据；

延迟检测单元，被配置为通过将包括在媒体数据中的时间戳与媒体数据到达第一媒体恢复单元的时间进行比较，来检测媒体数据的重放延迟；

配置文件改变单元，被配置为响应于延迟检测单元检测到重放延迟而请求媒体服务设备发送具有改变的配置文件的媒体数据，

其中，延迟检测单元还被配置为：通过将媒体数据的第一帧到达第一媒体恢复单元的时间与第一帧的时间戳之间的第一差和媒体数据的后续帧到达第一媒体恢复单元的时间与所述后续帧的时间戳之间的第二差进行比较，来检测重放延迟。

2.根据权利要求1所述的媒体重放设备，其中，重放延迟包括以下项中的任意一个或任意组合：在媒体数据从媒体服务设备传输到媒体重放设备期间发生的网络延迟、在第一媒体恢复单元的解码处理中发生的解码延迟以及在渲染器的渲染处理中发生的渲染延迟。

3.根据权利要求1所述的媒体重放设备，其中，延迟检测单元还被配置为：基于媒体数据到达第一媒体恢复单元的时间与所述时间戳之间的差值来检测重放延迟。

4.根据权利要求1所述的媒体重放设备，其中，第一帧包括：包括在媒体数据中的第一帧以及具有改变的配置文件的媒体数据的第一帧。

5.根据权利要求4所述的媒体重放设备，其中，延迟检测单元还被配置为：基于对第一差与第二差之间的差是否超过预定时间的确定，来检测重放延迟。

6.根据权利要求4所述的媒体重放设备，其中，延迟检测单元还被配置为：基于第一差与第二差之间的差是否超过5秒，来检测重放延迟。

7.根据权利要求1所述的媒体重放设备，其中，所述改变的配置文件为媒体数据的分辨率、帧率和比特率中的至少一个被改变的配置文件。

8.根据权利要求1所述的媒体重放设备，还包括：第二媒体恢复单元，被配置为通过嵌入在web浏览器中的另一解码器对接收的媒体数据进行解码，

其中，以所述脚本编写的所述解码器以JavaScript编写，并且嵌入在web浏览器中的所述另一解码器为由HTML5支持的视频标签模块。

9.根据权利要求1所述的媒体重放设备，其中，所述改变的配置文件具有配置文件的多个级别之中的比当前配置文件的级别更低的级别。

10.一种用于向媒体重放设备发送媒体数据的媒体服务设备，所述媒体服务设备包括：

模块存储单元，被配置为存储用于在媒体重放设备的web浏览器上重放媒体数据的脚本模块；

模块传输单元，被配置为响应于媒体服务设备与媒体重放设备之间的连接被建立，将脚本模块传输到媒体重放设备；

打包单元，被配置为将媒体数据打包以产生传输包；

web服务器，被配置为建立所述连接并响应于从媒体重放设备接收到请求的配置文件而将传输包发送到媒体重放设备，

其中，脚本模块被配置为在没有插件的情况下在媒体重放设备中对媒体数据进行解码，并检测在媒体数据的重放期间发生的重放延迟，

其中，脚本模块还被配置为：通过将媒体数据的第一帧到达解码模块的时间与第一帧的时间戳之间的第一差和媒体数据的后续帧到达解码模块的时间与所述后续帧的时间戳之间的第二差进行比较，来检测重放延迟。

11.根据权利要求10所述的媒体服务设备，其中，脚本模块以被配置为由web浏览器解析的JavaScript编写。

12.根据权利要求10所述的媒体服务设备，其中，重放延迟包括：在媒体数据从媒体服务设备传输到媒体重放设备期间发生的网络延迟、在媒体重放设备的解码处理中发生的解码延迟以及在媒体重放设备的渲染处理中发生的渲染延迟。

13.根据权利要求10所述的媒体服务设备，其中，脚本模块还被配置为：基于媒体数据到达解码模块的时间与媒体数据的时间戳之间的差值，来检测重放延迟，其中，解码模块用于在没有插件的情况下在媒体重放设备中对媒体数据进行解码。

Images