具体实施方式
现在将参照附图对示例性实施例做出详细参考描述。通过参照下面的示例性实施例的具体实施方式和附图,可更容易地理解本公开的优点和特征以及实现其的方法。然而,本公开可以以很多不同的形式实现,并不应被解释为限于这里阐述的实施例。相反,提供这些实施例,使得本公开将是彻底的和完整的并将本公开的构思完整地传达到本领域技术人员,并且本公开将仅由所附权利要求书限定。相同的数字标号始终表示相同的元件。
如这里使用的术语“流传输”表示播放源于远程装置的媒体(例如,音频、视频等)的方法,其中,在该方法中,可在没有必须首先将全部内容下载和存储在本地存储装置中的情况下,仅在部分下载(例如,缓冲)媒体之后开始回放。如这里使用的术语“直播流传输”(还被称为“对媒体进行直播”)表示本地装置在网络浏览器或应用上播放在远程装置实时捕获的媒体的方法。例如,诸如体育赛事、音乐会、演出和新闻广播的直播事件可以是在图像和/或声音正被捕获的同时被直播流传输。直播流传输并不一定指示当事件发生时被流传输,而可包括时间延迟(例如,一些秒)。如这里使用的术语“记录流传输”表示本地装置播放预先记录和存储在远程装置中的流传输媒体(例如,图像、音频和视频等)的方法。例如,视频点播(VOD)服务可允许本地装置在网络浏览器上播放存储在远程服务器中的电影。记录流传输(还被称为非直播流传输或记录媒体流传输)与直播流传输的不同之处在于,在播放开始之前,正播放的媒体已经被记录和存储。
除非另有定义,否则这里使用的所有术语(包括技术术语和科学术语)具有和本发明所属领域的普通技术人员普遍理解的含义相同的含义。还将理解,除非在这里明确地定义,否则术语(诸如在通用字典中定义的术语)应该被解释为具有与它们在相关领域的语境中的含义一致的含义,而不将被解释为理想化或过于形式化的意义。这里使用的术语仅是出于描述特定实施例的目的,而不意图限制。如这里所使用,除非上下文清楚地另有指示,否则单数形式也意图包括复数形式,反之亦然。
还将理解,当在本说明书中使用术语“包括”时,说明存在叙述的特征、整体、步骤、操作、元件和/或组件,但不排除存在或添加一个或多个其他特征、整体、步骤、操作、元件、组件和/或它们的组。这里公开的各种单元和模块可使用软件、硬件或二者的组合被实现。
以下,将参照附图更加详细地描述本公开。
图1A至图1C是用于说明服务器侧上的传统媒体数据传输协议的示例性示图。
图1A是用于说明渐进式下载方法的示例性示图。在渐进式下载方法中,使用超文本传输协议(HTTP)将媒体数据101从服务器100传输到客户机109。在这种情况下,即使在媒体数据101的传输完成之前,客户机109的用户也可基于位于媒体数据101的头中的元数据来播放媒体数据101。
渐进式下载方法的优点在于:这种方法可容易实现,并且仅通过将媒体数据101上传到服务器100然后向客户机109通知上传媒体数据101的地址(诸如,统一资源定位符(URT))可以进行回放。
然而,作为下载全部文件的方法的渐进式下载方法的缺点在于:这种方法在安全方面不足。此外,这种方法具有一个缺点在于:因为当数据被客户机109下载时这种方法会在网络中产生相同量的流传输量,网络可被保持繁忙。此外,还有一个缺点在于:一旦下载开始,不能改变媒体数据101的品质。也就是说,由于虽然需要但根据客户机109的资源或网络环境难以改变媒体数据101的品质,因此在难以播放高品质媒体数据的网络环境中的客户机109中,可发生缓冲,这不适用于直播流传输。
图1B是用于说明RTSP/RTP流传输方法的示例性示图。RTSP/RTP流传输方法将以不同品质(码率)编码的多个(例如,三个或四个)视频文件存储在服务器100中,并提供允许客户机109在流传输的过程期间改变品质的功能。
在图1B的示例中,低品质的媒体数据103、中品质的媒体数据105和高品质的媒体数据107被存储在服务器100中。
在RTSP/RTP流传输方法中,并不是传输全部媒体数据,而是仅传输客户机109想要观看的部分的一些帧。也就是说,如果观看者发现并点击将观看的场景,则从对应部分的帧开始播放媒体,并自动删除过去的帧,这从安全的角度看是期望的。
图1C是示出自适应HTTP流传输方法的示例性示图。参照图1C,可看出,与RTSP流传输方法相似,自适应HTTP流传输方法将三条媒体数据103、105和107存储在服务器100中。然而,也可存储少于三条或多于三条的媒体数据。
在自适应HTTP流传输方法中,存储在服务器中的媒体数据103、105和107在被传输之前被划分为更小的片段。客户机109将片段连成连续流。也就是说,服务器100按秒的单元对媒体数据103、105和107分片。客户机109接收分片的媒体数据103、105和107,并将他们组合成连续流以用于回方。
与自适应HTTP流传输方法相关的标准包括MPEG-DASH(国际标准化组织和国际电工委员会(ISO/IEC)23009-1:2012:HTTP上的动态自适应流传输)。在MPEG-DASH方案的情况下,使用HTTP通信传输媒体数据。虽然HTTP具有不必实现单独的流传输逻辑的优点,但是由于HTTP通信的无状态特性,所以它不适用于实时媒体传输。单独实现用于控制媒体的回放(诸如,播放、前进、倒回、快进和快退等)所需的协议也是必须的。
由于MPEG-DASH方案在服务器100中使用通过处理与一些秒对应的帧而获得的容器,在容器中载入媒体会花费时间。因此,MPEG-DASH方案具有产生不可避免的一些秒的延迟的缺点。尤其,在实时监控中,该延迟可能是缺点。
此外,MPEG-DASH方案可仅使用客户机109的网络浏览器支持的编解码器来播放媒体。也就是说,由于MPEG-DASH方案使用视频标签,仅视频标签支持的编解码器被使用,这产生高度依赖编解码器的缺点。
另一方面,参照图1B描述的RTSP/RTP方案根据哪个数据在WebSocket上传输而使用RTSP/RTP协议,并使用基于HTML5的WebSocket协议而与HTML5兼容。
图2至图4是示出在用于服务器与客户机之间的通信的WebSocket上传输RTSP/RTP协议的示图。
图2是示出针对装置之间的通信而分层次地定义的TCP/IP 4-层模型的示图。四个层包括网络接口层21、互联网(Internet)层22、传输层23和应用层24。由于在WebSocket上传输的RTSP/RTP协议中的WebSocket连接位于服务器100与客户机109之间的传输层23的连接的顶端,所以为了使用WebSocket连接,在服务器100与客户机109之间必须首先建立TCP传输连接。一旦例如通过3路握手(handshake)处理在服务器100与客户机109之间建立了WebSocket连接,WebSocket通信通过传输WebSocket包而被执行。以下,将参照图3描述WebSocket连接,将参照图4描述WebSocket包。
图3示出通过WebSocket连接来发送和接收数据的处理的示例。该WebSocket连接可根据作为HTML5标准的一部分的WebSocket协议被建立。具体地讲,由于WebSocket连接支持持续的双向通信,所以在没有被断开的情况下,数据可在客户机109与服务器100之间被持续发送和接收。如这里参照WebSocket所使用,“持续”发送和接收数据可指示:每次传输数据包时,不需要建立和/或终止连接或通信通道。相反,一旦WebSocket连接或通信通道建立,客户机109和服务器100就可连续或间歇地交换WebSocket数据,直到WebSocket连接终止为止。换言之,数据的持续传输可不一定表明没有数据传输的暂停或中断。
参照图3,客户机109将TCP/IP连接请求消息发送到服务器100,服务器100接受该请求并将TCP响应消息(SYN-ACK)发送到客户机109,从而建立TCP/IP通信。TCP传输连接可由一对本地TCP套接字(socket)和远程TCP套接字形成。每个TCP套接字至少由标识符(诸如,端口号和网络协议(IP)地址)限定。当然,在他们之间建立基于用户数据报协议/IP(UDP/IP)的连接而非基于TCP/IP连接也是可能的。
然后,当通过客户机109与服务器100之间的握手处理建立了WebSocket连接时,他们之间的持续数据发送/接收可随后被执行。也就是说,客户机109以发送WebSocket包(socket.send)的形式将媒体流传输请求发送到服务器100,服务器100以响应WebSocket包(socket.onMessage)形式将媒体流发送到客户机109。在他们之间可持续执行该处理,直到媒体流传输被完成或终止为止。
图4是示出通过网络接口21与服务器通信的通信包的结构的示图。当RTP头44被添加到与数据45对应的RTP净负荷(payload)时,他们变成RTP包。RTP包与WebSocket净负荷等同,WebSocket头43被添加到RTP包而成为WebSocket包。WebSocket包与TCP净负荷等同,TCP头42被添加到WebSocket包而变成TCP包。最终,TCP包与IP净负荷等同,IP头41被添加到TCP包,从而产生通信包(也就是说,IP包)。在服务器100和客户机109二者中执行产生IP包的处理和去除每个头文件的处理。
由于客户机109与服务器100之间的通信通过基于HTML5的WebSocket协议被执行,所以负责RTSP/RTP发送/接收控制的模块、负责解码和渲染的模块等可通过以HTML5解析的脚本语言实现。根据示例性实施例的一方面,RTSP/RTP发送/接收控制以及解码和渲染可通过JavaScript代码实现。因此,在不需要如传统方式所进行的单独安装插件(诸如ActiveX或NPAPI)情况下,可在网络浏览器中实现使用RTSP/RTP协议的媒体流传输。
目前为止已经描述了在WebSocke上传输的RTSP/RTP协议。以下,将参照图5至图14描述用于在根据网络浏览器中的播放方法改变逻辑的同时使用上述协议播放在远程地方捕获的媒体的设备和方法。
图5示出用于网络浏览器210中的媒体回放的整个系统。在该系统中,由媒体服务设备110捕获的媒体通过网络430被传输到媒体流传输设备120(还被称为媒体回放设备或用户装置)。
媒体服务设备110包括适用于将计算服务提供给一个或多个媒体播放设备的计算或处理装置。例如,媒体服务设备110包括能产生或存储媒体流并将媒体流传输到用户装置的装置(诸如,网络相机、网络硬盘录像机(NVR)和数字硬盘录像机(DVR))。
媒体流传输设备120包括适用于通过网络430与媒体服务设备110或其他计算用户装置交互的计算或处理装置。例如,媒体流传输设备120可以是台式计算机、移动电话或智能电话、个人数字助理(PDA)、膝上型计算机、机顶盒、数字媒体播放器、媒体加密锁或平板计算机。
媒体服务设备110和媒体流传输设备120使用如上所述的在WebSocket上传输的RTSP/RTP协议彼此通信。当在媒体服务设备110与媒体流传输设备120之间建立了WebSocket连接时,他们之间的持续数据发送/接收可随后被执行。
图6示出媒体服务设备110的配置的实施例。在一个实施例中,媒体服务设备110包括实时摄像机111、编码器112、封包单元113、网络服务器114、播放模块存储单元115、播放模块传输单元116和控制单元117。
实时摄像机111是用于实时捕获媒体的工具,并且这种捕获包括执行视频捕获和音频记录二者的情况和仅执行视频捕获的情况。
编码器112被配置为对由实时摄像机111捕获的媒体进行压缩和编码。不一定使用嵌入在网络浏览器中的解码器所支持的特定编解码器来执行编码器112的编码,而是可使用任何编解码器来执行编码器112的编码。
封包单元113对编码的媒体数据进行封包以产生传输包。封包意味着将媒体数据划分成合适的长度以促进通过网络430的传输或者如果媒体数据是短的则将控制信息(诸如,接收地址)共同地分配给合适的长度的每个数据。在这种情况下,控制信息位移包的头文件中。
封包单元113可根据由媒体流传输设备120请求的流传输模式、由媒体流传输设备120播放的媒体的配置文件(profile)元件和应用于媒体的编解码器,来执行媒体数据的封包。配置文件元件(例如,属性)包括分辨率、帧率等。
当媒体流传输设备120请求直播流传输作为流传输模式时,封包单元113可针对媒体的每一帧产生传输包。在直播流传输的情况下,媒体流传输设备120通过被实现为可由网络浏览器解析的脚本的解码器来在逐帧的基础上执行解码,从而能够在没有初始延迟的情况下播放。在这种情况下,可由网络浏览器解析的脚本可以是JavaScript。
当媒体流传输设备120请求记录流传输作为流传输模式时,封包单元113可产生基于逐帧的传输包或容器格式的传输包,其中,每个容器包括多个视频帧。传输包的格式可根据媒体流传输设备120的媒体的配置文件元件和应用于媒体的编解码器而被确定。
更具体地,响应于回放请求,如果媒体的配置文件元件大于阈值,封包单元113可产生容器格式的传输包;如果媒体的配置文件元件小于阈值,封包单元113可产生基于逐帧的传输包。在这种情况下,阈值可以是用于确定媒体流传输设备120的回放性能的特定参考值。例如,如果媒体配置文件元件是分辨率,则阈值可被设置为用于确定媒体流传输设备120的解码器是否平滑执行解码的特定分辨率值。阈值可根据计算装置在媒体流传输设备120中的媒体回放期间的性能而被调节。
此外,响应于回放请求,如果应用于媒体的编解码器格式被嵌入在媒体流传输设备120的网络浏览器中的解码器支持,则封包单元113可产生容器格式的传输包;如果不支持,则封包单元113可产生基于逐帧的传输包。因此,在媒体通过嵌入在网络浏览器中的解码器不支持的编解码器被编码的情况下,使用以可由媒体流传输设备120的网络浏览器解析的脚本编写的解码器来基于逐帧执行解码。
网络服务器114建立与媒体流传输设备120之间的通信会话。也就是说,通过媒体服务设备110的网络服务器114与媒体流传输设备120之间的握手处理来在他们之间建立WebSocket连接。此后,根据媒体流传输设备120的请求,通过网络服务器114传输由封包单元113产生的传输包。
播放模块存储单元115是用于存储在媒体流传输设备120中播放媒体所需的脚本模块的模块。在没有安装插件或单独的应用程序的情况下,脚本模块使用可由网络浏览器解析的脚本编写的代码,来允许媒体流传输设备120在处于HTML5环境的网络浏览器中播放媒体。根据示例性实施例的一方面,脚本模块可以是以JavaScript编写的代码。稍后将参照图8和图9描述脚本模块。
播放模块传输单元116是用于将存储在播放存储模块单元115中的脚本模块传输到媒体流传输设备120的模块。响应于媒体流传输设备120通过网络浏览器连接到媒体服务设备110的情况,播放模块传输单元116传输脚本模块。
控制单元117是用于控制媒体服务设备110中的其他配置模块的模块。例如,当媒体流传输设备120通过网络430连接到网络服务器114时,存储在播放模块存储单元115中的脚本模块通过播放模块传输单元116被传输到媒体流传输设备120。在这种情况下,控制单元117向各个模块发送信号或从各个模块接收信号以控制操作被平滑执行。
图7示出媒体服务设备110的配置的另一示例性实施例。图6的媒体服务设备110表示用于使用实时摄像机111传输实时直播视频的示例性实施例,图7的媒体服务设备110表示用于传输存储在媒体存储单元118中的示例性实施例。
媒体存储单元118包括网络视频录像机(NVR)和个人视频录像机(PVR)。然而,将结合网络视频录像机描述图7的示例性实施例。媒体存储单元118从相机或服务器接收媒体数据,并压缩(例如,编码、加密)和存储接收的媒体数据。当存在来自媒体流传输设备120的针对存储的媒体数据的传输的请求时,媒体服务设备110在封包单元113中对存储在媒体存储单元118中的媒体数据进行封包,并通过网络服务器114传输封包数据。在图7的示例性实施例中,已经参照图6的示例性实施例描述了媒体服务设备110的配置模块中的封包单元113、网络服务器114、播放模块存储单元115、播放模块传输单元116和控制单元117。
图8示出播放模块存储单元115的脚本模块的示例性实施例。在图8的示例性实施例中,脚本模块包括RTSP/RTP客户机模块121、解包模块122、解码器模块124和渲染器模块124。在图8的示例性实施例中,以JavaScript实现脚本模块。
RTSP/RTP客户机模块121被配置为支持与媒体服务设备110的RTSP/RTP通信。通常,在没有插件的情况下,在网络浏览器上根据RTSP/RTP协议处理媒体是不可能的。当使用RTSP/RTP客户机模块121时,即使网络浏览器使用HTTP方案,也可以可靠地接收通过RTSP/RTP协议发送的媒体数据也是不可能的。
解包模块122对从媒体服务设备110传输的包进行解包。解包是封包的逆处理。换言之,封包表示将媒体数据划分为具有合适长度以形成包的较小片段的处理,而解包表示通过将片段(即,包)再次组合将媒体数据恢复到封包之前的状态的处理。
解码器模块123对编码的媒体数据进行解压缩(例如,解码、解密)。与脚本模块的其他模块类似,可以以JavaScript实现解码器模块123。由于以JavaScript实现解码器模块123,所以不同于嵌入在网络浏览器中的解码器,以更多种类的编解码器而不是通过支持的编解码的受限集合来执行解码是可能的。执行基于逐帧的解码也是可能的。
当以JavaScript实现解码器模块123时,例如,可用下面的示例性代码表示它。
渲染器模块124被配置为对视频进行渲染并在输出装置(诸如,显示器等)上显示视频。渲染器模块12使用网页图形库(WebGL)将YUV格式的视频转换为RGB格式的视频。WebGL是通过JavaScript可用并允许3D图形接口的创建的基于网页的图像库。
由于图8的脚本模块使用JavaScript解码器,所以在不受视频的编解码器格式的限制情况下,执行基于逐帧的解码是可能的。然而,解码性能可由于JavaScript的动态特性而在高分辨率视频中快速劣化。因此,图8的脚本模块适用于在直播流传输以及没有初始延迟的回放的情况下使用嵌入在网络浏览器中的解码器不支持的编解码器的编码的视频以及具有不超出阈值的配置文件元件的视频的回放。
图9示出播放模块存储单元115的脚本模块的另一示例性实施例。在图9的示例实施例中,脚本模块包括RTSP/RTP客户机模块121、解包模块122和容器创建模块127。此外,在图9的示例实施例中,以JavaScript实现脚本模块。已经参照图8描述了RTSP/RTP客户机模块121和解包模块122。
更加详细地参照图9,与图8中示出的示例不同在于,图9的脚本模块包括以JavaScript实现的容器创建模块127。容器创建模块127被配置为当在解包的媒体数据在解包模块122中没有基于容器被封包时通过收集帧来产生容器。
当视频标签被用作嵌入在网络浏览器中的解码器的示例时,媒体回放性能高于以JavaScript实现的解码器的性能。然而,在传统MPEG-DASH的情况下,由于传输单元创建容器并在媒体被载入容器中的同时传输媒体,所以容器创建逻辑必须被实现在传输单元中。
如果先前安装的传输单元不提供创建支持MPEG-DASH的容器的功能,则媒体必须通过具有容器创建功能的服务器被单独传输。因此,通过将容器创建模块127移至媒体流传输设备120,可以在不修改现有装备的情况下解决兼容性问题。
当使用图9的脚本模块时,即使在WebSocket上传输的RTSP/RTP协议被使用,视频标签也可在没有兼容性问题的情况下被用作嵌入在媒体流传输设备120中的网络浏览器中的解码器的示例。通常,图8的方法还可被用于记录媒体流传输。然而,以JavaScript实现的解码器可由于动态语言(诸如,JavaScript)的限制而性能差。此外,当回放被执行时,实时属性由于它的特性而不被要求。也就是说,执行基于逐帧的解码不太重要。当使用视频标签时,初始延迟可由于容器格式而发生,但使用高帧频(FPS)和高分辨率视频高性能地执行解码是可能的。因此,图9的脚本模块适用于当媒体的配置文件元件超出阈值和当以视频标签支持的格式编码媒体时的回放。
图10是示出用于使用JavaScript的直播流传输或记录流传输的媒体流传输设备120的示例性示图,其中,JavaScript是可在网络浏览器中解析的脚本代码的示例。在图10的示例性实施例中,将描述用于播放使用H.264和H.265的编解码器编码的视频的配置。
图10中的RTSP/RTP客户机模块121、H.264解包模块122a、H.265解包模块122b、H.264解码器模块123a、H.265解码器模块123b和渲染器模块124是被配置为从媒体服务设备110的播放模块传输单元116接收图8的示例性实施例的客户机模块的模块。
WebSocket客户机230和RTSP/RTP客户机模块121构成接收单元。WebSocket客户机230是用于建立与媒体服务设备110的网络服务器114的WebSocket连接的模块。媒体流传输设备120和媒体服务设备110通过WebSocket客户机230与网络服务器114之间的握手而分别发送和接收传输包。
如参照图8的示例性实施例所述,RTSP/RTP客户机模块121被配置为支持用户的网络浏览器210的RTSP/RTP通信。因此,在没有安装单独的插件的情况下,用户可使用RTSP/RTP协议通过HTML5环境中的网络浏览器210播放媒体。
已经通过WebSocket客户机230和RTSP/RTP客户机模块121的传输包由第一媒体恢复单元130解码。在图9的示例性实施例中,由于以H.264或H.265编码的视频被作为目标,所以解包模块122包括H.264解包模块122a和H.265解包模块122b,解码器模块123包括H.264解码器模块123a和H.265解码器模块123b。以H.264编码的视频通过H.264解包模块122a和H.264解码器模块123a被解包和解码。以H.265编码的视频通过H.265解包模块122b和H.265解码器模块123b被解包和解码。
在图10的示例性实施例中,仅示出H.264编解码器和H.265编解码器。然而,通过另外实现针对每个另外的编解码器以JavaScript实现的解包模块和解码器模块,各种其他编解码器也可被支持。
由于在第一媒体恢复单元130中以JavaScript实现解码器模块,所以可以通过由视频标签不支持的H.265编码器所编码的视频进行解码,其中,视频标签是嵌入在当前网络浏览器中的解码器的示例。
此外,基于逐帧对视频执行H.264JavaScript解码器和H.265JavaScript解码器中的解码。通过逐帧处理方法,用户可在没有初始延迟的情况下以直播流传输模式播放视频。
与编解码器一致的解包和解码的视频通过渲染器模块124和canvas标签240被输出到网络浏览器。与输出单元对应的canvas标签240是HTML5的允许2D形状和位图图像被动态渲染的元件。也就是说,canvas标签240可被视为网络浏览器上的绘画程序(例如,渲染器)。由于它是大多数最新版本的网络浏览器支持的功能,所以媒体可由JavaScript实现的解码器基于逐帧被处理,并通过使用canvas标签240被显示在网络浏览器上。
通过图10的示例性实施例,在不依赖插件的情况下可以对由媒体服务设备110捕获的媒体进行实时流传输并播放媒体。因此,可以与网络浏览器开发商停止支持插件中的趋势一致地,提供在不担心与插件的使用相关联的安全问题的情况下实时播放媒体的环境。
此外,网络服务器114以在通过WebSocket客户机230和RTSP/RTP客户机模块121未分离的WebSocket上传输的RTSP/RTP协议来传输媒体数据。媒体流传输设备120基于逐帧处理使用JavaScript传输的媒体数据。因此,延迟时间可被减少为几十毫秒。
此外,由于以JavaScript实现解码器,所以它不要求单独的容器,并可支持另外的编解码器(诸如,H.265)。因此,在MPEG-DASH方案上提高了编解码器支持的可扩展性。
图11是示出用于使用视频标签260的记录流传输的媒体流传输设备120的示例性示图,其中,视频标签260是嵌入在网络浏览器中的解码器的实施例。在图11的实施例中,描述了在记录流传输模式下播放使用H.264编解码编码的视频的方法。此外,视频标签260被用作嵌入在网络浏览器中的解码器的示例。
在图11中,RTSP/RTP客户机模块121、解包模块122和容器创建模块127是被配置为从媒体服务设备110的播放模块传输单元116接收如图9所示的脚本模块的模块。
WebSocket客户机230和RTSP/RTP客户机模块121构成接收单元。WebSocket客户机230是与在图10的示例性实施例描述的模块相同的模块。RTSP/RTP客户机模块121被配置为支持用户的网络浏览器210的RTSP/RTP通信。因此,在没有安装单独的插件的情况下,用户可使用RTSP/RTP协议通过HTML5环境中的网络浏览器来在记录流传输模式下播放媒体。
已经通过接收单元的视频由第二媒体恢复单元140解码。视频由解包模块122解包,如果解包的视频不是以容器模式被传递,则容器创建模块127被配置为通过收集帧来创建容器。在没有由于容器格式的兼容性问题的情况下,已经通过容器创建模块127的视频被传递到媒体源扩展(MSE)250和视频标签260。
MSE 250是针对HTML5的JavaScript API,它是被创建用于使用HTTP下载的视频流传输回放。由万联网联盟(W3C)标准化的该技术使游戏机(诸如,Xbox和游戏机4(PS4))或谷歌电视棒媒体播放器上的流传输回放成为可能。
第二媒体恢复单元140的视频标签260执行解码和渲染,使得在屏幕上显示视频。由于在当前视频标签中支持H.264编解码器,所以使用H.264编解码编码的视频以及作为示例被描述。然而,针对其他视频标签所支持的编解码器和如果在将来扩展视频标签所支持的编解码器格式而扩展的编解码器,通过图11的示例性实施例解码和渲染视频也是可能的。
在图11的媒体流传输设备中,为了如在MPEG-DASH方案中一样地提供各种功能的媒体回放环境,通过在媒体流传输设备120的网络浏览器210中安装将由媒体服务设备110处理的容器功能,以与传统MPEG-DASH方案类似的方式通过HTML5的视频标签播放视频是可能的。
目前为止,已经参照图10和图11描述了媒体流传输设备的两个示例性实施例。图10的媒体流传输设备适用于当使用视频标签不支持的编解码器来编码媒体时和当媒体配置文件元件由于JavaScript的动态特性而未超出阈值以及没有初始延迟的直播流传输时的播放方法。图11的媒体流传输设备适用于考虑到视频标签的优异性能的当使用视频标签支持的编解码来编码媒体时和当媒体配置文件元件超出阈值时的播放方法。因此,当图10或图11的媒体流传输设备被选择性使用时,播放适用于直播流传输或记录流传输模式的媒体是可能的。
目前为止,已经参照图10和图11描述了以适用于直播流传输或记录流传输的方式在媒体流传输设备120中播放视频的方法。然而,使用JavaScript的播放方法可以以相同的方式被应用到音频。
图12是示出根据示例性实施例的在媒体流传输设备120中使用JavaScript实现播放音频的方法的处理的示例性示图。
图12的左侧是用于说明用于音频的如在图9的示例中一样的直播流传输的功能,图12的右侧是用于说明用于在图11的示例中一样的回放的功能。
同样在图12中,与图10类似,根据音频编解码器,可使用G.711编解码器或G.726编解码器来实时对音频进行解码。当然,除了图12中示出的编解码器之外,可以以JavaScript实现用于解码另一编解码器的解码器。实时解码的音频通过用作输出单元的网络音频API331被输出。
同样在图12中,与图11类似,存储的音频可在使用用于缓冲管理的MSE 350和使用作为嵌入在网络浏览器中的解码器音频标签360根据编解码器被解码之后被输出。
直到现在,已经参照图10至图12描述了根据直播流传输和记录流传输的播放方法。通过经由用户接口的用户输入来确定媒体数据的播放方法。用户接口可被实现为图形用户接口(GUI),并可通过远程连接操作。
图13是说明根据示例性实施例的产生以JavaScript实现的脚本模块的处理的示例性处理。
参照图13,以JavaScript实现的脚本模块可通过使用转换器(诸如,Emscripten)转换以传统C和C++本机代码(native code)编写的源来获得可用在浏览器中的JavaScript代码而被实现。
当使用转换器(诸如,Emscripten)时,从传统本机代码获得以JavaScript实现的解码器或容器是可能的。因此,可获得减少编解码器依赖性的优点。
由于代替插件而使用JavaScript代码,所以没必要担心当转变到新技术时的浏览器的传统支持。此外,没有必要担心根据浏览器是使用ActiveX接口还是NPAPI接口。也就是说,浏览器依赖性可被减少。
图14A和14B是根据示例性实施例的分别使用JavaScript的直播流传输方法和记录流传输的播放方法的流传输程图。JavaScript解码器被用在图14A中,视频标签解码器被用在图14B中。
参照图14A,媒体流传输设备120通过网络浏览器210连接到媒体服务设备110(S1100)。媒体流传输设备120从媒体服务设备110接收存储在播放模块存储单元115中的脚本模块(S1200)。正在实时捕获的媒体数据被媒体流传输设备120使用WebSocket来接收(S1300),并使用以JavaScript实现的解码器被解码(S1400)。可在用户的网络浏览器210中通过HTML5的渲染器和canvas标签240实时播放解码的媒体(S1500)。
参照图14B,媒体流传输设备120通过网络浏览器210连接到媒体服务设备110(S1100)。媒体流传输设备120从媒体服务设备110接收存储在播放模块存储单元115中的脚本模块(S1200)。预先记录和存储在媒体服务设备110中的媒体数据被媒体流传输设备120使用WebSocket来接收(S1300)。如果视频不是容器格式,则使用JavaScript创建容器(S1600)。媒体数据可通过HTML5的视频标签260被解码(S1700),并在媒体流传输设备120的网络浏览器210中被播放(S1800)。
在上面的描述中,网络浏览器不仅包括安装在台式计算机或移动装置上的众所周知的浏览器(诸如,Google Chrome、Microsoft Explorer、Microsoft Edge、MozillaFirefox和Apple Safari),还包括通过使用API或网络浏览器的资源创建的软件应用。
图5中示出的媒体流传输设备120可被实现为例如图15中示出的计算装置400。计算装置400可以是(但不限于)移动手持设备(例如,智能电话,平板计算机等)、膝上型或笔记本计算机、分布式计算机系统、计算网格或服务器等。计算装置400可包括通过总线440彼此通信或与其他元件通信的处理器401、存储器403和存储装置408。总线440可连接到显示器432、至少一个输入装置433和至少一个输出装置434。
所有这些元件可直接或者通过一个或多个接口或适配器连接到总线440。总线440连接到各种子系统。总线440可包括存储器总线、存储器控制器、外围总线、本地总线和他们的组合。
处理器(例如,中央处理器(CPU))401可选地包括高速缓存存储器402,高速缓存存储器402是用于暂时存储指令、数据或计算机地址的本地存储装置。处理器401执行存储在计算机可读存储介质(诸如,存储器403或存储装置408)中的指令(或软件模块)。计算机可读存储介质可存储实现特定实施例的软件模块,并且处理器401可执行存储的软件模块。
存储器403可包括随机存取存储器(RAM)404,只读存储器(ROM)405或他们的组合。此外,具有用于启动计算装置400所需的基本例程的基本输入/输出系统(BIOS)(例如,固件)可包括在存储器403中。
存储装置408可被用于存储操作系统409、可执行文件(EXEC)410、数据411、API412等。存储装置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通过输出接口424连接到总线440。例如,输出接口424可以是串行端口、并行端口、游戏端口、USB等。
根据示例性实施例,由如图6至图13所示的块表示的组件、元件、模块或单元中的至少一个可被实现为各种数量的执行上述各自功能的硬件、软件和/或固件结构。例如,这些组件、元件、模块或单元中的至少一个可使用直接电路结构(诸如,可通过一个或多个微处理器或其他控制设备的控制而执行各自功能的存储器、处理器、逻辑电路、查找表等)。此外,这些组件、元件、模块或单元中的至少一个可由包括用于执行特定逻辑功能的一个或多个可执行指令的模块、程序或部分代码具体实现,并由一个或多个微处理器或其他控制设备执行。这些组件、元件、模块或单元中的至少一个还可包括处理器(诸如,执行各自功能的CPU)、处理器等,或由处理器(诸如,执行各自功能的CPU)、微处理器等实现。这些组件、元件、模块或单元中的两个或更多个可被组合成单个组件、元件、模块或单元,其中,单个组件、元件、模块或单元执行组合的两个或更多个组件、元件、模块或单元的全部操作或功能。这些组件、元件、模块或单元中的至少一个的至少一部分功能可由这些组件、元件、模块或单元中的另一个执行。此外,虽然未在上面的块示图中示出总线,但是可通过总线执行组件、元件、模块或单元之间的通信。可以以在一个或多个处理器上执行的算法实现上面示例性实施例的功能方面。此外,由块或处理步骤表示的组件、元件、模块或单元可采用任意数量的用于电子配置、信号处理和/或控制、数据处理等的相关领域技术。
上述方法或算法的操作或步骤可被实现为计算机可读记录介质上或将通过传输介质传输的计算机可读代码,计算机可读记录介质是可存储之后由计算机系统读取的数据的任何数据存储装置。计算机可读记录介质的示例包括(但不限于)ROM、RAM、光盘ROM(CD-ROM)、数字通用光盘(DVD)、磁性软盘、磁带和光学数据存储装置。传输介质可包括通过互联网或各种类型的通信通道传输的载波。计算机可读记录介质还可分布在联网计算机系统上,使得计算机可读代码以分布式方式被存储和执行。
本领域技术人员将理解,在本质上不脱离本公开的原理的情况下,可对示例性实施例做出很多改变和修改。因此,公开的示例性实施例仅被用于描述性含义,而不是出于限制的目的。