一种在浏览器内播放媒体流的方法
发明领域
本发明主要涉及媒体流和下载媒体内容到在客户端上运行的浏览器应用。它进一步涉及在逐段基础上下载的媒体内容的播放。
发明背景
当用户访问包含媒体,例如音频、视频或两者兼有的网页时,在浏览器应用程序的浏览器窗口中的视频显示或音频播放器被激活。媒体本身在服务器上或者互联网上内容分发网络上的某处或者任何其它网络作为一个媒体项是可获得的。为了在媒体完全下载之前允许用户开始观看或收听,媒体可以从服务器中以多个段的形式被请求并且每个段可独立的从服务器上下载。只要第一个媒体段完成下载浏览器应用程序就可以开始呈现或播放媒体项目。在这样做的时候,下一段的媒体被下载。
这种下载方式允许在媒体项目完全下载之前呈现一个媒体项目。这导致媒体项目下载的开始和它的实际重放之间有一个小的延迟。此外,在媒体项目结束之前停止或暂停时,在下载也被停止,因此,只有所需要的视频数据被下载节约网络通信量和下载配额。
除了媒体段,服务器上也有有关媒体段在服务器上的位置和它们各自的特定时间的可用信息。该信息可以被包括在一个单一的或通常被称为清单文件的多个文件中。在呈现媒体之前,浏览器应用程序首先检索该清单文件,并选择媒体段下载。
由苹果公司开发的HTTP实时流媒体(HLS)是一种协议,描述这样一种方式下载媒体项目,即,渐进式下载。在支持HLS的客户端应用,客户端检索含有链接到一个视频项目的所有的视频段的一个或多个清单文件。每个视频项目可能有数个版本,每个版本涉及一个不同的质量和/或分辨率。当下载媒体段时,客户端可以选择何种质量或者分辨率的媒体块应基于存在于清单文件之一中的列表进行编码。由客户端选择的质量和/或分辨率的选择可取决于几个因素,如屏幕分辨率、带宽限制或用户输入和/或偏好。在HLS中,视频块是根据MPEG-TS协议被编码和作为独立的文件下载的。因此,视频产品是MPEG-TS编码的视频片段的继承。播放视频期间,客户端会下载一个或一个以上的下一个片段,因此,支持渐进式下载。
HLS更普遍称为HTTP的自适应流(HAS)协议,因为它允许流媒体内容的自适应方式,即质量和分辨率可以在流中进行调整。对于片段和清单的下载,HTTPGET请求被使用。其它HAS协议,例如微软平滑流(MSS)、HTTP动态流(HDS)由Adobe和动态自适应流通过HTTP由3GPP标准(DASH)定义。
HAS协议的一个缺点是,它们都不是被HTML5标准原生的支持。HTML5标准支持单一的媒体元素的重放而无需指定的视频格式。这样一来,HTML5的实现兼容的浏览器提供标准不支持通过链接到一个清单文件或媒体片段播放的HAS媒体项目,例如MPEG-TS视频片段。因此,要播放HAS视频项目,需要浏览器插件或HAS功能作为一个额外的特征必须被实现。这样的插件或额外的功能对于每一个浏览器应用程序需要被特别开发。通常只有几个浏览器应用程序具有这样的浏览器插件或功能可用于特定的HAS协议。
因此,本发明的目的是提供一种克服了上述缺点的用于在浏览器应用程序中播放有多个媒体片段的媒体项目的方法。
发明概述
这是通过根据权利要求1所述方法实现。
一种内容分发网络或CDN的范围可以从一个单一的文件服务器到位于在因特网上的多个数据中心的一个大的分布式系统的服务器。这些服务器可接着进一步包括缓存服务器和代理服务器以保证从CDN到浏览器应用程序快速、低延迟输送。该媒体段驻留在单个服务器上因此没有必要的。媒体段是媒体的一部分。各部分覆盖媒体的一段时间间隔。这样的部分可以是,例如,是一个MPEG-TS视频段或MP4音频或视频文件。浏览器应用程序中进行播放的媒体可以包括音频、视频或两者建有,并且因此可以在浏览器应用程序的音频或视频播放器中播放。由于方法是在浏览器应用程序中执行的,第一和第二媒体文件可以暂时驻留,高速缓存或随机存取(RAM)的存储器使得它们只对浏览器应用程序本身是可用的,保证快速和低延迟访问。
这是一个优点,即音频和/或视频数据有效载荷被直接用在第一和第二文件的结构,因此,不需要对在浏览器应用程序中的有效载荷数据转码、解码或编码。作为这样的结果是,该方法可以在一个浏览器的脚本语言来实现,如JavaScript这是HTML协议的一部分。由于低加工的需要,这些文件的结构是实时的并且文件因此可以以流传输物质被播放,即播放第一媒体文件时下载媒体段用于第二媒体文件。即使下载的段不被浏览器应用程序支持,所构造的文件是可播放的,因为用于编码在CDN的一边的有效载荷数据的编解码器是由浏览器应用程序所支持的。
因此,第一和第二文件是在浏览器应用程序中播放,并且文件的结构完成,使得所获得的文件根据一个浏览器协议,如如HTML或HTML5协议,可由浏览器的媒体播放器播放。HTML5中,例如,第一和第二文件的播放,可以通过环绕一个链接到第一或第二个文件用<video>标签来实现。它因此一个优点是没有插件,例如,Silverlight、Flash或QuickTime,需要执行媒体的解码和可视化。
根据一个实施例,方法还包括一个流媒体会话,与CDN一起启动。这是通过从CDN检索一个清单文件来实现的。清单文件包含媒体片段信息关于媒体片段是可用的作为文件在CDN上。媒体段的第一和第二子集,然后被选择使用这段信息。
优选的,片段信息包括内容分发网络上各个所述片段的位置的有关信息。获得第一和第二子集,于是包括通过发送请求到内容分发网络与片段的位置作为参数,检索所述第一和第二子集的每个所述片段。
通过解析清单文件,并基于清单文件中的信息选择片段,支持自适应流。这允许基于客户端运行的浏览器应用程序的质量和带宽要求选择片段。即使浏览器所使用的协议,例如HTML或HTML5,不支持自适应流,该方法允许由浏览器支持的脚本语言例如JavaScript实现在浏览器程序内这样的支持。
有利地,流会话是HTTP自适应流会话并且请求是HTTPGET请求。
这具有优势,协议如HLS、MSS、DASH或HDS可以在浏览器应用程序中被支持,而无需使用任何插件,因为该方法是通过浏览器应用程序本身执行,例如通过JavaScript代码。此外,通过使用HTTP协议,能够避免防火墙或代理阻塞检索片段,在一般情况下,它们允许HTTP流量通过。这对其他非基于HTTP的协议并不总是这样,例如实时流协议(RTSP)。
根据实施例,清单文件包括关于片段的可用版本的编解码信息。此编解码信息特定用于每个版本对应编解码器用于编解码音频和/或视频片段的有效载荷数据。然后,该方法进一步包括基于编解码信息选择一种版本的片段使得相应的编解码器被浏览器程序支持。
换句话说,该清单文件中列出几个版本的段及相应的媒体,由此每个版本提供媒体和片段由不同的编解码器进行编码。由于浏览器应用程序可能不支持所有可能的编解码器在浏览器应用程序的媒体播放器内重放媒体,这允许挑选一个由浏览器支持的编解码器编解码的片段版本。
根据一个实施例,媒体片段包括索引信息,其中,包括位置信息,关于媒体片段内音频和/或视频有效载荷数据的位置信息。然后,该方法进一步包括以下步骤:
-通过使用索引信息从媒体片段中提取视频和/或音频有效载荷数据。
-存储视频和/或音频有效载荷数据。
-使用所存储的视频和/或音频有效载荷数据用于所述构建步骤。
这允许检索来自一个片段的视频和/或有效载荷数据,即使数据在片段内没有按照应当的被命令,根据所得到的文件的格式,使它由播放浏览器应用程序是可播放的。这也允许跳过产生的文件中的不被需要的额外数据,例如字幕或不同的音频流。索引信息进一步还可以包括关于媒体内音频和/或视频有效数据载荷的时间间隔的同步信息。所以每一块有效载荷数据可由关于如何使数据与其它有效载荷数据及时对齐的定时信息伴随。该信息可以被重新格式化,以由第一和第二文件形成的兼容的形式。
根据一个实施例,播放的步骤可以进一步包括:
-在浏览器应用程序中的一个第一播放器播放第一媒体文件;
-在播放第一媒体文件的同时在播放器浏览应用程序的一个第二播放器中下载第二媒体文件;
-第一个媒体文件结束时,开始播放第二个媒体文件。
当在同一播放器中播放两个文件时,将需要一些时间来在第一和第二视频之间切换引起一个可见的或可听的过渡效果。因此,上述实施例具有媒体能以一种几乎无缝的方式被播放的优点。当第一个文件播放结束时,一切都准备好用于播放第二个文件,第二个播放器只需要在第一个播放器停止时开始,以确保这两个文件的播放之间一个几乎平滑的过渡。
在第一和第二媒体播放器是视频播放器用于由浏览器应用程序使用在显示器上播放视频的情况下,根据上述实施例的方法,播放步骤还可以包括:
-在所述下载之前,初始化和隐藏所述第二视频播放器。
-在显示器上定位第二视频播放器,与第一视频播放器相同的位置;
-在第一媒体文件播放结束时,隐藏第一个视频播放器;
-在第一媒体文件播放结束时,取消隐藏第二个视频播放器。
由此两个视频播放器被定位在彼此的顶部使得一个或另一个可见。在第一媒体文件在第一播放器上播放结束时,需要做的唯一一件事就是切换可见或者命令播放器,并且开始第二个播放器。这使得视频之间以有限的可视小瑕疵一个平滑的过渡。
根据一个替代实施例,当使用两种不同的媒体播放器时,构造第二媒体文件还包括:
-把来自媒体片段的第一子集的一个或多个最后片段中的一份视频和/或音频有效载荷数据放入第二文件。
该播放然后包括:
-在浏览器应用程序中的一个第一播放器播放第一媒体文件;
-在播放第一媒体文件的同时在播放器浏览应用程序的一个第二播放器中下载第二媒体文件;
-同步播放所述第一和第二媒体文件。
换句话说,第一个文件的最后一个有效载荷部分在第二文件的开始被重复,使得由两个文件呈现的媒体流及时的部分重叠。然后,当在两个媒体播放器播放两个文件时,第二媒体播放器是在此重叠部分期间启动的,所以在一些点上两个媒体播放器播放是同步的。这具有消除了在第一播放器之后第二播放器开始的时候仍然存在的可能的瑕疵的优点,因为这可能导致两个文件的播放之间的最小延迟。
有利的情况为,第一和第二播放器再次为视频播放器,用于由浏览器应用程序使用在显示器上播放视频,播放可进一步包括:
-在下载之前,初始化和隐藏第二视频播放器。
-在显示器上定位第二视频播放器,与第一视频播放器相同的位置;
-在所述同步播放期间,隐藏第一视频播放器和取消隐藏第二视频播放器。
在同步播放期间,第二视频播放器因此已经在播放内容,尽管在显示器上不可视。播放器之间的切换则仅局限于在播放器的可视性或命令的改变。这确保了视频中从一个文件到另一个文件的平稳过渡。由浏览器应用程序支持的HTML协议,允许以一种非常方便的方式进行这种定位、隐藏和取消隐藏视频播放器。
任选地,第一和第二视频播放器包括深度属性,在所述显示器上播放所述视频播放器时,在深度上限定出现的顺序,并且其中所述隐藏包括分配一个深度属性到所述第一播放器,使得所述第一视频播放器在所述显示器上在第二所述播放器之下出现。
深度属性允许以一种方便的方式执行(非)隐藏,因为在显示器上的对象的分层是浏览器应用程序的一种固有特性。然后,(非)隐藏通过改变浏览器应用程序中的对象的单个属性值进行。
此外,第一和第二视频播放器可以包括透明度属性,用于定义显示器上的第一和第二视频播放器的透明度。第一视频播放器的隐藏然后包括逐渐增加第一视频播放器的透明度。
换言之,在同步播放两个显示器期间,位于所述第一视频播放器下方的第二视频播放器将逐渐变得越来越明显。因此,(非)隐藏是一个渐进的过程。这种渐进式(非)隐藏的好处是,这两个播放器之间的一些像素或小的定时误差的小的定位误差会被两个播放器的混合掩盖。
根据替代实施例的进一步的实施例,当媒体片段包括具有音量电平的音频有效载荷数据时,第一媒体文件的构建包括当淡出音频有效载荷的数据的音量电平时会同步播放。第二媒体文件的构建于是包括当淡入音频有效载荷的数据的音量电平时会同步播放。淡入和淡出的执行,使得总音量电平保持基本不变
这具有这样的效果,即在同步播放时,第一播放器的音频的音量会逐渐降低并且第二播放器的音量将逐渐增大。两个文件之间的音频的转换是通过音量的交叉渐进在时间上是平滑的。音量的渐进是以这样的方式进行的,使音量电平的总和,即感知的音频的总量,基本上与原始片段中一个片段的音量是相同的。
这具有在媒体同步播放期间总音量被感知是未发生变化的有点。当不这样做时,第二播放器开始,感知的总音量会大于当单独播放文件中的一个时。
可替代地,将文件内的音频的音量电平渐淡时,同步播放可以包括逐渐减小的第一媒体播放器的音量级别;并且其中所述同步播放还包括逐渐增加第二媒体播放器的音量级别;执行的逐渐减小和增加,使得总体音量保持基本不变。
根据这个替代方案,音量电平,因此不通过改变媒体的音频有效载荷数据而改变,而是通过改变播放器的音量播放媒体。这具有的优点是,有效载荷数据能够在文件的构建期间保持不变,并且音量的变化是由播放器注意。
附图说明
图1示出根据本发明的一个实施例,获取媒体片段的一个第一子集和第二子集;
图2示出根据本发明的一个实施例,构建一个第一和第二媒体文件;
图3示出浏览器应用程序的一个浏览器窗口中的视频播放器;
图4示出根据本发明的一个实施例,构建一个第一和第二媒体文件;
图5示出根据本发明优选的一个实施例,播放一个第一和第二媒体文件;
图6示出根据本发明的实施例,音频音量电平的交叉渐进。
实施例详细描述
图1示出根据本发明优选的一个实施例,媒体项目的视频片段的的一个第一子集2和第二子集3如何被获取并存储入一个浏览器应用程序;用户与运行在客户端上的浏览器应用程序互动,例如个人电脑、平板电脑或智能手机,是在互联网上冲浪并到达一个网页,包括在服务器上互联网上或内容分发网络(CDN)上可用的媒体项目的参考。媒体项木可以是视频流或音频流。此媒体项目是根据HTTP实时流(HLS)协议进行编码,从而可以作为片段,其中每个片段1包含一定时间间隔的媒体的一部分。在HLS中,这些时间间隔通常范围为1至10秒。链接到媒体项目链接到一个清单文件,其包括关于片段的信息,例如各个片段的位置,和用于编解码有效载荷数据的编解码器,即在片段内的实际音频5和/或视频4有效载荷数据。如果浏览器应用程序的媒体播放器有使用的编解码器的支持,浏览器的应用程序持续,否则可能会显示一条消息,媒体无法播放,因为用于解码有效载荷数据的编解码器被不支持或不可用。通过下载清单文件,流媒体会话与CDN开始。任选地,清单文件可以提供片段的不同版本的可用性,其中的每一个版本的有效载荷数据是用不同的编解码器编码。当不同的编解码器的版本可用,浏览器应用程序将选择由浏览器应用程序所支持的片段的版本。
在HLS中,片段1是根据MPEG-TS协议被格式化,并且通常被称为片段。每个MPEG-TS片段被分成数据包6分别具有188字节的长度。片段中的第一个数据包是一个数据包报头,包含关于媒体内片段的时间的索引信息10和关于片段内的节目流媒体的进一步细节。每个这样的节目流可以是视频流、音频流或任何其他流诸如字幕流。音频流的有效载荷5和视频流的有效载荷4被划分在几个数据包。除了有效载荷,数据包6还包括进一步的索引信息允许从数据包同步所有有效载荷数据。
为了播放媒体项目,浏览器应用程序通过从清单文件中检索链接到的片段获得一个或多个MPEG-TS的一个第一集2并下载相应片段。在HLS中,下载通常是通过发出一个HTTPGET请求到服务器执行。由于MPEG-TS的片段1不被浏览器应用程序支持,媒体片段需要重新格式化到由浏览器应用程序支持的兼容的格式。因此,有效载荷数据是从数据包6通过检查数据包报头中的索引信息10和在每个数据包括有效载荷数据的开始提取。有效载荷数据然后存储在浏览器应用程序中的数据对象7。该数据对象7因而包括有效载荷数据部分A1、A2、A3和A4用于音频8和有效载荷数据部分V1、V2、V3和V4用于视频9。这样的同步信息11从片段进一步在集2提取,使得音频和视频可以在以后以同步方式被播放。同步信息7也存储在数据对象7中。
然后,从片段的第一子集,一个第一媒体文件被构建。该构建的文件的格式为MPEG-4Part14媒体文件,更通常被称为一个MP4文件。它包括来自片段第一子集2的视频有效载荷数据V1-V4和音频数据的有效载荷数据A1-A4。由于有效载荷数据保持不变,它可以直接从数据对象7复制到MP4文件,因此,不需要计算密集型的代码转换或重新编码操作。一个MP4视频文件的重放是由一个HTML5兼容的浏览器应用程序支持,因此,该构造的文件可以在浏览器应用程序的视频播放器里播放,只要浏览器应用程序支持用于解码音频和视频的有效载荷数据的编码编解码器。因为媒体的数据流是一个连续的过程,在重放第一媒体文件期间,片段3的第二子集被下载并且其有效载荷数据存储在数据对象7,与所述第一子集2为相同的方式。然后,第二MP4媒体文件被构造包括视频有效载荷数据V5-V8和音频有效载荷数据的A5-A8。这个第二个文件,然后,在浏览器应用程序的视频播放器中再次播放。下载片段的子集、构建视频文件和播放文件的过程被重复,直到媒体或视频项目结束或者直到重放停止。
视频文件的构建和它们是如何在浏览器应用程序播放将在下文中更详细地描述。
构建视频文件的第一种方法表示在图2中。第一视频文件21用视频有效载荷数据V1至V4和与该音频有效载荷数据A1至A4构造。还报头I1被添加到文件21用于所有的有效载荷数据的同步的目的。第二视频文件22然后从视频有效载荷数据V5-V8和音频有效载荷数据A5-A8构造。还有报头I2被添加到第二视频文件22。两个文件因此包括连续的视频部分在时间上是完整的视频项目在浏览器应用程序中进行播放。
对两个视频文件21和22的连续重放,文件是一个接一个播放没有中断。这是示于图3中。第一视频文件21是首先下载到浏览器应用程序的浏览器窗口33内视频播放器31中并被播放。下载和播放可以通过使用HTML5<视频>标签来完成。在第一文件重放期间,第二视频播放器32与第二视频文件22初始化,但此第二视频播放器32从视频项目的观看者保持隐藏。当第一播放器31在第一视频文件21播放结束时,第二视频播放器32被定位在与第一视频播放器31相同的位置,第一视频播放器从观看者隐藏并且第二视频文件重放开始。由于两个视频播放器31和32具有完全相同的尺寸和外观,观看者得到的印象是,他仍然是看同样的视频,并不知道有两个视频文件21和22之间的过渡。对于视频播放器的隐藏和取消隐藏层叠样式表(CSS)属性可以使用。视频播放器32的隐藏,然后通过将CSS“可见性”属性设置为“隐藏”完成。可替代地,“z-索引”CSS属性可以使用。该属性指定在浏览器窗口中的元素的叠层顺序或深度。视频播放器具有最高z-索引值将出现在视频播放器具有较低的z-索引值的顶部。
构建视频文件的第二种方法表示在图4中。第一文件41以从图2中第一文件21相同的方式被构造。对于第二文件44,第一子集2的最后一个片段的有效载荷数据,即V3-V4和A3-A4也放在第二文件44中。在视频文件41的时间的最后部分,因此与在视频文件42的时间的第一部分是相同的。换句话说,文件41和42是这样重叠的。
文件41和42的重放示于图5,其中所述视频有效载荷数据的重放被示出为时间的函数。上部杆57示出了视频有效载荷数据V1-V4中的第一个球员31和下杆58的重放表示视频有效载荷数据V3-V8在第二播放器32的播放。首先,文件41被装载入浏览器应用程序的浏览器窗口33内的第一播放器中,并在时刻t1启动,类似于上述的文件21的重放。在文件41的重放期间,在时间t2,第二视频播放器32与第二视频文件42初始化但对观看者隐藏。这个文件42的重放,然后在时刻t3开始,当第一视频播放器31是在视频有效载荷V2和V3播放中转换时。在那一刻,两个视频播放器31和32同步播放该视频文件41和42,即在同一时间每个显示相同的视频帧。在这个时刻t3,视频播放器32仍对观看者隐藏。在此同步播放期间,在时间t4,第二播放器32对观看者是可见并且第一播放器31是不可见的。从时间t4起,观看者由此看到了视频播放器32播放视频文件42。
当在视频文件中的重放没有重叠,如图2所示,取决于浏览器应用程序,由于视频播放器31和32纸件需要转换时间,有可能仍然可见和可到的瑕疵。通过构建和播放文件41和42的重叠部分,这类的瑕疵被避免,因为在播放器31和32转换期间,观看者总是看到和听到一个视频播放。
在播放文件41和42的重叠部分期间,从时间t3到时间t5可以有体积的增加,取决于浏览器应用程序是否会产生声音,当在第一或第二视频播放器是隐藏的。这示于图5,其中51表示第一视频播放器31的音量电平作为时间的函数,其中52表示第二视频播放器32的音量作为时间的函数,并且其中53表示由用户感知的音量电平51和52总和的总音量。当音量电平值为0,则音频静音并且当音量电平值是100,它是在原来存在于视频中的水平。由于视频文件41和42的交叠,在重叠的时段t3至t5期间量的增加是明显的。
为了解决这个问题,音量的交叉衰落可以应用。这也示于图5中。在重叠时段t3-t5,第一视频播放器31的音量水平54的音量减弱,并且同时,第二视频播放器32的音量水平55增加。这这种增加55和降低54是以这样一种方式完成,总的感知音量56保持相等,即与在原始音频有效载荷A3-A4中的相同。增加和减少音量可以以几种方式进行,例如用几个类型的曲线来实现,如图6所示。在图6-a中,这是用突然的方式进行,在开始把音量55静音,然后,在某一时刻,把音量54静音,并把该音量55恢复原来的音量。代替线性曲线,如图6-c所示,高阶曲线如图6-b所示,可以也可以使用。
适应音量54和55可以通过在重放文件41和42期间适应视频播放器31和32的音量水平来完成。视频播放器32的音量在随后在同步播放文件41和42期间逐渐增加,并且视频播放器31的音量在同一期间被逐渐减弱,使得总音量保持不变。
可替代地,音量电平54和55可以在文件41和42的构建过程中进行调整。为了做到这一点,音频有效载荷数据A3-A4将在创建两个文件41和42的过程中被改变。在文件41的构建期间,音频有效载荷数据A3-A4的音量将必须降低到零,并且文件42的构建期间,所述音频有效载荷数据A3-A4的音量将必须是从零提高到它原来的水平。再一次,在同步播放两个文件41和42期间,减小和增加是以这样的方式完成,被感知的总音量水平是恒定的,即,与原音量水平相同。换句话说,第一文件的音量电平淡出,而第二文件的音量电平淡入。
当在同步播放文件41和42期间切换播放器31和32的可视性,一个可见的瑕疵可能仍然会呈现给观众。如果两个播放器没有精确地定位在浏览器窗口的相同位置,即,当两个播放器之间有一个或多个像素的水平或垂直方向的偏移时,可能发生这种情况,此可见的瑕疵也可以由时间偏移引起,即当两个文件41和42没有被精确同步播放,即当两个播放器之间有一由一个或多个视频帧偏移。这个偏移的可视化效果可能由视频有效载荷的等效交叉衰减而不那么明显。同步地播放这两个文件41和42期间,视频播放器41被设置成越来越透明,从时刻t3到时刻t5。优选的视频播放器41的透明度是从零提高到百分之一百,即从不透明到完全透明的。这种方式中,第二视频播放器32被定位在与第一播放机31相同的位置,但完全被第一播放器31覆盖,将随着第一播放器31透明度的增加变得越来越明显。这样,由于位置或者时间偏移,可见瑕疵将被及时抹掉并且和对于观看者较少可见。视频播放器的透明度的变化可以通过CSS的“不透明度”属性来完成。
根据以上描述的实施例实施所述方法,JavaScript的脚本语言是优选使用的,因为这种语言是被支持浏览器应用程序支持的支持网页标准例如,HTML、CSS和JavaScript。JavaScript代码,然后由视频项的内容提供者,当用户在用户加载包含视频的网页或者当用户启动视频重放的时候被递送。该代码可以一种库的形式被递送。这样一来,当流视频到浏览器应用程序时,浏览器就没有进一步需要特定插件,如Flash、Silverlight或者QuickTime。
上述实施例已经描述用于视频项包括视频和音频有效载荷数据,但本发明不限于此。所描述的方法也可被应用到音频项其只包括音频有效载荷数据。在浏览器应用程序中重放的音频片段的子集,然后存储在数据对象7。从所述子集,音频文件然后构建用于在浏览器应用程序中重放。这些音频文件可以例如根据MPEG-4Part14标准被格式化为M4A文件。
上述实施例已经描述了HLS媒体流的重放,但是根据其它媒体流协议,媒体流使用的片段可以以类似的方式来实现。这些协议的例子是微软的SmoothStreaming(MSS),HTTP动态流(HDS)由Adobe和动态自适应流通过HTTP由3GPP标准(DASH)定义。
尽管本发明已经通过参考具体的实施例进行展示,这对那些本领域技术人员将是显而易见的,本发明并不限于前述说明性实施例的细节,并且,本发明可以进行多种变化和和修改进行实施,而不偏离其范围。因此本发明实施例在所有方面都是被考虑为是说明性的而不是限制性的,本发明的范围由所附的权利要求而不是由前面的描述说明,并且其落入权利要求的等价的含义和范围内的所有变化因此旨在被包含在其中。换句话说,设想覆盖落入基本原理的范围内的任何和所有修改,变化或等同物和其本质属性都声称在本专利申请中。本专利申请的读者应当理解进一步通过这样的词语“包括”或“包括”不排除其他元件或步骤,词语“一”或“一个”并不排除多个,并且单个元件,例如计算机系统、处理器或另一集成单元可以实现权利要求中所述的几个装置的功能。权利要求中的任何参考标记不应被解释为限制有关的各个权利要求。术语“第一”、“第二”、第三个“、”一“、”B“、”C“等,在说明书或权利要求中介绍了使用类似的元件或步骤,并且不区分必然描述顺序或时间顺序。但是应当理解,如此使用的术语在适当的情况下与本发明实施例中是可互换的,根据在本发明中以其他的序列,或者在取向与所述一个(多个)与上面所描述的或说明的不同,也能够操作。