观看者重视度自适应比特率传送的制作方法

本发明涉及通过网络传送媒体的领域，尤其涉及考虑观看者重视度而将媒体传送到客户端设备的方法。

背景技术：

针对视频内容的单播传送，自适应比特率传送变得越来越普遍，该视频内容的单播传送使用包括applehttplivestreaming(hls)和microsoftsmoothstreaming在内的专有技术，并使用标准化的mpegdash(http上的动态自适应流传输)协议。

自适应比特率流基于将内容划分为短片段的概念，通常，该短片段的时长为4至10秒，每个片段以多个不同的比特率进行编码(因此具有不同质量)，以便客户端设备使用httpget请求来取得内容。所请求的片段的比特率(质量)是基于最近网络上实现的吞吐量以及已经传送并在客户端设备处缓冲而等待显示的数据量而确定的。

自适应比特率传送的当前实现方式对所有的片段进行同样的处理。因此，某些片段可能以观看者可接受的质量(比特率)传送，但是其它片段可能以观看者不可接受的质量(比特率)传送。

技术实现要素：

本发明的实施方式的目的是提供一种向客户端设备传送媒体文件的改进方法。

根据本发明的一个方面，提供了一种从服务器向客户端设备传送视频内容的方法，所述视频内容包括片段的序列，并且其中以多个比特率编码每个片段，所述方法包括：

a)在所述客户端设备处接收关于每个片段的信息，其中所述信息包括比特率和与每个片段相关联的观看者重视度参数；

b)估计所述服务器和所述客户端设备之间的网络比特率；

c)确定在所述客户端设备处缓冲的视频内容的时长；

d)根据与第一片段相关联的所述观看者重视度参数，对所述客户端设备处缓冲的视频内容的时长进行调整；

e)根据所估计的所述网络比特率以及在所述客户端设备处调整的缓冲内容的时长确定最大片段比特率；

f)识别用于所述第一片段的比特率，所述比特率不大于所述最大片段比特率；

g)将所识别的第一片段传送到所述客户端设备。

当第一片段的观看者重视度参数低时，所述调整大。

所述调整可能还取决于与另一个片段相关联的观看者重视度参数。并且当与第一片段相关联的观看者重视度参数低于与另一个片段相关联的观看者重视度参数时，对第一片段的调整可以更大。

可以在清单文件中接收关于每个片段的信息。

重要的是认识到本发明的示例涉及片段的优先化，以试图确保以更高的质量传送观看者最感兴趣的片段。片段具有指示该片段的相对重视度的相关联的观看者重视度参数，并且片段的传送是根据其相对的观看者重视度而被有效地按优先顺序处理。

本发明的示例并不是关于通用数据流量的优先化(其中一个流优先于另一个流)，这或是由于流在整体上更有价值或更具时效性，或是由于特定流接近耗尽而引起播放拖延。它也并不是要确保要求较高的流(例如体育节目)比要求较低的流(例如戏剧节目)具有更高的网络吞吐量。

一个示例是一些体育赛事，其中最感兴趣的短时间段被不太感兴趣的长时间段分开。例如，在棒球和板球中，观看者会非常感兴趣从投手/投球手放开球之前开始的短时间段，但这仅持续几秒，而在下一次这样的比赛之前会有一段相当不感兴趣的时间。显然，该示例不限于体育内容，其还包括但不限于，游戏节目、真人秀节目、戏剧和新闻。

附图说明

为了更好地理解本发明，现仅通过示例的方式参考附图，其中：

图1是示出了本发明一个示例中的系统的网络图；

图2是本发明一个示例中的内容生成器的框图；

图3是本发明另一个示例中的内容生成器的框图；

图4是本发明另一个示例中的内容生成器的框图；

图5是本发明一个示例中的内容服务器的框图；

图6是本发明一个示例中的内容客户端的框图；

图7示出了使用速率比例因子的示例方法；以及

图8示出了使用缓冲器调整的示例方法。

具体实施方式

这里参考特定示例描述了本发明。然而，本发明不限于这些示例。

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

图1是示出了系统100的简化网络图，该系统100包括与内容服务器104通信的内容生成器102。内容生成器102负责接收未压缩的视频内容(例如电视直播)以及编码和封装该视频内容，以传给内容服务器104。内容服务器104负责存储接收的视频内容，并且根据请求将该内容传送到通过网络106连接的适当配置的客户端。该示例中示出了三个客户端设备108、110和112。例如，客户端可以是标准http自适应比特率流客户端、适于支持mpegdash或apple的hls。客户端用于发现视频内容、请求并处理清单文件、请求视频片段并处理这些片段以供观看。虽然视频内容可以通过网络106直接传送到这些客户端，但是也可以通过每个客户端本地的代理来进行传送。

内容生成器102包括用于将元数据插入其生成的清单文件中的机制，该元数据包括：针对编码内容的每个片段，将观看者重视度参数以信号形式报知给最终用户的数据，观看者重视度参数指示内容的重要性且由片段中编码的视频和音频数据表示。

应注意，术语“重视度”和“兴趣”在说明书中可互换使用。因此，对观看者重视度参数的引用等同于对观看者兴趣参数的引用。

在图2更详细地示出了内容生成器102。内容生成器102包括视频编码器206、音频编码器208、分段模块210、封装模块212和输出接口214。内容生成器102接收包括未压缩视频流202和未压缩音频流204的未压缩视频内容。具体地，视频编码器206获取未压缩视频流202，并对该视频进行编码以生成编码视频流。在本例中，所使用的视频编码方法符合itu-th.264标准，但是本发明并不限于此标准，而是可以使用其它编码方法。类似地，音频编码器208获取未压缩音频流204，并对该音频进行编码以生成编码音频流。在本例中，音频编码方法是mpeg-4heaacv2，但是本发明并不限于此标准，而是可以替代地使用其它编码方法。以多个比特率对未压缩视频流进行编码(通常仅以一个比特率对相关联的未压缩音频流进行编码，但也可以以多个比特率进行编码)，从而对于每个比特率生成编码流。不同的比特率在效果上导致不同的视频质量，较高的比特率编码导致较高的视频质量，较低的比特率导致较低的视频质量。编码视频流包括多个帧或画面，这些帧或画面又可以聚类成画面组或gop。

编码视频流和编码音频流(或者在以多个比特率对内容进行编码情况下的每个编码视频流和编码音频流)被分段模块210分段为离散的(视频和音频)时间片段。可以设想，每个时间片段为未压缩视频/音频的时长中的2至15秒之间，但也可以使用更长或更短的时长。虽然图中显示分段模块210是在编码器206和208之后操作，但是可以在编码之前对未压缩的视频流和音频流进行分段。因此，可以首先对未压缩视频和音频进行分段，然后可以对得到的未压缩片段进行编码，以生成编码视频和音频片段。

分段模块210可以在考虑服务要求的情况下选择片段时长。例如，较短的片段允许在具有不同编码比特率的流之间进行切换，以更快地出现，并且将允许以更精细的时间粒度来报知观看者重视度数据。但是，较长的片段更容易被系统组件处理(特别是通过cdn(内容分发网络)节点)，但可能会对报知观看者重视度数据的变化的频率产生负面影响，可能导致编码比特率之间的切换较慢，并可能在直播服务时引入更多端到端的延迟。通过选择每个片段的时长而不是使用固定值，可以选择片段时长，从而选择片段边界，使得它们与观看者重视度数据的变化一致，以同时实现名义上较长的片段时长和以精细的时间粒度来通报观看者重视度数据。

视频和音频片段由封装模块212处理。在一些实施例中，封装模块212的输出是所谓的多路复用格式，例如is13818-1中规定的mpeg-2传输流(mpeg-2transportstream)。mpeg-2传输流通常用于实时传送数字电视。mpeg-2传输流的片段也可用于apple的hls。在其它实施例中，封装模块的输出可以是所谓的非多路复用格式，例如is14496-12中规定的iso基本媒体文件格式(isobasemediafileformat)。这种格式的片段称为mp4片段。

本领域技术人员将理解，由编码器、分段模块和封装模块执行的功能可以由单个适当配置的通用视频编码器模块执行。

封装模块212还生成清单文件，该清单文件描述编码内容(在本示例中为传输流片段)以及如何获得编码内容，并将该文件传给内容服务器104。当使用mpeg-dash，is20009-1时，清单文件被称为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，它们分别执行解码操作并输出解码视频和解码音频。当内容片段已被解码并呈现给用户时，将该内容片段从内容片段和清单存储器606中移除。因此，内容片段和清单存储器606是充当接收的片段的缓冲器，直到接收的片段被解码器取得以用于解码和播放为止。

状态处理和状态信息存储器604监视在输入接口602上接收内容数据的速率、内容被解码并通过视频解码器610和音频解码器612呈现给用户的速率、以及接收并存储在内容片段和清单存储器606中但尚未解码并呈现给用户的内容片段数据量。

客户端决策模块608处理清单文件中的元数据和已经计算并存储在状态处理和状态信息存储器604中的状态信息，以确定接下来以哪种编码比特率或质量等级从内容服务器104请求哪个内容片段。然后，客户端决策模块608在输入接口602上向内容服务器104发出对内容片段的请求。

在一个示例中，内容请求采用针对每个片段的http请求的形式，其由内容服务器104处理，以将内容传送到客户端108。在一些实施例中，每个单个内容请求导致传送单个内容片段，而在其它实施例中，单个内容请求可以导致使用httppush协议传送多个内容片段。

清单文件中包括的元数据可以包括但不限于：每个片段的比特率、每个片段的时长以及每个片段的观看者重视度。这些数据项中的每一个对于整个内容片段(例如电影)中的每个片段都可以是不同的，或者也可以在较长时长或整个内容片段期间保持不变。在一个示例中，对于给定质量等级的每个编码片段，比特率是相同的，即所谓的恒定比特率编码。在另一个实施例中，对于给定质量等级的每个编码片段，比特率可以是不同的，使得在给定质量等级下，每个片段的感知质量接近于恒定，即所谓的恒定质量编码。每个片段的时长可以是恒定的，或者片段时长可以是可变的，例如，片段的边界与观看者重视度数据的变化相一致。通常，期望观看者重视度数据是在片段之间变化的，但是对于某些内容片段，可能没有变化或者变化很小。

计算并存储在状态处理和状态信息存储器604中的状态信息可以包括但不限于：已经接收但尚未呈现给用户的数据量，该数据量可以任何合适的单位进行测量，例如，依据向用户呈现的时间，或依据字节的存储数据；以及在至少一个时期内测量的客户端能够从内容服务器104获取的网络比特率(吞吐量)的估计值。

如上所述，清单文件用于描述每个内容片段的可用比特率，以及每个片段的位置(文件位置)。当使用mpegdash，is23009-1时，清单文件是被称作媒体呈现描述(mpd)的xml文件。当使用applehttplivestreaming(hls)时，清单文件是.m3u8格式的播放列表文件。当使用microsoftsmoothstreaming时，清单文件是xml文件。

现在将描述applehls清单文件的示例，接着是根据本发明示例的携带观看者重视度信息的applehls清单文件。还可以使用适当的语法以其它清单文件格式携带观看者重视度信息。

使用applehls，有一个.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/content_at_3m0.m3u8

#ext-x-stream-inf：bandwidth＝4500000

http：//example.com/content_at_4m5.m3u8

主播放列表文件引用另外四个播放列表文件：content_at_1m3.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-targetduration：10

#ext-x-version：3

#ext-x-media-sequence：1

#extinf：10.0，

segment_3m0_0001.ts

#extinf：10.0，

segment_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指示时长)。由于播放列表详细说明了构成内容的所有片段，因此客户端只需请求此类型的播放列表文件一次，即可播放整个内容项。

另选地，这四个播放列表文件中的每一个可以仅描述少量片段，可能是四个十秒的片段。这种用法对于直播内容传送服务(例如电视节目的直播传送)较为典型，其中播放列表中的片段代表最接近节目“直播边界(1iveedge)”的最新片段。客户端通常以约等于片段时长的间隔来重复请求播放列表文件。每次返回的播放列表文件可能包含不同的(较新的)片段。

以下是客户端可以在这种直播传送安排中接收的一个播放列表文件的示例。

#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-media-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_3m0_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

#extinf：10.0，

#ext-x-viewer-interest：i

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-inierest：2

segment_3m0_0124.ts

编号为121、122和123的片段再次被表示为观看者较不感兴趣，但编号为124的片段被表示为观看者更感兴趣。这可能是因为内容项表示一种体育赛事，其中有一些情节时段被构成下一个情节或下一个“比赛”的时段分开。片段124可以表示这样的情节时段，因此，相比于在其之前的时段，观看者会对片段124更有兴趣。

在视频点播播放列表的情况下，当首次取得清单文件时，整个内容项被描述给客户端，并且客户端可以计划何时请求片段以及在开始播放后的任何时间以哪种质量请求片段，直至需要片段来解码并呈现媒体。

然而，在直播播放列表的情况下，每个片段的观看者感兴趣级别仅在需要该片段以解码和呈现媒体之前的短期间内在客户端可见。处理这种直播情况更具挑战性，并且这种直播情况是对下文的客户端行为进行例示的基础。虽然参考直播场景描述了该示例，但该方法也可以应用于视频点播场景。

回顾一下，在直播内容的实现方式中，必须重复请求清单文件，以获得关于最近在内容服务器上可用的片段的新信息。

在该示例中，内容片段以四个恒定比特率编码，该内容片段均具有相同的10s时长。所述的四个比特率为1.3mbit/s、2.0mbit/s、3.0mbit/s和4.5mbit/s。客户端定期请求更新清单文件。这是applehls的常见行为，尤其是在视频直播时。在这种情况下，对清单文件的每个请求都可能导致清单文件致略有不同，详细说明了现在可用的不同内容的数据。例如，当客户端以约等于片段时长的间隔请求更新清单文件时，每个新的清单文件通常将列出最近变得可用的附加片段，而不再列出最早的一个片段，因为该最早的一个片段距离直播内容的“直播边界”太远了。

如前所述，客户端将请求清单文件，然后将确定接下来请求哪个片段以及以哪种质量请求。现在将描述从播放一段内容期间的任意点开始的客户端行为。

下表以缩略形式显示了针对单个编码比特率连续请求清单文件或播放列表文件时返回的信息。每一列均显示了片段编号列表和相关的观看者重视度值。针对另选的编码比特率，请求播放列表文件时将返回类似信息。因此，该表为上述播放列表的缩略形式。

表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)

在该示例中，知道比特率为1.3mbit/s、2.0mbit/s、3.0mbit/s和4.5mbit/s的片段可用的客户端决策模块608选择不大于所计算的最大片段比特率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。

下表示出了第一种网络场景中具有恒定网络吞吐量的客户端行为。

表2

以粗斜体示出描述具有更高观看者重视度的片段(编号为124的片段)的行。可以看出，由于尚未使用观看者重视度信息，所以已经以等于3.0mbit/s的编码比特率传送所有片段(包括被指示为具有更高观看者重视度的片段)。虽然这被认为是可接受的，但是4.5mbit/s的编码比特率也是可用的。如下所述，通过利用包含在清单文件中的观看者重视度信息，可以通过减小其它一些重视度较低的片段的比特率而以4.5mbit/s的编码比特率传送片段124。

以下示例进一步突出了该问题，其中在30s到40s时，网络比特率从3.1mbit/s下降到1.5mbit/s。

表3

再次以粗斜体示出描述具有较高观看者重视度的片段(编号为124的片段)的行。可以看出，由于尚未使用观看者重视度信息，被指示为具有更高观看者重视度的片段以表中列出的所有片段的最低质量进行传送(以等于1.3mbit/s的编码比特率进行传送)。这将给观看者带来不好的体验：尽管较低兴趣的前、后片段以可接受的质量进行传送，但是具有最高兴趣的片段实际上也已经以低质量进行传送。这可以通过检测实际网络比特率进行说明。

在这个例子中，在30s到40s时(在此实例中，是在29.1秒处刚以3.0mbit/s请求片段123之后，直至即将完成传送)，网络比特率从3.1mbit/s下降至1.5mbit/s。因此，传送花费的时间比客户所预测的更长，结果，当客户端决策模块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。

下表示出了具有恒定网络比特率的网络场景中的客户端行为。

表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。

表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。该式是希望以减少的下载可用时间传送三个片段并以这个下载可用的时间的两倍传送一个片段的结果。在这种情况下，重视度更低的三个片段中的第一个将具有2s的缓冲调整，第二个将具有4s的缓冲调整，并且第三个将具有6s的缓冲调整，给定标定时间8s来传送重视度更低的三个片段中的每一个，以及16s来传送具有更高重视度的片段。

缓冲区调整参数还可以取决于被标记为具有更高观看者重视度的片段的数量。例如，当清单中列出不止一个具有更高观看者重视度的片段时，可能需要使用比在清单中仅列出单个具有更高重视度的片段时更大的缓冲调整。例如，如果希望以具有更低重视度的先前片段的编码比特率的两倍来传送清单中列出的具有更高重视度的两个片段，且当在清单中首次列出具有更高重视度的片段时，已经列出三个具有更低重视度的片段且尚未请求这三个片段中的任何一个，如果所有相关片段的时长是10s，并且如果缓冲数据的时长等于最小缓冲时长，则将缓冲调整(ba)设置成3×(10-ba)+4×(10-ba)＝50，求解该式得出缓冲调整ba＝2.857s。该式是希望以减少的下载可用的时间传送三个片段并以这个下载可用的时间的两倍来传送两个片段中的每一个的结果。在这种情况下，具有较低重视度的三个片段中的第一个将具有2.857s的缓冲调整，第二个将具有5.714s的缓冲调整，并且第三个将具有8.571s的缓冲调整，给定标定时间7.143s来传送具有更低重视度的三个片段中的每一个以及14.286s来传送具有更高重视度的片段。

客户端决策模块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。

下表示出了具有恒定网络比特率的网络场景中的客户端行为。

表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。

表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的自适应比特率内容传送的传统方法(使用诸如applehls、mpegdash和microsoftsmoothstreaming之类的协议)具有显著延迟，对于直播服务，特别是对于体育内容的直播而言，这是很不理想的。该延迟部分是由于客户端必须等待片段内容被通知为可用。例如，在使用applehls时，必须等到新片段被列在更新的播放列表文件中，然后才能请求该新片段。使用mpegdash，客户端需要根据清单文件(mpd)中的定时信息及其自身时钟，连同通容错余量一起，来确定新的片段何时可用，然后才能请求。

行业中正在解决在能够对某个片段提出请求之前必须确切知道该片段何时可用的问题。具体地，正在开发标准is23009-6“基于全双工http协议(fdh)的dash”，以提供解决方案。

该方法是通过利用诸如http/2和websocket等internet协议的新特性和功能，通过http1.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传送流格式(如在is13818-1中所规定的)时，可以例如在具有特定pid(分组标识符，mpeg-2传送流包头中的字段)的分组流中携带观看者重视度信息，这与用于音频或视频数据不同，其使用可以向一组片段编号报知观看者重视度信息的语法。或者，可以使用mpeg-2传送流描述符中的类似语法来携带观看者重视度信息，可以在mpeg-2传送流中定期包括的psi表(例如，节目映射表)中找到mpeg-2传送流描述符。或者，可以使用类似的语法，在编码的媒体流之一中携带观众重视度信息，例如，在编码的视频流中，使用例如h.264或h.265编码的视频流中的补充增强信息(sei)消息。

当内容片段数据使用如is14496-12中所规定的iso基本媒体文件格式时，可以如上所述，在编码媒体流中的一者中携带观看者重视度信息，或者可以使用，例如，由针对一组片段编号报知观看者重视度信息的语法定义的特定“盒子(box)”，以文件格式本身携带观看者重视度信息。

在另一种方法中，在独立于清单文件的文件中报知所有或一些即将到来的片段的观看者重视度信息，但是其位置信号可以在清单文件中发送或在内容片段数据中发送。该文件可以包含内容的所有观看者重视度信息，因此了解观看者重视度信息的内容客户端108仅需要检索一次。或者它可能仅包含针对少数即将到来的片段的观看者重视度信息，在这种情况下，需要由了解观看者重视度信息的内容客户端108重复接收文件，其中每个更新可以具体由内容客户端108请求，或在推送会话初始化之后由内容服务器104推送。

虽然已经参考hls播放列表形式的清单文件描述了上述示例，但是也可以替代地使用mpegdash清单。

与applehls不同，当使用mpegdash,23009-1时，通常仅在接收和播放一段媒体内容时开始请求被称作媒体呈现描述(mpd)的清单文件。视频点播用例可以通过mpd来处理，该mpd为每种媒体类型(音频、视频等)的每个编码比特率指定单个文件的位置。直播用例以及视频点播用例可以通过mpd来处理，该mpd使用模板格式为每种媒体类型的每个编码比特率指定一系列文件的位置。

当使用mpegdash时，可以以多种不同方式报知观看者重视度信息，包括但不限于以下示例。

如上所述，可以在内容数据片段中报知观看者重视度信息。

可以在从mpd引用的文件中报知观看者重视度信息，该文件包含整个媒体内容项的所有观看者重视度信息并且仅被请求一次，或者包含针对少量即将到来的内容片段的观看者重视度信息，其要么被多次请求，要么在推送会话中被请求一次，并且内容服务器104在文件可用时将对文件的更新推送到内容客户端108。

以下是指示观看者重视度信息的位置的示例mpd。已经以粗斜体示出相关系列，以使其易于识别。

例如对于视频点播的用途例，可以在mpd内明确地传达观众重视度信息。这可以通过各种编码选项以多种不同方式进行传达。以下是mpd示例，其包括作为文本串的观看者重视度信息，每个片段具有一个字符，每个字符的十进制解释表明观看者重视度。已经以粗斜体示出相关行，以使其易于识别。请注意，为简洁起见，字符串已缩短为仅明示出前三个值和后两个值，而在实践中，每个片段都有一个值。

总的来说，在此应注意，虽然以上描述了本发明的示例，但是在不脱离所附权利要求限定的本发明的范围的情况下，可以对所描述的示例进行若干变化和修改。本领域技术人员将认识到对所述实施方式的修改。