CN109792547B - 将视频内容从服务器传送至客户端设备的方法 - Google Patents

将视频内容从服务器传送至客户端设备的方法 Download PDF

Info

Publication number
CN109792547B
CN109792547B CN201780060188.0A CN201780060188A CN109792547B CN 109792547 B CN109792547 B CN 109792547B CN 201780060188 A CN201780060188 A CN 201780060188A CN 109792547 B CN109792547 B CN 109792547B
Authority
CN
China
Prior art keywords
segment
viewer
segments
content
bit rate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201780060188.0A
Other languages
English (en)
Other versions
CN109792547A (zh
Inventor
M·尼尔森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of CN109792547A publication Critical patent/CN109792547A/zh
Application granted granted Critical
Publication of CN109792547B publication Critical patent/CN109792547B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明涉及将视频内容从服务器传送至客户端设备的方法。描述了将诸如视频序列的媒体从服务器传送到客户端设备的方法，其考虑了视频序列的不同部分的相对重视度。该序列被分成时间片段，各片段以多个比特率进行编码(并因此具有多种质量)。给各片段分配指示该片段的相对重视度的观看者重视度参数，其信息被存储于清单文件或类似文件中。客户端在清单文件中接收此片段和观看者重视度数据。针对下载选择的各片段的比特率取决于该片段和未来片段的相对重视度。然后，将所选片段从服务器传送到客户端设备。因此，相比于具有较低观看者重视度的片段，具有较高观看者重视度的片段将以较高的编码比特率被传送。

Description

将视频内容从服务器传送至客户端设备的方法
技术领域
本发明涉及通过网络进行媒体传送的领域，尤其涉及考虑观看者重视度将媒体传送到客户端设备的方法。
背景技术
针对视频内容的单播传送，自适应比特率传送变得越来越普遍，其使用包括AppleHTTP直播流(HLS)和Microsoft SmoothStreaming的专有技术，并使用标准化的MPEG DASH(HTTP上的动态自适应流传输)协议。
自适应比特率流是基于将内容划分为短片段的概念，通常，该短片段的时长为4至10秒，各片段以多个不同的比特率进行编码(因此具有不同质量)，以用于客户端设备使用HTTP GET请求来检索内容。所请求的片段的比特率(质量)是基于最近通过网络获得的吞吐量以及已经在等待显示的客户端设备处传送和缓冲的数据量而确定。
自适应比特率传送的当前实现方式是对所有的片段进行同样的处理。因此，某些片段可能以观看者可接受的质量(比特率)传送，但是其他片段可能以观看者不可接受的质量(比特率)传送。
发明内容
本发明的实施方式的目的是提供一种向客户端设备传送媒体的改进方法。
根据本发明的一个方面，提供了一种将视频内容从服务器传送到客户端设备的方法，所述视频内容包括片段序列，并且其中以多个比特率对各片段编码，所述方法包括：
a)在所述客户端设备处接收关于各片段的信息，其中所述信息包括比特率和与各片段相关联的观看者重视度参数；
b)估计所述服务器和所述客户端设备之间的网络比特率；
c)根据所估计的网络比特率和在客户端处缓冲的视频内容的时长确定最大片段比特率；
d)通过对所确定的最大片段比特率应用速率缩放因子来缩放所述最大片段比特率，其中所述速率缩放因子取决于与第一片段相关联的观看者重视度参数；
e)识别用于所述第一片段的比特率，该比特率不大于缩放后的最大片段比特率；
f)将所识别的第一片段传送到所述客户端设备。
可以针对片段序列中的第二片段重复步骤a)至f)。
当与所述第一片段相关联的观看者重视度参数为低时，所识别的用于第一片段的比特率为低，当与所述第一片段相关联的观看者重视度参数为高时，所识别的用于第一片段的比特率为高。
所识别的比特率还可以取决于与另一片段相关联的观看者重视度参数。并且，当与所述第一片段相关联的观看者重视度参数低于与另一片段相关联的观看者重视度参数时，所识别的第一片段的比特率较低。
当针对第一片段的观看者重视度参数为低时，速率缩放因子为低，并且当针对第一片段的观看者重视度参数高时，速率缩放因子较高。
速率缩放因子可以还取决于与另一片段相关联的观看者重视度参数。并且当与第一片段相关联的观看者重视度参数低于与另一片段相关联的观看者重视度参数时，用于第一片段的速率缩放因子较低。
可以在清单文件中接收关于各片段的信息。
重要的是认识到本发明的示例涉及片段的优先化，以试图确保以更高的质量传送观看者最感兴趣的片段。片段具有相关联的观看者重视度参数，其指示该片段的相对重视度，并且片段的传送是根据其相对的观看者重视度而被有效地按优先顺序处理。
本发明的示例并不是关于通用数据流量的优先化(其中一个流优先于另一个流)，这或是由于流在整体上更有价值或更具时效性，或是由于特定流接近耗尽而引起播放拖延。它也并不是要确保要求较高的流(例如体育节目)比要求较低的流(例如戏剧节目)具有更高的网络吞吐量。
一个示例是一些体育赛事，其中最感兴趣的短时间段被不太感兴趣的长时间段分开。例如，在棒球和板球中，观看者会非常感兴趣从投手/投球手放开球之前开始的短时间段，但这仅持续几秒，而在下一次这样的比赛之前会有一段相当不感兴趣的时间。显然，该示例不限于体育内容，其还包括但不限于，游戏节目、真人秀节目、戏剧和新闻。
附图说明
为了更好地理解本发明，现仅通过示例的方式参考附图，其中：
图1是表示本发明的示例中的系统的网络图；
图2是本发明的示例中的内容生成器的框图；
图3是本发明的另一示例中的内容生成器的框图；
图4是本发明的另一示例中的内容生成器的框图；
图5是本发明的示例中的内容服务器的框图；
图6是本发明的示例中的内容客户端的框图；
图7示出了使用速率缩放因子的示例方法；以及
图8示出了使用缓冲器调整的示例方法。
具体实施方式
这里参考特定示例描述了本发明。然而，本发明不限于这些示例。
本发明的示例提供了一种考虑视频序列的不同部分的相对重视度将媒体(诸如视频序列)从服务器传送到客户端设备的方法。该序列被分成时间片段，各片段以多个比特率进行编码(并因此具有多种质量)。给各片段分配指示该片段的相对重视度的观看者重视度参数，其信息被存储于清单文件或类似文件中。客户端在清单文件中接收此片段和观看者重视度数据。选择下载的各片段的比特率取决于该段和未来片段的相对重视度。然后，将所选片段从服务器传送到客户端设备。因此，相比于具有较低观看者重视度的片段，具有较高观看者重视度的片段将以更高的编码比特率被传送。
图1示出了系统100的简化网络图，该系统100包括与内容服务器104通信的内容生成器102。内容生成器102负责接收未压缩的视频内容(例如电视直播)，并且编码和打包视频内容，以传给内容服务器104。内容服务器104负责存储接收的视频内容，并且根据请求将该内容传送到通过网络106连接的适当配置的客户端。该示例中示出了三个客户端设备108、110和112。例如，客户端可以是标准HTTP自适应比特率流客户端，适于支持MPEG DASH或Apple的HLS。客户端用于发现视频内容、请求和处理清单文件、请求视频片段、并处理这些片段以供观看。虽然视频内容可以通过网络106直接传送到这些客户端，但是也可以通过每个客户端本地的代理来进行传送。
内容生成器102包括用于将元数据插入其生成的清单文件中的机制，该元数据包括：针对编码内容的各片段，将观看者重视度参数按信号的方式发送给终端用户的数据，所述观看者重视度参数指示内容的重要性且由片段中编码的视频和音频数据表示。
应注意，术语“重视度”和“兴趣”在说明书中可互换使用。因此，对观看者重视度参数的引用等同于对观看者兴趣参数的引用。
在图2中更详细地示出内容生成器102。内容生成器102包括视频编码器206、音频编码器208、分段模块210、封装模块212和输出接口214。内容生成器102接收未压缩视频内容，其包括未压缩视频流202和未压缩音频流204。具体地，视频编码器206获取未压缩视频流202，并对该视频进行编码以生成编码的视频流。在该示例中，所使用的视频编码方法是根据ITU-T H.264标准，但是本发明并不限于此标准，而是可以使用其他编码方法。类似地，音频编码器208获取未压缩音频流204，并对该音频进行编码以生成编码的音频流。在该示例中，音频编码方法是MPEG-4HE AAC v2，但是本发明并不限于此标准，而是可以替代地使用其他编码方法。未压缩视频流以多个比特率编码(相关联的未压缩音频流通常仅以一个比特率编码，但也可以以多个比特率编码)，从而针对每个比特率生成编码流。不同的比特率有效地产生不同的视频质量，较高的比特率编码产生较高的视频质量，较低的比特率产生较低的视频质量。编码视频流包括多个帧或图片，这些帧或图片进而可以被聚类成图片组或GOP。
编码的视频流和编码的音频流(或者在以多个比特率对内容进行编码情况下的每个编码的视频流和音频流)被分段模块210分段为离散的(视频和音频)时间片段。可以设想，在未压缩视频/音频的时长中，每个时间片段为2至15秒之间，但也可以使用更长或更短的时长。虽然图中显示分段模块210是在编码器206和208之后操作，但是可以在编码之前对未压缩的视频流和音频流进行分段。因此，可以首先对未压缩视频和音频进行分段，然后可以对得到的未压缩片段进行编码，以生成编码的视频和音频片段。
分段模块210可以考虑服务要求选择片段时长。例如，较短的片段允许在不同编码比特率的流之间进行切换，以更快出现，并且将允许以更精细的基于时间的粒度来按信号的方式发送观看者重视度数据。但是，较长的片段更容易被系统组件(特别是通过CDN(内容分发网络)节点)所处理，但可能会对按信号的方式发送观看者重视度数据的变化的频率产生负面影响，可能导致编码比特率之间的切换较慢，并可能在直播服务时引入更多端到端的延迟。通过选择各片段的时长而不是使用固定值，可以选择片段时长，从而选择片段边界，使得它们与观看者重视度数据的变化一致，因此能实现名义上长的片段时长且精细的时间粒度按信号的方式发送观看者重视度数据。
视频和音频片段由封装模块212处理。在一些实施方式中，封装模块212的输出是所谓的多路复用格式，例如IS 13818-1中规定的MPEG-2传输流(MPEG-2TransportStream)。MPEG-2传输流通常用于实时传送数字电视。MPEG-2传输流的片段也可用于Apple的HLS。在其他实施方式中，封装模块的输出可以是所谓的非多路复用格式，例如IS 14496-12中所规定的ISO基本媒体文件格式(ISO Base Media File Format)。这种格式的片段称为MP4片段。
本领域技术人员将理解，由编码器、分段模块和封装模块执行的功能可以由单个适当配置的通用视频编码器模块执行。
封装模块212还生成清单文件，该清单文件描述编码内容(在该示例中为传输流片段)以及如何获得编码内容，并将该文件传给内容服务器104。当使用MPEG-DASH，IS 20009时，清单文件被称为MPD(媒体呈现描述)。Apple的HLS以播放列表文件(.m3u8文件)的形式提供清单文件。清单文件包括针对每个内容片段指示该片段对观看者的重视度的观看者重视度参数数据。
该观看者重视度参数(也称为观看者重视度数据)可以由观看者重视度模块240使用未压缩视频流202和/或未压缩音频流204生成。
在一个示例中，观看者重视度数据可以从音频流的响度获得，例如，响亮的音频表示较大的观看者重视度。在另一示例中，观看者重视度数据可以从视频流获得，观看者重视度数据从下述的一项或更多项获得：视频流的移动量、流内的场景变化率、以及通过将视频流的图片与预定图片进行匹配。
如图3所示，观看者重视度数据可以由观看者重视度模块240使用下述信息来生成：通过对视频编码器206中的未压缩视频流202进行编码而生成的信息，和/或，通过对音频编码器208中的未压缩音频流204进行编码而生成的信息。在一个示例中，可以从音频流中的响度或成音频率来获得观看者重视度数据。在另一示例中，可以从视频编码处理中获得观看者重视度数据，其中观看者重视度数据是从下述的一个或更多个获得：视频流的运动矢量的大小、帧内帧被编码的速率、以及视频流的复杂性，其根据编码中使用的量化参数和得到的压缩比特数计算得出。
如图4所示，可以通过在内容生成器102接收源内容之前发生的过程来生成观看者重视度数据，在这种情况下，将观看者重视度数据流205与未压缩视频流202及未压缩音频流204一起输入到内容生成器。在这种情况下，可以在内容捕获期间通过自动过程生成观看者重视度数据。例如，在体育赛事中，从一些相机捕获的内容可被认为比其他相机捕获的内容对观看者而言更重要。或者，可以手动注释内容以指示对于观看者的不同重视度级别。这样的手动注释可以集成于现有的内容捕获和生产工作流程，其中，在捕获期间注释内容，使得能够为了观看者的利益而重放内容，或者用于稍后生成的亮点包，或者用于在事件的自然间隙期间的讨论。
分段模块210可以在考虑观看者重视度数据的情况下选择片段时长，并且具体地，将片段边界与观看者重视度数据中的变化或显着变化对齐。
在一个示例中，封装模块212接收观看者重视度数据，并在其生成的清单文件中包括该数据。清单文件描述了每个内容片段的可用比特率，以及各片段的位置(片段存储于内容服务器104中的位置的地址)。客户端使用清单文件来选择和请求内容片段，其中客户端至少基于与这些片段相关联的观看者重视度数据(或观看者重视度参数)选择请求哪个编码的内容片段、以及以哪个编码的比特率来请求。
在另一个实施方式中，封装模块212接收观看者重视度数据，并且将该数据包括在其产生的内容片段内，在一个内容片段中按信号的方式发送至少一个未来内容片段的观看者重视度数据。
在图5中更详细地示出了内容服务器104。内容服务器104在输入接口502处，以例如MP4文件的传输流片段或碎片以及任何相关联的清单的形式，接收编码的内容片段。内容服务器104还包括用于存储内容片段506和清单文件508的数据存储器504，以及输出接口510。数据存储器504可形成标准网络服务器的一部分，其能够响应经由输出接口510的请求而提供各个内容片段。内容服务器104响应于客户端的请求提供内容片段。
在图6中更详细地示出了客户端108。客户端108可以通过首先向内容服务器104请求与所需内容相关联的适当的清单文件来发起内容传送。在接收并处理清单文件之后，客户端可以使用与清单文件中的各片段相关联的位置信息来对编码的内容片段进行特定请求，并使用清单文件中包含的元数据以及它已计算和存储的状态信息来决策关于请求哪个片段以及以哪种编码比特率进行请求。
在输入接口602上向内容服务器104请求清单文件并接收清单文件之后，内容客户端108将清单文件存储在内容片段和清单存储器606中。客户端决策模块608分析清单，并使用清单文件中的位置信息以指定的编码比特率或质量等级发出对内容片段的请求。该请求由内容客户端108通过输入接口602传到内容服务器104。当在输入接口602上接收到来自内容服务器104的所请求的片段和任何后续片段时，将内容片段存储在内容片段和清单存储器606中。
接收和存储的内容片段被传给视频解码器610和音频解码器612，视频解码器610和音频解码器612分别执行解码操作并输出解码的视频和音频。当内容片段已被解码并呈现给用户时，将该内容片段从内容片段和清单存储器606中移除。因此，内容片段和清单存储器606是充当接收的片段的缓冲器，直到它们被解码器检索以用于解码和播放为止。
状态处理和状态信息存储器604监测在输入接口602上接收内容数据的速率、内容经由视频解码器610和音频解码器612被解码并呈现给用户的速率、以及接收并存储在内容片段和清单存储器606中但尚未解码并呈现给用户的内容片段数据量。
客户端决策模块608处理清单文件中的元数据和已经被计算并存储在状态处理和状态信息存储器604中的状态信息，以确定接下来以哪种编码比特率或质量等级从内容服务器104请求哪个内容片段。然后，它在输入接口602上向内容服务器104发出对该内容片段的请求。
在一个示例中，内容请求针对各片段采用HTTP请求的形式，其由内容服务器104处理，以将内容传送到客户端108。在一些实施方式中，各单个内容请求导致单个内容片段被传送，而在其他实施方式中，单个内容请求可以导致多个内容片段使用HTTP PUSH协议被传送。
清单文件中包括的元数据可以包括但不限于：各片段的比特率、各片段的时长、以及各片段的观看者重视度。这些数据项中的每一个对于整个内容片段(例如电影)中的各片段可能是不同的，或者对于较长时长或整个内容片段也可能保持不变。在一个示例中，对于给定质量等级的每个编码片段，比特率是相同的，即所谓的恒定比特率编码。在另一个实施方式中，对于给定质量等级的每个编码片段，比特率可能是不同的，使得在给定质量等级下，各片段的感知质量接近于恒定，即所谓的恒定质量编码。各片段的时长可以是恒定的，或者片段时长可以是可变的，例如，片段的边界与观看者重视度数据的变化相一致。通常，期望观看者重视度数据是在片段之间变化，但是对于某些内容片段，其可能没有变化或者变化很小。
计算并存储在状态处理和状态信息存储器604中的状态信息可以包括但不限于：已经接收到但尚未呈现给用户的数据量，其可以任何合适的单位进行测量，例如，依据向用户呈现的时间，或依据字节的存储数据，以及在至少一个时段内测量的客户端能够从内容服务器104获取的网络比特率(吞吐量)的估计。
如上所述，清单文件用于描述每个内容片段的可用比特率，以及各片段的位置(文件位置)。当使用MPEG DASH，IS 23009-1时，清单文件是被称作媒体呈现描述(MPD)的XML文件。使用Apple HTTP Live Streaming(HLS)时，清单文件是.m3u8格式的播放列表文件。使用Microsoft SmoothStreaming时，清单文件是XML文件。
现在将描述Apple HLS清单文件的示例，接着是根据本发明示例的携带观看者重视度信息的Apple HLS清单文件。还可以使用适当的语法以其他清单文件格式携带观看者重视度信息。
使用Apple HLS，有一个.m3u8文件的层次结构，它向客户端提供有关内容的信息，主播放列表文件引用了许多单独的播放列表文件。以下是主播放列表文件的示例：
#EXTM3U
#EXT-X-STREAM-INF：BANDWIDTH＝1300000
Http：//example.com/content_at_1M3.m3u8
#EXT-X-STREAM-INF：BANDWIDTH＝2000000
http：//example.com/content_at_2M0.m3u8
#EXT-X-STREAM-INF：BANDWIDTH＝3000000
http：//example.com/ccntent_at_3M0.m3u8
#EXT-X-STREAM-INF：BANDWIDTH＝4500000
hTTP：//example.com/content_at_4M4.m2u8
该主播放列表文件引用另外四个播放列表文件：content_at_1 M3.m3u8、content_at_2M0.m3u8、content_at_3M0.m3u8和content_at_4M5.m3u8。这些播放列表文件中的每一个都可以在http：//example.com/中找到，并且参考内容分别以1.3MBit/s、2.0MBit/s、3.0MBit/s和4.5MBit/s编码，如带宽属性所指示的。
通过列出以相应比特率编码表示该内容项的所有片段，这四个播放列表文件中的每一个都可以描述整个视频内容项，例如电影。这种用法对于视频点播应用较为典型，其中在客户端开始播放时，整个内容项在内容服务器上都是可用的。
以下是此类播放列表文件content at 3M0.m3u8的示例。
#EXTM3U
#EXT-X-PLAYLIST-TYPE：VOD
#EXT-X-TARGETDURATICN：10
#EXT-X-VERSION：3
#EXT-X-MEDIA-SEQUENCE：1
#EXTINF：10.0，
Segment_3M0_0001.ts
#EXTINF：10.0，
Seqment_3M0_0002.ts
#EXTINF：10.0，
Segment_3M0_0003.ts
...
#EXTINF：10.0，
Segment_3M0_0719.ts
#EXTINF：9.0，
Segment_3M0_0720.ts
#EXT-X-ENDLIST
播放列表文件由总共720个片段组成，除最后一个之外，所有片段均具有10s的时长，最后一个具有9s的时长(由参数#EXTINF指示时长)。由于播放列表详细说明了构成内容的所有片段，因此客户端只需请求此类型的播放列表文件一次就能播放整个内容项。
另选地，这四个播放列表文件中的每一个可以仅描述少量片段，可能是四个十秒的片段。这种用法对于直播内容传送服务(例如电视节目的直播传送)较为典型，其中播放列表中的片段代表最接近节目“直播边界(live edge)”的最新片段。客户端通常以约等于片段时长的间隔来重复请求播放列表文件。每次返回的播放列表文件可能包含不同的(较新的)片段。
以下是客户端可以在这种直播传送安排中接收的一个播放列表文件的示例。
#EXTM3U
#EXT-X-TARGETDURATION：10
#EXT-X-VERSION：3
#EXT-X-MEDIA-SEQUENCE：120
#EXTINF：10.0，
Segment_3M0_0120.ts
#EXTINF：10.0，
Segment_3M0_0121.ts
#EXTINF：10.0，
Segment-3M0_0122.ts
#EXTINF：10.0，
Segment_3M0_0123.ts
该播放列表显示了可以下载的四个片段，编号为120至123。片段120是最早的内容片段，而片段123是最新的片段并且是最接近内容的“直播边界”的片段。
如果客户端在大约10秒后再次请求播放列表，则可能会收到稍微不同的播放列表文件，因为新内容可能变为可用。下面示出了一个示例，其中最早列出的片段现在是编号121，并且新的片段124可用了。
#EXTM3U
#EXT-X-TARGETDURATION：10
#EXT-X-VERSION：3
#EXT-X-MEDIA-SEQUENCE：121
#EXTINF：10.0，
Segment_3M0_0121.ts
#EXTINF：10.0，
Segment_3M0_0122.ts
#EXTINF：10.0，
Segment_3M0_0123.ts
#EXTINF：10.0，
Segment_3M0_0124.ts
现在接下来是包含观看者重视度数据的播放列表文件的示例。
以下示出了上述视频点播播放列表文件，其被扩展以提供关于哪些片段可能是对该内容的观看者来说最感兴趣的信息。
#EXTM3U
#EXT-X-PLAYLIST-TYPE：VOD
#EXT-X-TARGETDURATION：10
#EXT-X-VERSION：3
#EXT-X-NEDIA-SEQUENCE：1
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0001.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：2
Segment-3M0_0002.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_2M0_0003.ts
...
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：2
Segment_3M0_0719.ts
#EXTINF：9.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0-0720.ts
#EXT-X-ENDLIST
在该示例播放列表文件中，各片段具有由前缀#EXT-X-VIEWER-INTEREST指示的附加参数。可以看出，编号为1、3和720的片段具有值1，表示观看者兴趣较低，而片段2和719具有值2，表示观看者兴趣较高。例如，片段2可能是观看者感兴趣的，因为它代表电影开始时电影情节的重要部分，并且类似地，片段719可能已被标记为观看者更感兴趣，因为它代表电影结束时的一些结论性情节。片段720可能已被标记为观看者比较不感兴趣，因为它表示电影结束时的演职员名单。
以下是从上述第一个请求的直播播放列表文件获得的直播播放列表文件的示例。
#EXTM3U
#EXT-X-TARGETDURATION：10
#EXT-X-VERSION：3
#EXT-X-MEDIA-SEQUENCE：120
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0120.ts
#EXTTNF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0121.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0122.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0123.ts
在该示例中，可以看出所有列出的片段被置为观看者兴趣级别较低。
以下是从第二个请求的播放列表文件获得的直播播放列表文件的示例，其在第一个请求的播放列表文件约十秒后立即请求。
#EXTM3U
#EXT-X-TARGETDURATION：10
#EXT-X-VERSION：3
#EXT-X-MEDIA-SEQUENCE：121
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0121.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0122.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：1
Segment_3M0_0123.ts
#EXTINF：10.0，
#EXT-X-VIEWER-INTEREST：2
Segment_3M0_0124.ts
编号为121、122和123的片段再次被指示为观看者较不感兴趣，但编号为124的片段被指示为观看者更感兴趣。这可能是因为内容项表示体育赛事，其中有一些情节时段与构成下一个情节或下一个“比赛”的时段分开。片段124可以表示这样的情节时段，因此，相比于在其之前的时段，观看者会对片段124更有兴趣。
在视频点播播放列表的情况下，当首次检索清单文件时，向客户端描述整个内容项，并且客户端可以计划何时请求片段以及在开始播放后的任何时间以哪种质量请求片段，直至片段被解码和呈现媒体所需要。
然而，在直播播放列表的情况下，各片段的观看者感兴趣级别仅在需要该片段用于解码和呈现媒体之前的短时段内在客户端可见。处理这个直播情况更具挑战性，其是下面示出的客户端行为的基础。虽然参考直播场景描述了该示例，但该方法也可以应用于视频点播场景。
回顾一下，在直播内容的实现方式中，必须重复请求清单文件，以获得关于最近在内容服务器上可用的片段的新信息。
在该示例中，内容片段以四个恒定比特率编码，其均具有等于10s的相同时长。所述的四个比特率为1.3MBit/s、2.0MBit/s、3.0MBit/s和4.5MBit/s。客户端定期请求更新清单文件。这是Apple HLS的常见行为，尤其是在视频直播时。在这种情况下，对清单文件的每个请求都可能导致清单文件致略有不同，其详细说明了现在可用的不同内容的数据。例如，当客户端以约等于片段时长的间隔请求更新清单文件时，每个新的清单文件通常将列出最近变得可用的附加片段，而不再列出最旧的一个片段，因为它距离直播内容的“直播边界”太远了。
如前所述，客户端将请求清单文件，然后将确定接下来请求哪个片段以及以哪种质量请求。现在将描述从播放一段内容期间的任意点开始的客户端行为。
下表以缩略形式显示了针对单个编码比特率连续请求清单文件或播放列表文件时返回的信息。每一列均显示了片段编号列表和相关的观看者重视度值。针对可选的编码比特率，请求播放列表文件时将返回类似信息。因此，该表为上述播放列表的缩略形式。
Figure GDA0002975926320000131
表1
在这个示例中，返回的第一个播放列表(可能是在播放开始时，但是我们假设它是在播放期间的某个任意点处)列出了编号为120到123的片段，这所有片段具有等于1(代表观看者的重视度级别较低)的观看者重视度参数。
返回的第二个播放列表列出编号为121到124的片段，其中前三个的观看者重视度参数等于1，代表重视度级别较低，而最后一个片段124的观看者重视度参数等于2(代表重视度级别较高)。
类似地，第三个和第四个播放列表文件中引入了新片段，在该示例中，新片段具有片段编号125和126，且其观看者重视度参数等于代表重视度级别较低的1。
因此，仅在接收到第二个播放列表文件时，客户端才知道即将到来的具有较高重视度的片段。此时，客户端有机会提前计划以确保以足够的质量等级(即比特率)来获得较高重视度的片段。
接下来是客户端使用的下载片段的方法的示例，其不考虑观看者重视度参数。客户端可以使用该方法来决策接下来请求的内容片段以及以哪种质量进行请求。
当客户端已经部分下载并已经缓存了一些内容准备解码和播放时，该示例开始。为方便起见，将下一个播放列表文件(即上述表1中的第一个播放列表文件)从内容服务器传送到客户端的时间描述为时间零。
最初，客户端请求清单文件，其中的信息汇总于表1，各片段可用于4种不同的比特率：1.3MBit/s、2.0MBit/s、3.0MBit/s和4.0Mbit/s。客户端状态处理和状态信息存储器604监测在输入接口802上已接收的内容数据的速率。客户端决策模块608使用该速率信息来估计可用的网络比特率(或吞吐量)，例如，等于在给定时间段内收到数据的速率的运行平均值。
客户端状态处理和状态信息存储器604还监测已经接收并存储在内容片段和清单存储器606中但尚未解码并尚未呈现给用户的内容片段的数据量。可以将该数据量视为缓冲内容的时长。
客户端决策模块608使用缓冲数据的时长来计算可供下载下一片段的时间。其定义如下：
可供下载的时间＝(缓冲数据的时长)+(下一片段时长)-(最小缓冲时长)(1)
下一片段时长是要下载的下一片段的时长，下一片段一旦被下载就会增加缓冲数据的时长。最小缓冲时长是针对客户端缓冲区设置的数据时长，以试图避免在网络比特率有波动时可能发生的缓冲区下溢和内容播放停顿。然而，太大的缓冲时长将导致大量数据被缓冲，并且播放显著晚于“直播边界”，即在直播之后的很长时间才向用户呈现。
例如，如果缓冲数据时长是16秒，下一片段时长是10秒，而最小缓冲时长是15秒。则可供下载的时间是11秒(16+10-15)。如下所示，假设最初收到16s的数据但是尚未对该数据解码，且各片段的播放时长为10s，那么在接收到下一片段之后，已经下载16s+10s＝26s的数据且尚未解码，由于下载需要一些时间，这些数据中的一部分将被解码。为了在下载下一片段结束时最小缓冲时长为15秒，下载最多可花费26s-15s＝11s。因此，客户端决策模块808计算可供下载下一片段的时间，在此样例中为11s。
然后，客户端决策模块608继续确定可下载的下一片段的最大片段比特率，这取决于可供下载的时间限制与给定的先前估计的网络比特率。例如，如果估计可用网络吞吐量为3.1MBit/s，那么在可用时间(11s)内以该比特率下载的10s时长的片段的最大比特率由下式给出：3.1MBit/s×11s/10s＝3.41MBit/s。
一般来说，此计算如下式所示：
最大片段比特率＝(估计的网络比特率)×(可供下载时间)/(下一片段时长)(2)
在该示例中，客户端决策模块608知道片段在1.3MBit/s、2.0MBit/s、3.0MBit/s和4.5MBit/s比特率可用，其选择不大于所计算的最大片段比特率3.41MBit/s的片段。通常，选择不大于所计算的最大片段比特率的最大的比特率片段。在该示例中，所选择的编码比特率是3.0MBit/s，然后客户端决策模块608在输入接口802上向内容服务器104请求以选定的速率3.0MBit/s编码的、编号为120的下一个内容片段。服务器104将所请求的片段传送至客户端设备。
现在描述仿真结果，该仿真示出了在两种不同的网络比特率场景下的客户端执行的方法的效果。在两种场景下，网络比特率在一段时间内约为3.1MBit/s，因此客户端决策模块808估计可用网络吞吐量是3.1MBit/s。在第一个示例的场景中，网络吞吐量在整个场景期间保持在3.1MBit/s；而在第二个示例的场景中，除了从30s到40s期间降至1.5MBit/s外，网络吞吐量保持在3.1MBit/s。
下表示出了第一个网络场景中具有恒定网络吞吐量的客户端行为。
Figure GDA0002975926320000151
表2
以粗斜体示出描述具有更高观看者重视度的片段(编号为124的片段)的行。可以看出，由于尚未使用观看者重视度信息，所以已经以3.0MBit/s的编码比特率传送所有片段(包括具有更高观看者重视度的片段)。虽然这被认为是可接受的，但是4.5MBit/s的编码比特率也是可用的。如下所述，通过利用包含在清单文件中的观看者重视度信息，可以通过减小其他一些重视度较低的片段的比特率，以4.5MBit/s的编码比特率传送片段124。
以下示例进一步突出了该问题，其中在时间从30s到40s时，网络比特率从3.1MBit/s下降到1.5MBit/s。
Figure GDA0002975926320000161
表3
再次以粗斜体示出描述具有较高观看者重视度的片段(编号为124的片段)的行。可以看出，由于尚未使用观看者重视度信息，具有更高观看者重视度的片段与表中列出的所有片段均以1.3MBit/s的编码比特率的最低质量被传送。这将给观看者带来不好的体验：尽管更低兴趣的前、后片段以可接受的质量被传送，但是具有最高兴趣的片段实际上也已经以低质量被传送。这种情况可以通过检测实际网络比特率进行说明。
在这个例子中，在时间从30s到40s时，网络比特率从3.1MBit/s下降至1.5MBit/s，即，在29.1秒以3.0MBit/s请求片段123之后，直至恰好在传送完成之前。因此，传送花费的时间比客户所预测的更长。当客户端决策模块808对片段124进行计算时，发现可供下载时间仅为7.133s，且所估计的网络比特率现在仅为2.567MBit/s，因此最大片段比特率仅为1.831MBit/s，迫使其选择编码比特率等于1.3MBit/s的片段。
通过本发明以下示例解决了上述问题，其将上述方法修改为考虑清单文件中的观看者重视度信息。当识别到具有较高重视度的片段时，第一解决方案对所估计的网络比特率应用速率缩放因子，并使用缩放的网络比特率来计算最大片段比特率。当识别出较高重视度的片段时，第二种解决方案调整(增加)需要被缓冲的数据量，直到(但不包括)具有较高重视度的片段。现在将更详细地描述这两种解决方案。
图7概括了使用速率缩放因子的第一解决方案的流程图。
在步骤700中，由客户端设备请求清单文件并将其存储在内容片段和清单存储器606中。客户端状态处理和状态信息存储器604监测已在输入接口602上接收数据的速率。在步骤702中，客户端决策模块608使用该速率信息来估计可用网络比特率(或吞吐量)，例如，将可用网络比特率估计为等于在给定时间段内已经接收数据的速率的运行平均值(例如片段时长)。
在步骤704，客户端状态处理和状态信息存储器604还监测已经接收并存储在内容片段和清单存储器606中但尚未解码并尚未呈现给用户的内容片段数据量。可以将该数据量视为缓冲内容时长。
在步骤706中，客户端决策模块608使用缓冲数据时长，以利用等式(1)计算可供下载下一片段的时间。
在步骤708中，客户端决策模块608根据可供下载的时间和所估计的网络比特率确定可下载的下一片段的最大片段比特率。该第一解决方案还对最大片段比特率应用缩放因子(速率缩放因子)，如下所示：
最大片段比特率＝(速率缩放因子)×(所估计的网络比特率)×(可供下载时间)/(下一片段时长)(3)
速率缩放因子在0.0到1.0的范围内，根据与要下载的下一片段相关联的观看者重视度参数，以及可选地根据一个或更多个未来片段，来设置速率缩放因子。
可以以多种方式设想速率缩放因子的影响，包括但不限于：最大片段比特率的缩放；所估计的网络比特率的缩放，其有效地节省了一些网络比特率，以用于被标记为具有更高观看者重视度的片段的后续请求；可供下载的时间的缩放，其有效地节省了一些时间，以用于被标记为具有更高观看者重视度的片段的后续请求。
速率缩放因子的结果是客户端决策模块608可以选择以更低的比特率编码片段，而一旦客户端决策模块608知道即将到来的片段被标记为具有更高观看者重视度，客户端决策模块608将以其它比特率对片段进行编码。
客户端决策模块608可以以多种方式选择速率缩放因子。速率缩放因子可以仅基于与要下载的下一片段相关联的观看者重视度参数值，而不管从清单上可见的未来片段。例如，如果观看者重视度有3个等级(1为低重视度，2为中等重视度，3为高重视度)，那么速率缩放因子也可以设置为3个等级其中之一，当观看者重视度为低(1)时，使用低速率缩放因子(例如0.6)；当观看者重视度为中(2)时，使用较高速率缩放因子(例如0.8)；而当观看者重视度为最高(1)时，使用最高的速率缩放因子(1.0)。
或者，当清单仅示出低重视度的片段时，可以将速率缩放因子设置为固定值(例如1.0)；当清单上出现高重视度的片段时，切换到较低值(例如0.6)；并且当要下载的下一片段是较高重视度的片段时，再次切换到较高值(例如1.0)。
速率缩放因子可以取决于在清单中被标记为具有较高重视度的片段之前被标记为具有更低观看者重视度的片段的数量。例如，可能希望尝试以先前片段或具有较低重视度片段的编码比特率的指定倍数传送具有较高重视度的片段。作为样例，如果目标是以具有较低重视度的先前片段的编码比特率的两倍传送具有较高重视度的片段，并且当首次列出具有较高重视度的片段时，在清单中已经列出三个这样具有较低重视度的片段，且尚未请求这三个片段中的任何一个，则可以设置速率缩放因子(rsf)以使(3×rsf)+(2×rsf)＝4，求解该式得到速率缩放因子rsf＝0.8。该等式是希望在四个片段时长内传送三个降低了速率的片段和一个以降低速率的两倍编码的片段的结果。
速率缩放因子可以取决于清单中被标记为具有更高观看者重视度的片段的数量。例如，相较于在清单中仅列出具有较高重视度的单个片段，当清单中列出的具有更高观看者重视度的片段多于一个时，可能需要使用更小的速率缩放因子。作为样例，如果目标是将清单中列出的具有较高重视度的两个片段以具有较低重视度的前述片段的编码比特率的两倍传送，并且当首次列出具有较高重视度的片段时，在清单中已经列出三个这样具有较低重视度的片段，且尚未请求这三个片段中的任何一个，则可设置速率缩放因子rsf，使得(3×rsf)+(2×2×rsf)＝5，求解该式得到速率缩放因子rsf＝0.714。该等式是希望在五个片段时长内传送三个降低了速率的片段和两个以降低速率的两倍编码的片段的结果。
返回到图7的流程图，在步骤710中，将要下载的下一片段的比特率识别为不大于所确定的最大片段比特率的比特率。因此，如果最大片段比特率(缩放后)被确定为2.2Mbit/s，则所识别的比特率必须是1.3Mbit/s或2.0Mbit/s其中之一。通常，选择不大于最大片段比特率的最高的比特率的片段。
然后，客户端请求所识别的片段，并在步骤712中将其传送。
然后，针对下一片段重复该过程，从步骤700中对下一个清单文件(例如表1中的第二个播放列表文件)的另一个请求开始。
接下来示出当在清单上看不见具有较高重视度的片段时，客户端决策模块608将速率缩放因子设置为1.0，当看见具有较高重视度的片段时，速率缩放因子为恒定值0.60，并且当正在处理具有较高重视度的片段时，速率缩放因子为恒定值1.0。
下表示出了具有恒定网络比特率的网络场景中的客户端行为。
Figure GDA0002975926320000191
表4
再次以粗斜体示出描述具有较高观看者重视度的片段(编号为124的片段)的行。由于在作出请求时，客户端并不知道即将到来的被标记为具有更高观看者重视度的片段，所以如在参考情况中那样，其以编码比特率3.0MBit/s请求编号为120的片段。在对中间片段121、122和123做出决策时，客户端知道了具有更高观看者重视度片段124。在这些片段的情况下，客户端决策模块608应用如上所述的0.60的速率缩放因子来确定最大片段比特率，以及选择以哪种编码比特率请求这些片段。表中的结果表明，以编码比特率2.0MBit/s请求片段121和122，而在参考情况下为3.0MBit/s(参见表2)。如在参考情况中那样，片段123是以相同的编码比特率3.0MBit/s被请求，这是因为已缓冲但尚未解码的数据量明显高于参考情况，因此允许更多时间来下载该片段，从而抵消了速率比率因子的影响。
当对片段124做出决策时，客户端决策模块608应用1.0的速率缩放因子正常工作，但由于已缓冲但尚未解码的数据量高于参考情况，因此以编码比特率4.5MBit/s请求该片段，而参考情况中为3.0MBit/s。然后以3.0MBit/s和4.5MBit/s请求片段125和126。
总体效果是被标记为对于观看者具有较高重视度的片段以4.5MBit/s的编码比特率传送，而不是参考情况下的3.0MBit/s，但这是将片段121和122以较低的编码比特率传送为代价的。然而，考虑到对这些片段的观看者相对的重视度，这算是一个改进的结果。可以考虑将速率缩放因子设置为较高的值，因为以3.0MBit/s而不是4.5MBit/s传送片段126将更好，并且可以利用此网络吞吐量以更高的编码比特率传送片段122，但是这必须与在被标记为对于观看者具有较高重视度的片段被传送之前网络吞吐量可能已经下降的风险平衡。
下表示出了具有可变网络比特率的网络场景中的客户端行为，其中时间从30s到40s，网络比特率从3.1MBlt/s下降到1.5MBit/s。
Figure GDA0002975926320000201
表5
再次以粗斜体示出描述具有较高观看者重视度的片段(编号为124的片段)的行。由于在进行请求时，客户端并不知道即将到来的被标记为对于观看者具有较高重视度的片段124，所以再次以编码比特率3.0MBit/s请求编号为120的片段。
客户端决策模块608针对片段121、122和123做出与上述恒定网络比特率场景相同的决策，因为网络比特率直到时间30s时才会下降到1.5MBit/s，其已部分地传送了片段123。虽然减少的网络吞吐量延迟了片段123的传送，但是由于已经缓冲但尚未解码的数据量(21.113s，假定供下载片段124的时间为16.113s)和所估计的网络比特率2.823MBit/s，客户端决策模块608可以以4.5MBit/s的编码比特率请求片段124。与表3中所示的不使用观看者重视度信息的参考情况相比，更早地请求了片段124，此时更多数据已被缓冲但尚未解码，并且由于使用1.5MBit/s的降低速率的网络的时间更少，因此所估计的网络比特率更高。因此，客户端可以以最高质量而不是最低质量请求具有更高观看者重视度的片段。
图8概述了通过根据一个或更多个片段的观看者重视度参数调整需要在客户端缓冲的数据量的第二解决方案的流程图。
步骤800、802和804对应于图7中的步骤700、702和704，其中在步骤800中请求清单文件，在步骤802中估计网络比特率，以及在步骤804中确定缓冲的内容时长。
然后在步骤806中，客户端决策模块608使用缓冲数据时长来使用等式(1)计算可供下载下一片段的时间，并且进一步应用如下的缓冲调整参数：
可供下载的时间＝(缓冲数据的时长)+(下一片段时长)-(最小缓冲时长)-(缓冲调整)
根据下一片段的观看者重视度参数来设置缓冲调整，并且可选地，进一步根据一个或更多个未来片段来设置缓冲调整。缓冲调整参数可以取正值，并且以秒为单位进行测量。
缓冲调整参数的应用可以被设想为减少可供下载下一片段的时间，从而使得有更多时间可供传送被标记具有更高观看者重视度的片段。
缓冲调整参数可以由客户端决策模块608以多种方式选择。缓冲调整因子可以仅基于要下载的下一片段的观看者重视度参数。例如，如果下一片段的观看者重视度参数为低，则可以应用高缓冲调整(例如6s)，但是如果下一片段的观看者重视度参数为高，则可以应用低缓冲调整(例如2s或甚至0s)。
另选地，如果仅低重视度片段在清单上可见，则缓冲调整可以设置为零，但是在清单上一旦具有更高观看者重视度值的片段出现，则将缓冲调整设置为某一非零值(例如4s)，而当具有较高重视度的片段是将要下载的下一片段时，再次切换到零。
在另一种方法中，缓冲调整参数可以根据在被标记为具有较高重视度的那个片段之前被标记为具有较低观看者重视度的片段的数量来设置，并且特别地，它可以随着被标记为具有较低观看者重视度的各片段而增加，直至被标记为具有较高重视度的片段，此时缓冲调整参数可以设置为零。例如，如果希望以具有较低重视度的前一片段的编码比特率的两倍来传送具有较高重视度的片段，且当首次列出具有较高重视度的片段时，在清单中已经列出三个具有较低重视度的片段且尚未请求这三个片段中的任意一个，如果所有相关片段的片段时长是10s，并且如果缓冲数据的时长等于最小缓冲时长，则设置缓冲调整(ba)以使3×(10-ba)+2×(10-ba)＝40，求解该式得出缓冲调整ba＝2s。该等式是希望以减少的可供下载时间传送三个片段并以这个可供下载的时间的两倍传送一个片段的结果。在这种情况下，假定用于传送具有较低重视度的三个片段中的每一个的标定时间8s并且用于传送具有较高重视度的片段为16s，具有较低重视度的三个片段中的第一片段将具有2s的缓冲调整，第二片段将具有4s的缓冲调整，并且第三片段将具有6s的缓冲调整。
缓冲区调整参数还可以取决于被标记为具有较高观看者重视度的片段的数量。例如，当清单中列出不止一个具有较高观看者重视度的片段时，可能需要使用比在清单中仅列出单个具有较高重视度的片段时更大的缓冲调整。例如，如果希望以具有较低重视度的先前片段的编码比特率的两倍来传送清单中列出的具有较高重视度的两个片段，且当在清单中首次列出具有较高重视度的片段时，已经列出三个具有较低重视度的片段且尚未请求这三个片段中的任何一个，如果所有相关片段的时长是10s，并且如果缓冲数据的时长等于最小缓冲时长，则设置缓冲调整(ba)，以使3×(10-ba)+4×(10-ba)＝50，求解该式得出缓冲调整ba＝2.857s。该等式是希望以减少的可供下载的时间传送三个片段并以这个可供下载的时间的两倍来传送两个片段中的每一个的结果。在这种情况下，假定用于传送具有较低重视度的三个片段中的每一个的标定时间为7.143s并且用于传送具有较高重视度的片段的标定时间为14.286s，具有较低重视度的三个片段中的第一片段将具有2.857s的缓冲调整，第二片段将具有5.714s的缓冲调整，并且第三片段将具有8.571s的缓冲调整，。
客户端决策模块608已经计算了可供下载片段的时间，然后根据等式(2)继续在步骤808中确定最大片段比特率。注意，根据缓冲调整参数的设置，可以有效地减小最大片段比特率。
在步骤810中，将要下载的下一片段的比特率被识别为不大于所确定的最大片段比特率的比特率。因此，如果最大片段比特率被确定为2.2Mbit/s，则识别的比特率必须是1.3Mbit/s或2.0Mbit/s其中之一。通常，选择不超过最大片段比特率的最高的比特率的片段。
然后，客户端请求所识别的片段，并且在步骤812中传送该片段。
然后，针对下一片段重复该过程，从步骤800中对下一个清单文件的另一个请求开始。
接下来示出客户端决策模块608一旦已知即将到来的被标记为具有较高观看者重视度的片段124，则将被标记为具有较低观看者重视度的第一片段121的缓冲调整设置为3s。然后，对于具有较低观看者重视度的各片段，将其缓冲调整增加3s，直至到达具有较高重视度的片段，此时缓冲器调整被设置为零。因此，对于片段122缓冲调整参数设置为6s，并且对于片段123设置为9s，但对于片段124设置为0。
下表示出了具有恒定网络比特率的网络场景中的客户端行为。
Figure GDA0002975926320000231
表6
再次以粗斜体示出描述具有较高观看者重视度的片段(编号为124的片段)的行。由于在作出请求时，客户端并不知道即将到来的被标记为具有对观看者为较高重视度的片段，所以如在参考情况中那样，以编码比特率3.0MBit/s请求编号为120的片段。在对中间片段121、122和123做出决策时，客户端知道了具有较高观众重视度的片段124。在这些片段的情况下，客户端决策模块608应用3s、6s和9s的缓冲调整参数，如如上所述，分别确定可供下载片段121、122和123的时间，并且因此计算各片段的最大片段比特率，然后选择以哪种编码比特率来请求这些片段。表中的结果表明，以3.0MBit/s的编码比特率请求各片段121、122和123，而在参考情况下为2.0MBit/s。
当针对具有较高观看者重视度的片段124做决策时，客户端决策模块608正常工作，缓冲调整参数为零。然而，由于已缓冲但尚未解码的数据量高于参考情况，最大片段比特率更高，因此所请求片段的比特率是4.5MBit/s，而在参考情况下是3.0MBit/s。然后分别以4.5MBit/s和3.0MBit/s请求片段125和126。
总体效果是被标记为具有较高观看者重视度的片段以4.5MBit/s的编码比特率传送，而不是参考情况下的3.0MBit/s，但这是将片段121、122和123以较低的编码比特率传送为代价的。然而，考虑到这些片段的相对的观看者重视度，这算是一个改进的结果。可以考虑将缓冲调整参数设置为更低的值，因为以3.0MBit/s而不是4.5MBit/s的速度传送片段125将更好，并且可以利用此网络吞吐量以较高编码比特率传送较早片段之一，但是这必须与在被标记为具有较高观看者重视度的片段被传送之前网络吞吐量可能已经下降的风险平衡。
下表示出了具有可变网络比特率的网络场景中的客户端行为，其中时间从30s到40s时，网络比特率从3.1MBlt/s下降到1.5MBit/s。
Figure GDA0002975926320000241
表7
再次以粗斜体示出描述具有较高观看者重视度的片段(编号为124的片段)的行。由于在进行请求时，客户端尚不知道即将到来的被标记为对于观看者具有较高重视度的片段，再次以编码比特率3.0MBit/s请求编号为120的片段。
因为网络比特率直到时间30s时才会下降到1.5MBit/s，此时片段123的传送已经完成，客户端决策模块608对于片段121、122和123做出与上述恒定网络比特率场景相同的决策。客户端决策模块608在网络比特率下降之前做出关于片段124的决策，并且这与已经缓冲但尚未解码的大量数据(27.048s，假定供下载片段124的时间为32.048s)一起可以决定以4.5MBit/s的编码比特率请求片段124。
与不使用观看者重视度信息的参考情况相比，更早地请求了片段124，此时有更多数据已被缓冲但尚未解码，并且因为网络比特率尚未下降，所以所估计的网络比特率更高。因此，客户端可以以最高质量而不是最低质量请求具有较高观看者重视度的片段。
在减少网络吞吐量期间(从30s到40s)，片段124的传送受到影响，使得传送花费了19.7s(从29.2s到48.9s)。但由于传送开始较早，大量数据被缓冲但尚未解码，所以这不是问题。结果是以更低的编码比特率请求和接收先前的片段。
通过客户端决策模块608对下一片段125作出决策的时间，缓冲的数据量回到更正常的水平，如在参考情况中那样，以3.0MBit/s的比特率进行请求。
现在接下来描述可以实现本发明的示例的一些其他方式。
首先，还可以使用基于全双工HHTP的协议来实现本发明的示例。
已知使用HTTP的自适应比特率内容传送的传统方法具有显着延迟，该传送方法使用诸如Apple HLS、MPEG DASH和Microsoft SmoothStreaming之类的协议，对于直播服务这是不期望的，并且特别是对于体育内容的直播而言。该延迟部分是由于客户端必须等待片段内容被通知为可用。例如，在使用Apple HLS时，必须等到新片段被列在更新的播放列表文件中，然后才能请求该新片段。使用MPEG DASH，客户端需要从清单文件(MPD)中的定时信息及其自身时钟，并与错误余量(margin for error)一起确定新的片段变为可用时，才能请求它。
行业中正在解决在能够提出请求之前必须确切知道某个片段何时可用的问题。特别是，正在开发标准IS 23009-6“基于全双工HTTP协议(FDH)的DASH”以提供解决方案。
该方法是通过利用诸如HTTP/2和WebSocket等Internet协议的新特性和功能，通过HTTP 1.1增强现有的MPEG-DASH机制。这些允许服务器发起的业务和客户端发起的业务、数据请求取消和多个数据响应的多路复用，这些都可以用于减少延迟。
在这种情况下，内容客户端108发起媒体信道，通过该媒体信道内容服务器104可以使用例如HTTP/2服务器推送或WebSocket消息将数据主动地推送到内容客户端108。媒体信道经由HTTP/1.1协议升级机制建立。在升级之后，内容客户端108利用URI和推送策略向内容服务器104请求媒体片段或清单文件，该URI和推送策略指示内容服务器104应该如何将媒体传送至内容客户端108，例如，它是应该由内容服务器104发起还是由内容客户端108发起。当内容服务器104已经接收到请求时，它响应于所请求的数据并初始化在推送策略中定义的推送循环。
例如，内容客户端108首先利用推送策略请求清单文件，并且当接收到清单文件时，内容客户端108利用片段推送策略向内容服务器104请求视频片段。然后，内容服务器104以所请求的第一个视频片段进行响应，然后按照片段推送策略中所指示的推送循环进行响应。通常，内容客户端108在接收到最小数据量之后开始解码和播放内容，并在内容服务器104推送内容时继续解码和播放内容，直至媒体流会话结束。
在这种情况下，对于推送到内容客户端108的各片段，内容服务器104可以从内容的编码比特率集合中选择编码比特率。可以在不使用本发明的情况下做出该决策，本发明即考虑到对到内容客户端108的网络吞吐量的估计以及由内容客户端108接收和缓冲但尚未解码的数据量的估计。
另外，内容服务器104可以使用各片段的观看者重视度的知识做出该决策，选择以更高比特率编码那些被标记为具有较高观看者重视度的片段，并选择以较低比特率编码那些被标记为具有较低观看者重视度的片段，使用与上述做出决策的内容客户端108的情况基本相同的方法。
此外，发送观看者重视度信号不限于将其包括在清单文件中。可以以多种不同方式向内容客户端108发送观看者重视度信号。
在一种方法中，用当前片段的内容片段数据发送所有或一些即将到来的片段的观看者重视度信息。当内容片段数据使用MPEG-2传送流格式(如在IS 13818-1中所规定的)时，可以在例如具有特定PID(分组标识符，MPEG-2传送流包头中的字段)的分组流中携带观看者重视度信息，这与用于音频或视频数据不同，其使用可以向一组片段编号发送观看者重视度信息信号的语法。或者，可以使用MPEG-2传送流描述符中的类似语法来携带观看者重视度信息，可以在MPEG-2传送流中定期包括的PSI表(例如，节目映射表)中找到MPEG-2传送流描述符。或者，可以使用类似的语法，在编码的媒体流之一中携带观众重视度信息，例如，在编码的视频流中，使用例如H.264或H.265编码的视频流中的补充增强信息(SEI)消息。
当内容片段数据使用如IS 14496-12中所规定的ISO基本媒体文件格式时，可以如上所述，在编码媒体流中携带观看者重视度信息，或者可以使用，例如，由针对一组片段编号发送观看者重视度信息信号的语法定义的特定“盒子(box)”，以文件格式本身携带观看者重视度信息。
在另一种方法中，在独立于清单文件的文件中发送所有或一些即将到来的片段的观看者重视度信息信号，但是其位置信号可以在清单文件中发送或在内容片段数据中发送。该文件可以包含内容的所有观看者重视度信息，因此仅需要由了解观看者重视度信息的内容客户端108检索一次。或者它可能仅包含针对少数即将到来的片段的观看者重视度信息，在这种情况下，需要由了解观看者重视度信息的内容客户端108重复接收文件，其中每个更新可以具体由内容客户端108请求，或在推送会话初始化之后由内容服务器104推送。
虽然已经参考HLS播放列表形式的清单文件描述了上述示例，但是也可以替代地使用MPEG DASH清单。
与Apple HLS不同，当使用MPEG DASH,23009-1时，通常仅在接收和播放一段媒体内容时开始请求被称作媒体呈现描述(MPD)的清单文件。视频点播用例可以通过MPD来处理，该MPD为每种媒体类型(音频、视频等)的每个编码比特率指定单个文件的位置。直播用例以及视频点播用例可以通过MPD来处理，该MPD使用模板格式为每种媒体类型的每个编码比特率指定一系列文件的位置。
当使用MPEG DASH时，可以以多种不同方式发送观看者重视度信息的信号，包括但不限于以下示例。
如上所述，可以在内容数据片段中发送观看者重视度信息的信号。
可以在从MPD引用的文件中发送观看者重视度信息的信号，该文件包含整个媒体内容项的所有观看者重视度信息并且仅被请求一次，或者包含针对少量即将到来的内容片段的观看者重视度信息，其要么被多次请求，要么在推送会话中被请求一次，并且内容服务器104在文件可用时将对文件的更新推送到内容客户端108。
以下是指示观看者重视度信息的位置的示例MPD。已经以粗斜体示出相关系列，以使其易于识别。
<？xml vers ion＝″1.0″encoding＝″UTF-8″？>
＜MPD
xmlns：xsi＝″http：//www.w3.org/2001/XMLSchema-inetance″
xmlns-″urn：mpeg：DASH：schema：MPD：2011″
xsi：schemaLocation＝〞urn：mpeg：DASH：schema：MPD：2011″
type＝″static″
mediaPresentationDuration＝″PT7199S″
minBufferTime＝″PT1.2S″
profiles＝″urn：mpeg：dash：profile：isoff-on-demand：2011〞>
<BaseURL>http：//example.com/</BaseURL>
＜ViewerInterestURL＞http：//example.com/ViewerInterest.xm1＜/ViewerInterestURL>
,Period>
<！--Audio-->
<AdaptationSetmimeType＝〞audio/mp4〞codecs＝〞mp4a.0x40〞lang＝〞en〞
SubsegmentAlignment＝〞true〞>
＜Representationid-〞1〞bandwidth-〞64000〞>
<BaseURL>audio_content.mp4</BaseURL>
</Representation>
</AdaptationSet>
<！--Video-->
<AdaptationSetmimeType＝〞video/mp4″codecs＝〞avc1.4d0228〞
SubsegmentAlignment＝〞true〞>
<Representationid＝〞2〞bandwidth＝〞1300000〞width＝〞720〞
height＝〞360〞>
<BaseURL＞viddeo_content_at_1M3.mp4</BaseURL>
</Representation>
＜Representation id＝〞3〞bandwidth＝〞2000000〞width＝〞960″
height＝〞540〞＞
<BaseURL>video_content_at_2M0.mp4</BaseURL>
</Representation>
<Representation id＝〞4〞bandwidth＝〞3000000〞width＝〞1440〞
height＝〞720″>
＜BaseURL>video_content_at3M0.mp4</BaseURL>
</Representation>
<Representation id＝″5″bandwidth＝〞4530000〞width＝〞1440〞
height＝″720〞>
<BaseURL>video_content_at_4M5.mp4</BaseURL>
＜/Representation>
＜/AdaptationSet>
＜/Period>
<MPD>
可以在MPD内明确地发送观众重视度信息的信号，例如，用于视频点播用例。这可以通过各种编码选项以多种不同方式发出信号。以下是MPD示例，其包括作为文本串的观看者重视度信息，各片段具有一个字符，每个字符的十进制解释指示了观看者重视度。已经以粗斜体示出相关行，以使其易于识别。请注意，为简洁起见，字符串已缩短为仅明确示出前三个值和后两个值，而在实践中，各片段都有一个值。
＜？xml version＝″1.0″encoding＝″UTF-8″？＞
＜MpD
xmlns：xsi＝″http：//www.w3.org/2001/XMLSchema-instance″
xmlns＝〞urn：mpeg：DASH：schema：MPD：2011〞
xsi：schemaLocation＝〞urn：mpeg：DASH：schema：MPD：2011〞
type＝″static″
mediaPresentationDuration＝″PT7199S″
minBufferTime＝〞PT1.2S〞
profiles＝〞urn：mpeg：dash：profile：isoff-on-demand：2011″＞
＜BaseURL＞http：//example.com/＜/BaseURL＞
viewerInterest＝〞121...21〞
＜Period＞
＜！--Audio--＞
＜AdaptationSet mimeType＝〞audio/mp4″codecs＝″mp4a.0x40〞lang＝″en″
SubsegmentAlignment＝〞true″＞
＜Representation id＝″1〞bandwidth＝″64000〞＞
＜BaseURL＞audio_content.mp4＜/BaseURL＞
＜/Representation＞
＜/AdaptationSet＞
＜！--Video--＞
＜AdaptationSet mimeType＝″video/mp4″codecs＝″avc1.4d0228〞
SubsegmentAlignment＝″true〞＞
＜Representation id＝″2″bandwidth＝″1300000″width＝″720″
height＝″360″＞
＜BaseURL＞video_content_at_1M3.mp4＜/BaseURL＞
＜/Representation＞
＜Representation id＝″3〞bandwidth＝″2000000″width＝〞960〞
height＝〞540〞＞
＜BaseURL＞video_content_at_2M0.mp4＜/BaseURL＞
＜/Representation＞
＜Representation id＝〞4〞bandwidth＝〞3000000〞width＝〞1440〞
heiqht＝〞720〞＞
＜BaseURL＞video_content_at_3M0.mp4＜/BaseURL＞
＜/Representation＞
＜Representation id＝〞5″bandwidth＝″4500000〞width＝〞1440〞
height＝〞720〞＞
＜BaseURL＞video_content_at_4M5.mp4＜/BaseURL＞
＜/Representation＞
＜/AdaptationSet＞
＜/Period＞
＜/MPD＞
通常，在此应注意，虽然以上描述了本发明的示例，但是在不脱离所附权利要求限定的本发明的范围的情况下，可以对所描述的示例进行若干变化和修改。本领域技术人员将认识到对所述实施方式的修改。

Claims (9)

1.一种将视频内容从服务器传送至客户端设备的方法，所述视频内容包括片段序列，并且其中，各片段以多个比特率编码，所述方法包括以下步骤：
a)在所述客户端设备处接收关于各片段的信息，其中，所述信息包括所述比特率和与各片段相关联的观看者重视度参数；
b)估计所述服务器和所述客户端设备之间的网络比特率；
c)根据与第一片段相关联的观看者重视度参数来设置缓冲调整参数；
d)根据所估计的网络比特率、所述缓冲调整参数和在所述客户端设备处缓冲的视频内容的时长确定最大片段比特率；
e)通过对所确定的最大片段比特率应用速率缩放因子来缩放所述最大片段比特率，其中，所述速率缩放因子取决于与所述第一片段相关联的观看者重视度参数；
f)识别用于所述第一片段的比特率，该比特率不大于缩放后的最大片段比特率；
g)将所识别的第一片段传送到所述客户端设备。
2.根据权利要求1所述的方法，其中，对所述片段序列中的第二片段重复步骤a)至g)。
3.根据权利要求1或2所述的方法，其中，当与所述第一片段相关联的观看者重视度参数为低时，所识别的用于所述第一片段的比特率为低，并且当与所述第一片段相关联的观看者重视度参数为高时，所识别的用于所述第一片段的比特率为高。
4.根据权利要求1所述的方法，其中，所识别的比特率还取决于与另一片段相关联的观看者重视度参数。
5.根据权利要求4所述的方法，其中，当与所述第一片段相关联的观看者重视度参数低于与所述另一片段相关联的观看者重视度参数时，所识别的用于所述第一片段的比特率较低。
6.根据权利要求1所述的方法，其中，当所述第一片段的观看者重视度参数为低时，所述速率缩放因子为低；并且当所述第一片段的观看者重视度参数为高时，所述速率缩放因子为高。
7.根据权利要求6所述的方法，其中，所述速率缩放因子还取决于与另一片段相关联的观看者重视度参数。
8.根据权利要求7所述的方法，其中，当与所述第一片段相关联的观看者重视度参数低于与所述另一片段相关联的观看者重视度参数时，用于所述第一片段的速率缩放因子较低。
9.根据权利要求1所述的方法，其中，所述关于各片段的信息在清单文件中被接收。
CN201780060188.0A 2016-09-30 2017-09-29 将视频内容从服务器传送至客户端设备的方法 Active CN109792547B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
EP16250017.7 2016-09-30
EP16250017 2016-09-30
EP16250016.9 2016-09-30
EP16250016 2016-09-30
PCT/EP2017/074890 WO2018060488A1 (en) 2016-09-30 2017-09-29 Viewer importance adaptive bit rate delivery

Publications (2)

Publication Number Publication Date
CN109792547A CN109792547A (zh) 2019-05-21
CN109792547B true CN109792547B (zh) 2021-09-24

Family

ID=60022081

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201780060188.0A Active CN109792547B (zh) 2016-09-30 2017-09-29 将视频内容从服务器传送至客户端设备的方法
CN201780059978.7A Active CN109792546B (zh) 2016-09-30 2017-09-29 从服务器向客户端设备传送视频内容的方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201780059978.7A Active CN109792546B (zh) 2016-09-30 2017-09-29 从服务器向客户端设备传送视频内容的方法

Country Status (4)

Country Link
US (2) US10931993B2 (zh)
EP (2) EP3520422B1 (zh)
CN (2) CN109792547B (zh)
WO (2) WO2018060490A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109792547B (zh) 2016-09-30 2021-09-24 英国电讯有限公司 将视频内容从服务器传送至客户端设备的方法
EP3520420B1 (en) 2016-09-30 2022-11-02 British Telecommunications public limited company Viewer importance adaptive bit rate delivery
US10880354B2 (en) * 2018-11-28 2020-12-29 Netflix, Inc. Techniques for encoding a media title while constraining quality variations
WO2021064664A1 (en) * 2019-10-04 2021-04-08 Enensys Expway Method for broadcasting dash/hls hybrid multimedia streams
US11277461B2 (en) * 2019-12-18 2022-03-15 The Nielsen Company (Us), Llc Methods and apparatus to monitor streaming media
US11570517B2 (en) * 2020-06-23 2023-01-31 Tencent America LLC Application intended interactive selection information for interactive playback of dash content
FR3124672A1 (fr) * 2021-06-24 2022-12-30 Orange Gestion du téléchargement progressif adaptatif d’un contenu numérique en mode économiseur d’écran

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102783170A (zh) * 2010-03-05 2012-11-14 汤姆森特许公司 自适应流传输系统中的比特率调整

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6771644B1 (en) 1999-09-17 2004-08-03 Lucent Technologies Inc. Program insertion in real time IP multicast
US6665705B1 (en) * 1999-10-19 2003-12-16 International Business Machines Corporation Method and apparatus for proxy replication
US7594249B2 (en) * 2001-05-04 2009-09-22 Entropic Communications, Inc. Network interface device and broadband local area network using coaxial cable
US8392952B2 (en) 2002-05-03 2013-03-05 Time Warner Cable Enterprises Llc Programming content processing and management system and method
US7792984B2 (en) * 2003-01-23 2010-09-07 International Business Machines Corporation Systems and methods for the distribution of bulk data using multicast routing that mitigates network traffic on subnets
US20080037420A1 (en) 2003-10-08 2008-02-14 Bob Tang Immediate ready implementation of virtually congestion free guaranteed service capable network: external internet nextgentcp (square waveform) TCP friendly san
US7430222B2 (en) * 2004-02-27 2008-09-30 Microsoft Corporation Media stream splicer
US8135040B2 (en) * 2005-11-30 2012-03-13 Microsoft Corporation Accelerated channel change
US20080098420A1 (en) * 2006-10-19 2008-04-24 Roundbox, Inc. Distribution and display of advertising for devices in a network
US20090025027A1 (en) * 2007-07-20 2009-01-22 Michael Craner Systems & methods for allocating bandwidth in switched digital video systems based on interest
US8316409B2 (en) * 2007-10-11 2012-11-20 James Strothmann Simultaneous access to media in a media delivery system
US8578432B2 (en) * 2007-12-07 2013-11-05 Cisco Technology, Inc. Policy control over switched delivery networks
US9094140B2 (en) * 2008-04-28 2015-07-28 Time Warner Cable Enterprises Llc Methods and apparatus for audience research in a content-based network
CN101282479B (zh) 2008-05-06 2011-01-19 武汉大学 基于感兴趣区域的空域分辨率可调整编解码方法
JP5167412B2 (ja) 2008-07-03 2013-03-21 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｔｖ放送システムにおける高速チャネル切り替え
US8014393B1 (en) 2008-08-05 2011-09-06 Cisco Technology, Inc. Bandwidth optimized rapid channel change in IP-TV network
US8112781B2 (en) 2008-10-07 2012-02-07 General Instrument Corporation Content delivery system having an edge resource manager performing bandwidth reclamation
US8321887B2 (en) * 2008-11-10 2012-11-27 Time Warner Cable Inc. Displaying enhanced advertisements simultaneously across substantially all channels
CN101420618B (zh) * 2008-12-02 2011-01-05 西安交通大学 基于感兴趣区域的自适应可伸缩视频编解码结构设计方法
CN101494785B (zh) 2008-12-19 2012-05-09 无锡云视界科技有限公司 一种h.264感兴趣区域编码的方法
US8949888B2 (en) * 2008-12-30 2015-02-03 Verizon Patent And Licensing Inc. Systems and methods for efficient messaging and targeted IP multicast advertisement in communication networks
WO2010111261A1 (en) 2009-03-23 2010-09-30 Azuki Systems, Inc. Method and system for efficient streaming video dynamic rate adaptation
CA2774363C (en) * 2009-09-15 2020-06-23 Comcast Cable Communications, Llc Dynamic content packaging
US10264029B2 (en) 2009-10-30 2019-04-16 Time Warner Cable Enterprises Llc Methods and apparatus for packetized content delivery over a content delivery network
US10003851B2 (en) 2009-11-24 2018-06-19 Imagine Communications Corp. Managed multiplexing of video in an adaptive bit rate environment
US9158769B2 (en) * 2009-12-28 2015-10-13 Adam Dunstan Systems and methods for network content delivery
US9143813B2 (en) 2010-02-11 2015-09-22 Beaumaris Networks Inc. Multi-video-service bandwidth allocation
JP5569053B2 (ja) * 2010-03-11 2014-08-13 ソニー株式会社 コンテンツ配信装置、コンテンツ配信方法および送信サーバ
WO2011139305A1 (en) * 2010-05-04 2011-11-10 Azuki Systems, Inc. Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction
US9021119B2 (en) * 2011-01-06 2015-04-28 Sonic Ip, Inc. Systems and methods for performing adaptive bitrate streaming based upon the delay of each stream and the channel rate
GB2490659A (en) 2011-05-04 2012-11-14 Nds Ltd Fast channel change using channel packs comprising independently decodable frame segments having differing qualities
US9615126B2 (en) * 2011-06-24 2017-04-04 Google Technology Holdings LLC Intelligent buffering of media streams delivered over internet
US9380079B2 (en) 2011-06-29 2016-06-28 Cable Television Laboratories, Inc. Content multicasting
US8676995B1 (en) * 2011-07-07 2014-03-18 Cisco Technology, Inc. System and method for enabling pairing of a companion device with a mate device for performing a companion service
US10320869B2 (en) 2011-07-07 2019-06-11 Telefonaktiebolaget Lm Ericsson (Publ) Network-capacity optimized adaptive HTTP streaming
US9264508B2 (en) 2011-08-19 2016-02-16 Time Warner Cable Enterprises Llc Apparatus and methods for reduced switching delays in a content distribution network
US9445136B2 (en) * 2011-09-21 2016-09-13 Qualcomm Incorporated Signaling characteristics of segments for network streaming of media data
US9197907B2 (en) 2011-10-07 2015-11-24 Ericsson Ab Adaptive ads with advertising markers
US9485526B2 (en) 2012-07-16 2016-11-01 Time Warner Cable Enterprises Llc Multi-stream shared communication channels
US10708335B2 (en) 2012-11-16 2020-07-07 Time Warner Cable Enterprises Llc Situation-dependent dynamic bit rate encoding and distribution of content
KR101716071B1 (ko) * 2013-02-27 2017-03-13 애플 인크. 적응적 스트리밍 기법
US9621902B2 (en) 2013-02-28 2017-04-11 Google Inc. Multi-stream optimization
US9066153B2 (en) * 2013-03-15 2015-06-23 Time Warner Cable Enterprises Llc Apparatus and methods for multicast delivery of content in a content delivery network
US9402107B2 (en) 2013-03-15 2016-07-26 Time Warner Cable Enterprises Llc Apparatus and methods for delivery of multicast and unicast content in a content delivery network
US20140282792A1 (en) 2013-03-15 2014-09-18 Cygnus Broadband, Inc. Video streaming with buffer occupancy prediction based quality adaptation
US10242462B2 (en) 2013-04-02 2019-03-26 Nvidia Corporation Rate control bit allocation for video streaming based on an attention area of a gamer
US9693118B2 (en) 2013-05-29 2017-06-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for prioritizing adaptive bit rate distribution of content
US10230950B2 (en) 2013-05-30 2019-03-12 Intel Corporation Bit-rate control for video coding using object-of-interest data
US8850055B1 (en) 2013-09-17 2014-09-30 Google Inc. Intelligently streaming portions of media at higher quality over a limited bandwidth connection
WO2015051846A1 (en) 2013-10-10 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Optimized adaptive streaming
CN105227535B (zh) 2014-07-01 2019-12-06 思科技术公司 用于边缘缓存和客户端设备的装置及方法
US10498790B2 (en) 2014-08-07 2019-12-03 Arris Enterprises Llc Systems and methods for multicast delivery of a managed bundle in service provider networks
US9948539B2 (en) 2014-08-29 2018-04-17 The Nielsen Company (Us), Llc Methods and apparatus to predict end of streaming media using a prediction model
US10749918B2 (en) * 2014-11-10 2020-08-18 Avago Technologies International Sales Pte. Limited Adaptive streaming with early client indication
US9788028B2 (en) 2015-03-27 2017-10-10 Ericsson Ab System and method for providing guaranteed channel content in a switched digital video network using multicast ABR streaming
KR102170046B1 (ko) 2016-06-29 2020-10-27 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 적응형 멀티미디어 스트리밍의 품질 추정
US11677799B2 (en) * 2016-07-20 2023-06-13 Arris Enterprises Llc Client feedback enhanced methods and devices for efficient adaptive bitrate streaming
EP3520420B1 (en) 2016-09-30 2022-11-02 British Telecommunications public limited company Viewer importance adaptive bit rate delivery
CN109792547B (zh) 2016-09-30 2021-09-24 英国电讯有限公司 将视频内容从服务器传送至客户端设备的方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102783170A (zh) * 2010-03-05 2012-11-14 汤姆森特许公司 自适应流传输系统中的比特率调整

Also Published As

Publication number Publication date
EP3520422A1 (en) 2019-08-07
US10931993B2 (en) 2021-02-23
CN109792547A (zh) 2019-05-21
US20200037012A1 (en) 2020-01-30
EP3520421A1 (en) 2019-08-07
US11044507B2 (en) 2021-06-22
CN109792546B (zh) 2022-01-04
US20200037017A1 (en) 2020-01-30
WO2018060488A1 (en) 2018-04-05
EP3520421B1 (en) 2023-03-22
CN109792546A (zh) 2019-05-21
EP3520422B1 (en) 2022-11-02
WO2018060490A1 (en) 2018-04-05

Similar Documents

Publication Publication Date Title
CN109792545B (zh) 从服务器向客户端装置传送视频内容的方法
CN109792547B (zh) 将视频内容从服务器传送至客户端设备的方法
US11470405B2 (en) Network video streaming with trick play based on separate trick play files
US9756369B2 (en) Method and apparatus for streaming media data segments of different lengths wherein the segment of different length comprising data not belonging to the actual segment and beginning with key frames or containing key frames only
US9247317B2 (en) Content streaming with client device trick play index
KR101837687B1 (ko) 콘텐트의 품질을 결정하는 복수의 인자에 기초한 적응적인 스트리밍 방법 및 장치
US20140359678A1 (en) Device video streaming with trick play based on separate trick play files
CN116074296A (zh) 用于编码视频内容的系统和方法
US9706240B2 (en) Methods and systems for content control
US20140297804A1 (en) Control of multimedia content streaming through client-server interactions
US20140344852A1 (en) Advanced streaming playback/dynamic ad insertion
WO2014193996A2 (en) Network video streaming with trick play based on separate trick play files
CA2842810C (en) Fragmenting media content
US20160029076A1 (en) Arrangements and Method Thereof for Channel Change during Streaming
CA3088533A1 (en) Methods and systems for low latency streaming
US20190253738A1 (en) Method for processing encoded data, method for receiving encoded data, devices, and associated computer programs
US20210168472A1 (en) Audio visual time base correction in adaptive bit rate applications

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant