用于直播自适应比特率(ABR)媒体的优化传递的系统和方法与流程

用于直播自适应比特率(abr)媒体的优化传递的系统和方法
技术领域
1.本公开一般涉及以更有效率的方式向自适应比特率(abr)客户端提供直播视频，该客户端在场所在被管理网络上接收视频。非限制性地、更具体地说，本公开针对用于使用多播机制来提供abr视频以便传递到场所的方法和装置。


背景技术：

2.当今，基于ip的直播视频内容经由两个分开的机制传递，取决于装置类型和需要借助的网络类型：
•ꢀ
多播视频传递通常被用在“被管理”网络、即电信运营商所管理的网络上。在这些网络上，运营商能够保证特定服务质量(qos)，并且因此能够以固定比特率传递视频内容而具有极少的分组丢失和强的差错恢复。典型终端装置是机顶盒(stb)和住宅网关(rg)，但是也可包括内容分发网络服务器。
3.•ꢀ
单播自适应比特率(abr)视频传递通常用在“未被管理”网络上，例如在开放的因特网上和/或借助内容传递网络(cdn)。通常，在这些未被管理网络上几乎没有qos，并且“端对端”可用带宽会变化。abr技术允许客户端在网络条件恶化时切换到相同内容的更低比特率实例。目标装置包括个人计算机(pc)、移动电话、平板、智能tv等。这些也称作“达到”装置或达到客户端。这些装置中的大多数没有多播能力，并且能够在家庭之内或之外操作。当用于家中时，达到装置仍然向cdn请求直播内容，但是内容通过被管理网络来传递。
4.现有技术状况所存在的一些问题包括下列问题：
•ꢀ
由于以不同方式将内容打包以用于被管理和未被管理直播视频传递，即，多播用于被管理网络，而基于http的单播传递用于abr视频传递，所以构建诸如从stb到平板的流播或者只是帧准确加书签之类的跨装置消费协同是麻烦的;
•ꢀ
由于接入网中的qos队列的资源限制，单播视频内容被区分优先级为“常规因特网数据”，并且接收尽力而为传递，而不是对于stb被当作“视频”来处理。因此，对于多播视频传递无法实施qos。这转化为abr的未达最佳的视频比特率选择，并且因此转化为降级的用户体验；
•ꢀ
信道冲浪可能是麻烦的，因为从cdn得到内容的等待时间就系统响应性而言超过用户预期；以及
•ꢀ
在接入网上的策略实施是缺失的。当前在家庭网络中没有机制来基于下游请求预见对固定qos接入网的上游资源约束，也没有机制在家庭网络中的未被管理的达到客户端上实施策略。


技术实现要素：

5.本专利公开广义地针对用于促进以更有效率的方式向达到装置提供直播abr内容的方案的装置和方法，所述达到装置在预订被管理网络的家中或其它场所中操作。所提出的解决方案是基于下列主要架构概念：
•ꢀ
统一且优化的abr视频传递链是基于已经为abr传递准备的单播内容的多播封装。内容通过被管理网络经由多播而不是单播来传递，并且被区分优先级为“视频”而不是数据，无需附加的qos队列；
•ꢀ
hls、mpeg
‑
dash和abr清单的聚合传递，允许stb或rg具有用于与相同信道对应的所有abr流的所有清单的先验知识。hls和mpeg
‑
dash片段共享基于传输流的特性，这允许跨qos和未被管理网络的流传递的调和；
•ꢀ
在住宅网关、机顶盒或cdn上实现以向位于家中网络上的“达到”装置供给内容的abr多播接收器功能性。rg或stb通过将最佳多播转换成所要求单播来充当家中网络上其它装置的代理。通过连续监测从一个多播组地址切换到另一个(但是仅在经过所有受约束网络段之后)，从而来适配多播的比特率。代理对达到装置来说看似常规abr内容服务器，而且不要求专门的应用或增加的硬件以播放通过多播网络传递的内容。另外，这个过程允许跨stb和达到装置的统一消费，并且实现帧准确加书签。例如，用户能够在stb上暂停，并且在平板达到装置上恢复；
•ꢀ
用于abr流的加速信道改变和差错恢复功能性。已知系统针对恒定或固定比特率流，但是不针对用于abr的加速信道改变；
•ꢀ
用于多播流的自适应比特率功能性，其允许abr装置在使用多播的同时在流简档之间切换，如当前在传统单播中可用的那样。这个混合系统采用少量单播来补充多播，以改进响应性，同时极大地降低对abr的单播的需要。
6.•ꢀ
新的双向多播自适应比特率(mabr)流策略实施协议被用来确定要加入的上游最佳多播组，并且在下游用来操纵单播abr客户端以符合mabr策略实施。
7.在一方面，公开一种向场所提供直播自适应比特率(abr)视频的方法的实施例。该方法包括：从内容服务器接收用于信道的基于传输流的直播abr内容；把用于所述内容的传输流(ts)分组封装在rtp分组中以形成rtp内容分组；把用于所述内容的多个abr流的聚合清单封装在rtp分组中以形成rtp清单分组；复用rtp内容分组和rtp清单分组；以及将已复用rtp分组作为多播流来传送。
8.在另一方面，公开一种用于向场所处的客户端提供直播自适应比特率(abr)视频的方法的实施例。该方法包括：在多播流中接收用于信道的rtp分组和聚合清单，所述rtp分组包含自适应比特率(abr)传输流ts分组，并且标识所述ts分组所属的abr片段；以及如果已经接收用于给定abr片段的所有rtp分组，则依次序将所述ts分组从所述rtp分组拆包以重组所述abr片段，并且缓存所述abr片段，以便根据请求传递到所述场所处的abr客户端。
9.在另一方面，公开一种向多播至abr代理(m2ap)装置提供所请求单播内容的方法的实施例，所述多播至abr代理(m2ap)装置向客户端装置提供直播自适应比特率(abr)视频。所述方法包括：过滤所接收rtp多播分组以将聚合清单分组与视频片段分离；重组聚合清单，并且解析聚合清单中携带的所选简档清单；缓冲与简档清单中列出的最近片段id对应的rtp分组；以及在缓冲器中存储最近片段和聚合清单，以用于应请求加速信道改变和重试。
10.本发明的优点包括、但不限于以下各项：
•ꢀ
在预订被管理网络的场所内操作的达到客户端能够消费通过接入网经由多播网络向该场所传递的内容。达到装置不需要直接加入多播流的能力。用于直播内容的浪费
的单播带宽成本被降低。对于通过被管理网络传递的内容，qos能够应用于该内容，使得达到装置上的内容的质量取决于家中网络上可用的质量和容量而不是家庭因特网预订线路上的能力。
11.•ꢀ
通过在通过携带简档的所有多播流来传递的一个结构中聚合所有简档清单，stb和rg被提供了关于给定信道的所有可用简档和片段的全貌。这能够被借助以加速信道改变功能性，并且应用围绕流管理的定制策略。
12.•ꢀ
在家庭网络中不需要基于硬件的编码器/变码器，降低了stb或rg相关硬件的成本。对于达到客户端播放器，不需要专门的应用，因为代理透明地处理转换。另外，对直播流加书签与相同时间点准确地对齐。由于stb和达到装置能够消费打包在一起并且按图片组(gop)对齐的内容，所以来自平板的书签设置会在相同时间点应用于stb的对应流。
13.•ꢀ
加速信道改变基础设施将在切换信道时实现更好的用户体验，并且将提供差错恢复。先前，即时信道改变机制尚未应用于单播abr。
14.•ꢀ
在接入网或家庭网络上的可用带宽下降时，用于多播的新的快速比特率改变机制将促进多播比特率改变的快速响应时间。当前没有通过切换多播组地址来适应拥塞的机制。虽然用户在简档的改变生效时可感知视频质量的一些变化，但是切换不会导致对视频的中断。
15.•ꢀ
拥塞策略被启用以响应于拥塞而在达到客户端处实施改变。现有技术是基于单播的，而达到客户端没有对上游资源的可见性。达到客户端认为它在控制中，而真正控制被移到m2ap，诸如stb、rg或cdn。
附图说明
16.在附图的各图中通过示例而不是限制来说明本公开的实施例，附图中相似的参考标号指示相似的要素。应当注意，本公开中对“某一”或“一个”实施例的不同引用不一定表示同一实施例，并且这类引用可表示至少一个。此外，在结合某一实施例来描述特定特征、结构或特性时，无论是否明确描述，均认为结合其它实施例来实现这种特征、结构或特性是在本领域技术人员的知识范围之内。
17.附图被结合到本说明书中并且形成其部分，以说明本公开的一个或多个示范实施例。从结合所附权利要求书并且参照附图进行的以下详细描述中将会理解本公开的各种优点和特征，附图中：图1示出按照本专利申请的一个实施例的用于直播abr媒体的优化传递的系统的高级视图；图2a示出按照本专利申请的一个实施例的abr至多播打包器(a2mp)的功能框图；图2b示出按照本专利申请的一个实施例的多播至abr代理(m2ap)的功能框图；图2c示出按照本专利申请的一个实施例的分发服务器(d
‑
服务器)的功能框图；图2d示出按照本专利申请的一个实施例的用于图2a
‑
2c中任一个的基本硬件的框图；图3a和图3b示出按照本专利申请的一个实施例、能够由图2a的a2mp实施的过程的流程图；图4a
‑
4e示出按照本专利申请的一个实施例、能够由图2b的m2ap实施的过程的流
程图；图5示出按照本专利申请的一个实施例、能够由图2c的分发服务器实施的方法的流程图；图6说明按照本专利申请的一个实施例、由图1的系统的组件所展示的清单之间的定时关系；图7说明按照本专利申请的一个实施例、对片段边界的多播调谐以及本系统如何避免数据丢失；图8a示出按照本专利申请的一个实施例、在达到装置上调谐到新信道的过程；图8b和图8c示出图8a和图10的过程的简化版本；图9示出图8a的过程的定时；图10示出按照本专利申请的一个实施例、切换到达到装置所请求的新简档的过程；图11示出图10的过程的定时；图12a示出按照本专利申请的一个实施例、迫使达到装置用于策略实施的简档中的降低的过程；图12b和图12c示出图12a的过程的简化版本；以及图13示出图12a的过程的定时。
具体实施方式
18.在以下描述中，针对本专利公开的一个或多个实施例提出许多具体细节。但是应当理解，即使没有这类具体细节也可实施一个或多个实施例。在其它情况下，没有详细示出众所周知的子系统、组件、结构和技术，以免影响对示例实施例的理解。因此，本领域技术人员将会理解，没有这类具体组件，也可实施本公开的实施例。还应当认识到，本领域技术人员借助于本文给出的详细描述并且参照附图，将能够在没有过度实验的情况下做出和使用一个或多个实施例。
19.另外，在以下描述、权利要求书或者两者中，可使用诸如“耦合”和“连接”之类的术语及其派生词。应当理解，这些术语不一定要作为彼此的同义词。“耦合”可用来指示彼此可以有或者可以没有直接物理或电接触的两个或更多单元相互配合或交互。“连接”可用来指示相互耦合的两个或更多单元之间的通信、即可通信关系的建立。此外，在本文所述的一个或多个示例实施例中，一般来说，单元、组件或模块在该单元能够执行或者以其它方式在结构上设置成执行某个功能时可配置成执行那个功能。
20.本专利公开的一个或多个实施例可使用软件、固件和/或硬件的不同组合来实现。因此，附图(例如流程图)中所示技术中的一个或多个可使用一个或多个电子装置或节点(例如订户客户端装置或终端站、网络单元等)上存储和执行的代码和数据来实现。这类电子装置可使用诸如非暂时计算机可读存储介质(例如磁盘、光盘、随机存取存储器、只读存储器、闪速存储器装置、相变存储器等)、暂时计算机可读传输介质(例如电、光、声或其它形式的传播信号—诸如载波、红外信号、数字信号)等的计算机可读介质来存储和(在内部和/或通过网络与其它电子装置)传递代码和数据。另外，这类网络单元通常可包括一个或多个处理器的集合，这些处理器耦合到一个或多个其它组件，诸如一个或多个存储装置(例如非
暂时机器可读存储介质)以及(一个或多个)存储数据库、用户输入/输出装置(例如键盘、触摸屏、定点装置和/或显示器)、以及用于实现信令和/或承载媒体传输的网络连接。处理器的集合和其它组件的耦合通常可通过以任何已知的(例如对称/共享多处理)或在此以前未知的架构来设置的一个或多个总线和桥(又称作总线控制器)来进行。因此，给定电子装置或网络单元的存储装置或组件可配置成存储代码和/或数据，以便在该单元、节点或电子装置的一个或多个处理器上执行，用于实现本公开的一个或多个技术的目的。
21.现在参照附图，更具体来说，参照图1，示出用于直播abr媒体的优化传递的系统100。该系统包括五个节点：abr至多播打包器(a2mp)104、分发服务器106、多播至单播abr代理(m2ap)114、网络存档系统108和达到装置116。abr内容服务器102向系统100提供内容。下面描述这五个节点的功能。
22.a2mp 104负责从诸如abr内容服务器102之类的http内容服务器拉取基于传输流的直播abr内容，并且通过在如rfc
‑
2250所定义的用户数据报协议/传输控制协议(udp/rtp)中包装传输流，在分开的多播地址上多播每个流。这个机制为时钟恢复和数据报丢失重试作了准备。另外，a2mp 104在必要时聚合各个简档清单，将这些清单存储在mpeg
‑
2私有节(mpeg
‑
2 private sections)中，这些私有节被分组化成传输流分组并且被包装成rtp分组。a2mp 104然后将含清单的rtp分组与含内容的rtp分组进行复用以便在多播流中传递。最后，这个节点将通过经由用于单个丢失事件的单播和用于相关丢失的多播重传来重传所丢失的rtp数据报，来提供差错恢复。
23.多播至单播abr代理(m2ap)114是位于网络数据中心的节点(在这里，这个节点能够向终端用户家庭提供服务)，或者是在终端用户家庭中的节点。当位于终端用户家庭中时，m2ap 114能够是机顶盒、住宅网关或者在家庭内担当中心传递节点的任何装置；否则，m2ap 114能够在网络中的上游。m2ap 114能够调谐到在被管理网络上可用的多播流，作为单播向分发服务器106请求缺失的分组或数据突发，并且用作本地http服务器以向位于家中网络上的达到装置传递单播内容。在实际实现中，可能并非所有简档和/或所有服务都具有所请求abr内容的多播版本。如果m2ap没有所请求简档，则它能够向上游cdn发送302重定向，以使客户端经由http单播来检索abr简档清单和内容，因而对于片段请求绕过该m2ap。m2ap 114负责使abr内容清单保持为最新，并且使片段在需要时可用于(一个或多个)达到装置。诸如机顶盒之类的一些m2ap也用作主要回放和记录装置。住宅网关也能够用作记录装置。
24.分发服务器106负责缓冲a2mp 104的输出，并且应请求而向m2ap 114供给所缓冲分组，这将更详细地说明。m2ap 114能够向分发服务器106请求缺失的数据报或者数据的突发，以填充其内部缓冲器。分发服务器106也能够向a2mp请求缺失的数据报。
25.达到装置116是能够位于终端用户家庭内部或外部的节点；它们实现带宽流管理系统。当位于家庭网络外部时，它们实时检测诸如m2ap 114之类的本地http服务器的缺乏，并且直接通过开放的因特网经由单播abr向cdn请求内容。当位于家庭内部时，它们参与带宽流管理，以及基于资源约束，它们可经由单播abr向m2ap 114请求内容，m2ap 114则使内容通过http在本地可用。当本地资源受到约束时，带宽流管理系统实时收敛，以及请求将绕过本地资源，并且经由单播abr向cdn请求内容。
26.网络存档系统108是部署在运营商网络内的、理想地尽可能接近终端订户的一个
或多个节点。存档系统配置成加入被管理网络上可用的多播流，向a2mp请求缺失的数据报，重构abr片段，并且存储它们，以供订户以后通过http作为常规非直播abr内容来访问。网络存档系统108应用与m2ap 114相同的abr片段重构过程。
27.图1的装置中的三个在图2a
‑
2c中的功能框图中示出，并且其基本硬件单元在图2d中示出。作为a2mp 104的一个实施例的abr至多播打包器(a2mp)202包括：abr内容接收器204和abr清单接收器206，它们共同请求并且接收清单和片段，这些片段组成直播视频的内容；rtp分组器208和rtp调度器210，它们准备出去的rtp分组并且调度其输出；以及多播器212。将参照图3a和图3b的流程图更详细论述这些组件的功能。
28.作为m2ap 114的一个实施例的多播至abr代理(m2ap)220包括多播接收器222，多播接收器222本身包括rtp分组验证模块224和片段重组模块226。m2ap 220还包括abr管理器228和输出接口234。abr管理器228负责将经由多播和来自分发服务器106的所请求突发而接收的abr内容编织在一起，并且使这个abr内容经由输出接口234可用。将结合图4a
‑
4e和图8a
‑
13更详细论述m2ap 220的这些组件的功能。
29.作为分发服务器106的一个实施例的分发服务器240包括rtp过滤模块242、内容组装和缓冲244、清单组装和处理246、高速缓存管理252和客户端接口250。将关于图5以及图8a
‑
13更详细论述分发服务器240的组件的功能。
30.图2d是诸如图2a、图2b、图2c中所示的a2mp 202、m2ap 220和分发服务器240之类的网络节点的硬件组织的一般化框图。节点260包括通过一个或多个数据总线270耦合在一起的一个或多个处理器262、存储器264、本地存储装置266和输入/输出(i/o)接口电路268。i/o接口电路268将装置耦合到一个或多个外部网络、附加存储装置或系统以及如本领域中所公知的其它输入/输出装置。如本文所述的装置的系统级功能性通过硬件执行计算机程序指令来提供，这些指令通常存储在存储器264中，并且由(一个或多个)处理器262来检索和执行。
31.现在将参照其余附图来描述所公开的过程。图3a
‑
3b说明将直播abr流转换为多播rtp流的过程。一般来说，abr至多播打包器(a2mp)202配置成检索用于特定信道的信道清单。信道清单列出简档清单，这些简档清单对应于构成该信道的各简档，即，用户装置能够用来接收该信道的各种比特率。a2mp 202能够过滤信道清单，以便仅考虑通过直播abr内容服务器可供使用的所有简档的子集。对于给定信道，a2mp 202传送用于各个所选简档的一个多播；这些多播中的每个随其携带聚合清单，聚合清单包含经由多播可用的那些简档。
32.对于每个所考虑简档，abr清单接收器206检索简档清单(310)。每个简档清单能够具有其自己的有效性周期，而且abr清单接收器206负责定期检索各简档清单的新版本。abr清单接收器206然后可选地把所有所选简档清单聚合(312)在称作聚合清单的单个私有数据结构中，这能够是实现相关的。这个单元是可选的，因为在mpeg
‑
dash格式化内容的情况下，信道和简档清单包含在媒体呈现描述(mpd)中，mpd已经是聚合清单。在这种情况下，abr清单接收器206只需要周期性地检索这个mpd，而无需分别检索信道清单和所有简档清单。但是，如果a2mp 202没有多播所有可用简档，则应当过滤mpeg
‑
dash mpd，以去除没有被提供的那些简档。rtp分组器208使用私有专用分组标识符(又称作“pid”)在mpeg
‑
2私有节中存储聚合清单(314)，这也是实现相关的。所得到的mpeg
‑
2私有节被分组化成传输流分组，这些分组本身被封装到rtp分组中(330)，并且使之可供rtp调度器210使用，其中rtp报头扩
展标识聚合清单。
33.并行地，对于各简档，abr内容接收器204请求和接收(302)简档清单中列出的最近片段。在任何时间点，a2mp 202仅传送可用于各简档的最近片段。各片段包括传输流分组，rtp分组器208将传输流分组封装(306)到rtp分组的序列中，各rtp分组具有标识片段的rtp报头扩展。所述rtp分组中的每一个包含7个mpeg
‑
2传输流分组，除了最后的rtp分组，最后的rtp分组将包含取决于片段大小的数量的分组，即(fragment_size/(188*7))/188个传输分组。然后使那些分组可供rtp调度器210使用。
34.在至少一个实施例中，不是将组成片段的传输分组与携带聚合清单的传输分组重新复用，而是rtp调度器210在rtp层，即，在封装之后，重新复用各数据集。这使下游组件能够在rtp层而不是在传输流层过滤各数据集。本领域技术人员会认识到，还有可能在传输流级重新复用。因此，下面概括在rtp层的重新复用过程。rtp分组多播调度器210在每个片段周期读取封装片段的rtp分组，并且以不超过一秒的周期读取封装聚合清单的rtp分组。rtp调度器210调度来自两种源(即，片段和聚合清单)的rtp分组的传输，并且更新每个rtp分组的rtp序列号(334)。多播器212通过多播来传送(336)所得到的rtp分组的序列。因此，在计及rtp封装之后，加上从聚合清单的周期性插入所得到的比特率，给定多播的比特率将大于或等于片段的聚合比特率。应当注意，a2mp传送聚合清单，其中各简档清单列出不再被传送的片段。这个信息将由分发服务器以及m2ap用来实现特定情形，诸如分组重试和时间移位。
35.为了分发服务器106、网络存档系统108和m2ap 114重构abr片段，需要标识传送分组并且需要缓冲分组的顺序，以及哪些分组携带片段净荷或者包含聚合清单的mpeg
‑
2私有节。由于该原因，不同的rtp报头扩展被用于携带片段净荷的rtp分组以及用于携带聚合清单的那些rtp分组。rtp固定报头已经提供序列号，该序列号被用来对通过多播接收的rtp分组重新排序，并且在缺失时请求缺失的分组。为了进一步标识片段在哪里开始和结束，系统使用私有“片段”rtp报头扩展，其语法能够如下所示：其中：
•ꢀ
fragment_type(16位)是指示rtp分组包含片段相关数据的任意值；建议值为0
×
abcd；
•ꢀ
fragment_id(32位)是通过多播rtp传送的片段的唯一标识符；
•ꢀ
fragment_size(32位整数，无符号)是片段的总大小，其中rtp分组的总数从这个数量推导出来为fragment_size/(188*7)+1；fragment_size必须是188字节的倍数，并且对具有相同fragment_id的所有rtp分组必须是相同的；
•ꢀ
fragment_rtp_packet_index(24位整数，无符号)是形成完整片段的rtp分组的序列中的rtp分组的索引；该值必须严格小于(fragment_size/188*7+1)；以及
•ꢀ
rtp_ts_pkts(8位整数，无符号)是rtp分组内封装的传输分组的数量，并且必须等于7，除了该序列的最后的rtp分组之外。
36.类似地，需要标识rtp分组是否携带聚合清单。下列“清单”rtp报头扩展能够用来指示聚合清单文件。
37.其中：
•ꢀ
manifest_type(16位)是指示rtp分组包含清单相关数据的任意值；建议值为0
×
1234；
•ꢀ
man_version(8位，无符号)是清单版本，由a2mp来维护并且在更新聚合清单时被更新；这个值对于每个新版本递增1，并且在达到0
×
ff时翻转成0；
•ꢀ
manifest_size(24位，无符号)是mpeg
‑
2私有节中封装的聚合清单的总大小；rtp分组的总数从该数量推导出来为manifest_size/(188*7)+1；这个值必须是188字节的倍数，并且对于具有相同man_version的所有rtp分组必须是相同的；
•ꢀ
manifest_rtp_packet_index(24位整数，无符号)是形成完整聚合清单的rtp分组的序列中的rtp分组的索引；该值必须严格小于(manifest_size/188*7+1)；
•ꢀ
rtp_ts_pkts(8位整数，无符号)是rtp分组内封装的传输分组的数量，并且必须等于7，除了该序列的最后的rtp分组之外。
38.图4a
‑
4e描述m2ap 220和网络存档系统108这两者如何基于通过多播接收的rtp分组来重组片段。在这里考虑abr文件片段的特定情况，但是封装聚合清单的mpeg
‑
2节的重组沿用相同过程，唯一差别在于检查rtp报头扩展类型。类似地，该过程依照m2ap 220来描述，但是本领域技术人员会认识到，本描述也适用于存档系统108。最初，多播接收器222接收与预定义简档对应的特定多播地址上的rtp分组(402)。多播接收器222可例如在由a2mp重传之后接收任何rtp分组的副本。因此，rtp分组验证224检查(406)rtp分组是否已经被接收和处理、即缓存。如果情况是这样，则多播接收器222恢复监听新的多播分组。基于rtp固定报头序列号，rtp分组验证224还检查(410)rtp分组的序列中是否存在间断性，因为没有保证分组按次序到达。应当注意，rtp分组可包含片段净荷或者封装聚合清单的mpeg
‑
2私有节。在这个阶段，rtp分组验证224仅检查rtp固定报头及其序列号，而不检查rtp净荷的性质。如果检测到序列间断性，则rtp分组验证224向分发服务器106请求(414)缺失的rtp分组。值得注意的是，分发服务器106和网络存档系统108还具有请求缺失分组并且将对a2mp 104进行其请求的能力。rtp分组验证224还检查rtp报头扩展内的任何不一致(其会使rtp包无效)
(418)。对于给定fragment_id，必须满足下列条件：
•ꢀ
fragment_size跨所有rtp分组保持相同；
•ꢀ
fragment_rtp_packet_index必须小于fragment_size/(188*7)；以及
•ꢀ
rtp_ts_pkts必须等于7，除了最后的rtp分组之外。
39.如果检测到任何不一致，则rtp分组验证224记录差错(422)，其将指向待解决的打包问题。如果rtp分组是有效的，则将分组添加(426)到由fragment_id标识并且用fragment_rtp_packet_index来索引的rtp分组的列表。
40.对于所接收的每个rtp分组，多播接收器222检查对应列表是否完整(430)。如果给定fragment_id的rtp分组的列表是完整的，则分组重组226通过依次序将传输流从rtp分组拆包来重组(438)片段。多播接收器222然后缓存(446)已重组片段。这个片段然后变成可用于本地回放或http检索。如果给定fragment_id的rtp分组的列表不完整，则多播接收器222检查是否已经重试所有缺失分组以及是否所有请求已经超时(434)。如果情况不是这样，则一些分组仍然要被接收，并且该节点返回到监听模式。但是，如果所有缺失分组重试已经超时，则认为该列表是伪完整的，以及片段重组226通过依次序对有效rtp分组拆包并且通过在mpeg
‑
2传输流报头中适当设置transport_discontinuity_bits以指示间断性，来重组(442)片段。这个信息将由达到客户端用来在回放期间重置其解码器。多播接收器222然后缓存(446)已重组片段，已重组片段变成可用于本地回放或http检索。
41.就像m2ap 114和网络存档系统108，分发服务器106也是a2mp的多播客户端。但是，分发服务器106没有重组片段，而是基于它将从相同多播流中接收的聚合清单中提取的简档清单来缓冲由fragment_id索引的rtp分组。由于网络约束，可能发生如下情况：分发服务器106没有接收所有rtp分组。在这种情况下，分发服务器106将向a2mp请求分组重试。当发出突发时，分发服务器106将按照与多播器212最初发送的相同的次序来发送rtp分组。
42.图5说明分发服务器240的缓冲过程500。在加入从a2mp 202始发的多播流之后，分发服务器240接收用于所选比特率(例如800kbps)的rtp多播(502)。分发服务器240的rtp过滤模块242过滤出包含“清单”rtp报头扩展的rtp分组(504)。清单组装和处理246则重组聚合清单(508)，并且从聚合清单提取与经由多播流接收的流对应的简档清单，聚合清单由a2mp 202周期性地发送。在并行过程中，rtp过滤242过滤出包含“片段”rtp报头扩展的rtp分组(506)。内容组装和缓冲244使用在508重组的简档清单来过滤和收集与用于这个简档的最近片段对应的所有rtp分组(510和516)。一旦重组了最近片段，高速缓存管理252从高速缓存中去除当前简档清单中不再列出的任何片段(518)。高速缓存管理252然后在其内部缓冲器中存储最近rtp分组，以用于加速信道改变和重试(520)。客户端接口250到目前为止还没有参与所述动作，而是将在图8
‑
13所述的过程中与m2ap 220交互。
43.图6说明abr内容服务器102上可用的内容602、由a2mp 104通过多播传送的片段604以及分发服务器106在突发期间能够供给的片段606的集合之间的定时关系。如能够看到的，abr内容服务器102上可用的简档清单602以及作为多播的部分所传送的简档清单606是相同的，即，所示第一时隙中的片段n
‑
4、n
‑
3、n
‑
2在片段n
‑
2 604通过多播传送的同时被发送。片段的这个相同集合将由分发服务器106在少许延迟的时间帧608中供给。应当注意，分发服务器106知道它在需要时将具有完整片段，能够在实际上完全接收这个片段之前稍微早一点开始包含最近片段的突发。类似地，m2ap 114能够在完成最后片段之前稍微早一
点供给最近聚合清单，因为这个片段能够在分发服务器正突发其数据的同时完成。
44.接下来看图7，值得注意的是，在多播abr环境中，多播流按图片组(gop)对齐。当达到客户端从一个多播(例如多播1)执行因特网组管理协议(igmp)“离开”时，达到客户端仍然能够在例如50毫秒的时间周期里接收一些多播分组。这在图中示为不想要的数据。类似地，在对多播(例如多播2)执行igmp“加入”时，能够存在客户端不会接收任何多播分组的某个时间周期，例如100毫秒，以交叉阴影线示出。在多播abr环境中，客户端通常在片段边界上从一个多播流切换到另一个。这转化为所示数据丢失，这损害了在第二多播上接收的第一片段的完整性。数据丢失的量等于离开(t0)与加入(t3)之间的时间差乘以多播的比特率(bw)，即，(t3
‑
t0)*bw。要避免这种数据丢失，目前的系统依靠为分组重试分配的附加带宽，其表示为分发服务器输出。在所公开的系统中，分发服务器106充当通过单播的分组转发器，而带宽等于e*bw，其中e是已经分配供多播中使用的比特率的某个百分比(some fraction)。通过从片段的开始转发分组，这个过程确保客户端已经恢复在igmp等待时间期间原本会缺失的分组的一部分，而无需执行任何重试。
45.看过了所公开系统的组件，现在将转向这些组件用来填充缺失数据并且提供直播abr媒体的优化传递的方法，这些在图8
‑
13中详示。本专利申请中概述的传递系统将通过多播传递的内容发送给stb或rg，stb或rg用作多播至abr代理(m2ap)，并且使用单播向场所上的达到客户端传递内容。本领域技术人员会理解，达到客户端能够发现哪些信道经由m2ap是可用的。使达到客户端能够快速调谐到某个站的主要难题之一是尽可能快地使相关片段在m2ap上可用。本专利申请提出加速达到客户端的调谐操作的三个机制的组合：
•ꢀ
当达到客户端向m2ap发出“调谐”请求时，m2ap采用包含单个简档的信道清单进行应答。要使之可用的简档的选择取决于运营商选择和策略以及流管理条件；
•ꢀ
同时，m2ap向分发服务器请求单播数据突发，使得m2ap能够采用片段和聚合清单开始填充其内部缓冲器。所请求的数据突发包含当前正传送或最近传送(即，过去的1
‑
10秒)的片段；突发速率取决于可用带宽，但是通常将采用等于视频的标称速率的120%至400%的数据速率；以及
•ꢀ
在突发期间，m2ap将采用它已经正确重组和缓存的片段的列表周期性地更新供给达到客户端的简档清单。当突发结束时，m2ap所供给的简档清单应当与聚合清单内包含的清单一致。
46.•ꢀ
注意，当消费装置是stb或者不需要abr片段的其它装置时(例如当m2ap是stb并且在该stb上请求消费时的情况)，能够在适当的时候略过abr片段重组，并且传输流分组能够被直接馈送给解码器。
47.图8a详细描述在达到客户端上调谐到信道的过程，而图9从定时的角度来说明同一过程。下列参考标号及其描述参照图8a和图9。将会认识到，m2ap 805对应于图2b的m2ap 220，以及在至少一个实施例中，包含先前图中所示的功能框。该过程开始于用户801在达到装置803的用户界面上选择要调谐到的信道(810)。本领域技术人员会理解，达到装置803会被提供m2ap的url，并且将访问这个url以得到信道的清单(812)。要加速达到客户端803的调谐过程，m2ap 805采用包含所选单个简档的信道清单进行应答(814a)。同时，m2ap 805向分发服务器809请求与这个简档对应的数据突发(814b)。分发服务器809发送数据突发(816)，数据突发包含当前在其缓冲器中与该简档对应的聚合清单和片段。运营商可配置这
个突发的比特率以及它包含多少片段。通常，比特率将设置成匹配开始回放的达到客户端的最小缓冲器要求。注意，在图9所示的示例中，运营商配置了2.5
×
突发速率和2
‑
片段缓冲器。还值得注意的是，信道清单将由m2ap 805来维护和更新。达到客户端803将周期性地请求这个清单，正如客户端通常在调谐到常规过顶(ott)abr内容服务器时请求清单那样。通过控制清单的周期，有可能使m2ap 805几乎实时地实施流管理策略。
48.基于m2ap 805所供给的信道清单，达到装置803请求与它预期的流简档对应的简档清单(818)。在这个请求的时间，聚合清单以及第一片段应当已经处于从分发服务器809朝m2ap 805的途中。一旦m2ap 805接收到聚合清单和第一片段，m2ap 805立即生成具有所列出的一个片段的简档清单，并且向达到客户端803发送简档清单(820)。清单是达到客户端播放器所支持的格式(其例如是hls或mpeg
‑
dash)。如在图9中看到的，m2ap 805按照它预计具有从突发重组的新片段的时间将这个清单的周期设置成某个值、例如0.4秒。到那时，m2ap 805将重新生成具有所列出的两个片段的新简档清单，依此类推，直到它具有可用的聚合清单中所列出的所有片段。这个过程迫使达到客户端803足够早地重取简档清单，以请求下一个片段。当m2ap 805预计分发服务器809将要结束其突发时，它将简档清单的周期设置成最大值，其是片段的时长、例如1秒。贯穿整个数据突发，m2ap 805重组片段和聚合清单(822)，以及达到装置803开始请求被公告为在m2ap上可用的片段(824)。m2ap 805通过http采用对应片段进行应答(826)。请求和发送片段的序列在m2ap 805根据来自达到装置803的请求供给片段时重复进行(828a、830a、828b、830b)。在这个时间期间，从分发服务器809始发的单播突发仍然是活动的，以及m2ap 805所供给的信道清单仍然仅限于一个简档，迫使达到客户端试探保持被约束到这个单个比特流。
49.一旦分发服务器809已清空其缓冲器，这个服务器向m2ap 805发送消息以加入多播(831)。分发服务器809则以e的速率开始转发片段(833)，其中“e”是在网络上分配的视频的标称速率之上的可配置带宽百分比，例如当分组丢失时用于重试或者当网络不忙时作为备用带宽。单播材料的这个缩减防止客户端开始接收多播时的管道或网络上的溢出，同时仍然确保m2ap 805仍然能够在igmp加入等待时间期间接收片段。理想地，由igmp加入延迟导致的空缺将通过接收与第一多播片段对应的所有rtp数据报的时间来填充。要确保空缺能够与下载第一多播片段同时或接近同时通过“e”突发来填充，e将等于或大于igmp加入等待时间(j)除以片段时长(f)。如先前所述，任何附加缺失rtp数据报能够通过从m2ap 805到分发服务器809的特定请求来重试，从而请求填充空缺所需的序列。m2ap 805加入与当前被解码的简档对应的多播(832)。这作为igmp加入请求向最接近的上游多播复制点807发出。同时，单播突发以e的速率继续进行。一旦实现加入(836)，m2ap 805开始以音频/视频的标称速率来接收多播分组。如先前详述的，多播流包含被分组化为rtp分组、与简档对应的最近直播片段以及被封装在mpeg
‑
2私有节和rtp分组中的聚合清单。
50.在如图9中看到的这一点，m2ap 805基于运营商策略和流管理实时约束来更新信道清单，以列出能够对于该信道可用的所有简档。m2ap 805立即指示分发服务器809停止转发片段(850)，并且将请求任何必要重试。m2ap 805更新其简档清单，并且缓存最近片段。当达到客户端803随后请求信道清单的最近版本(846)时，m2ap 805向达到客户端803返回已更新的信道清单(848)。从那一点开始，达到客户端803可操作以作为标准abr算法的部分重新计算其试探，以及确定当前简档是否在给定装置能力和网络条件(没有具体示出)的情况
下提供最佳可能质量。偶尔，m2ap 805可能没有收到所有多播分组，在这种情况下，m2ap 805将向分发服务器809请求那些分组，以便使所有片段及时可用于达到客户端803。分发服务器809将缺失的rtp分组从分发服务器的循环缓冲器返回到m2ap 805(852)。在图9的示例中，片段之间的虚线框表示在多播流和分发服务器突发中传递的聚合清单的更新。如先前所提到的，聚合清单在片段传输生存期期间重复传送，并且在片段边界被更新。在所示示例中，使用一秒片段，是突发的2.5倍，即，在突发期间，一秒片段由分发服务器809在400ms中传送。
51.当达到装置803从一个简档切换到另一个时，与上述调谐过程相似的状况发生，这将在图10和图11中描述。在查看简档切换的细节之前，图8b和图8c说明图8a和图9的调谐过程与图10和图11的简档改变过程之间的相似性。在过程800b，达到装置803能够调谐到某个站，要不然就请求新简档(870)。在任一种情况下，m2ap 805的abr管理器228经由单播向分发服务器809请求视频突发(872)。一旦接收到初始片段，abr管理器228开始将所接收视频提供给输出接口234，其使用单播向达到装置803传递视频(874)。m2ap 805然后确定突发是否完成(876)。这个确定能够由分发服务器809(其能够指示m2ap 805加入适当多播)来提供。如果突发完成，则多播接收器222发送加入所选信道的适当多播的请求(878)。在过程800c中，m2ap 805确定是否已经实现多播加入(880)，而且一旦实现了加入，则指示分发服务器809停止转发片段(882)。这时，m2ap 805还能够恢复请求任何必要重试。
52.来看附图的后续集合，能够注意，带宽策略能够基于下游条件、即达到客户端试探或者基于运营商所定义的流管理策略并且基于被管理网络的约束来实施。图10说明达到装置803基于其试探计算从一个简档切换到另一个时的所公开过程，而图11从定时角度说明相同过程。图12说明m2ap 805如何能够迫使达到客户端803基于运营策略、流管理或网络条件来切换简档，以及图13从定时角度说明图12的过程。
53.首先来看图10和图11，m2ap 805加入与特定简档对应的多播(1010)，并且接收包含mpeg
‑
2传输流的rtp多播流(1012)。在这一点上将会理解，先前所述以及图8a和图9所示的加速调谐机制被应用于这些步骤，但是为了理解的清楚起见而未示出。如先前小节所述，rtp多播流由音频和视频内容以及聚合清单组成。在常规回放体验期间，达到装置803周期性地请求片段以及信道和简档清单的新版本，通过清单的分析来确定(1014)，以及m2ap 805向达到装置返回对应片段或清单更新(1016)。在接收到片段时，达到装置803上的播放器重新计算试探(1018)。在这个示例中，达到装置803评估重新计算的试探，并且请求不同简档的清单(1020)。m2ap 805立即触发向分发服务器809的突发请求(1022)，以便开始采用与新请求的简档对应的最近片段来填充其缓冲器。由于m2ap 805具有达到装置803对于前一简档先前请求的片段的知识，所以m2ap 805能够请求要由分发服务器809对于新简档优先传递的特定片段。本领域技术人员会认识到，虽然达到装置803请求来自新简档的片段，但是达到装置803上的播放器仍然消费先前从m2ap 805接收的音频和视频分组。分发服务器809发出具有最近聚合清单和rtp分组的数据突发(1024)，从m2ap 805所请求的第一片段开始。这个数据突发与信道调谐请求中使用的数据突发是相同的，只不过当前突发从所请求的特定片段而不是分发服务器缓冲器的开头开始。因此，这个突发可能比因信道调谐请求而发出的突发持续更短。
54.m2ap 805一重组了分发服务器809所发送的第一片段，m2ap 805就返回列出这个
片段的简档清单(1026)，并且设置清单的有效性周期，如在图11中所见，使得达到装置803在下一个片段可用时(例如0.4秒)请求更新。又在图11中看到，简档清单由m2ap 805在每次重组从分发服务器809所接收的新片段时被更新。达到装置803开始请求简档清单中列出的片段(1028)，以及m2ap 805向达到装置803返回这些片段以供回放(1030)。达到装置803然后更新其试探(1032)。达到装置803一直请求信道和简档清单的新版本以及用于这个新简档的新片段(1034a、1034b)。如前一示例中所述并且在图11中所见，一旦m2ap 805评估分发服务器809快要结束突发，清单的周期被设置成最大值、例如1秒，其在本公开中等于片段时长。m2ap 805采用其高速缓存中存储的清单和片段来应答该请求(1036a、1036b)。一旦来自分发服务器809的突发完成，则分发服务器809指示m2ap 805加入多播流(1038)，并且开始以速率e转发rtp分组(1039)。要确保空缺能够与下载第一多播片段同时或接近同时通过“e”突发来填充，e将等于或大于igmp加入等待时间(j)除以片段时长(f)，如下式所示。任何额外的缺失的rtp数据报照常通过从m2ap 805到分发服务器809的特定请求来重试，从而请求填充该空缺所需的序列。
55.m2ap 805发出多播加入(1040)，而且一旦实现加入，m2ap 805接收用于这个简档的rtp多播流(1042)。这个多播包含具有片段和聚合清单的mpeg
‑
2传输流。先前向达到装置展示的简档清单采用新有效性周期(其基于所接收的最近片段索引来计算)来更新。通过准确计算这个周期，m2ap指示达到装置何时下一个清单被定为目标而变得可用。一旦加入发生，m2ap 805指示分发服务器809停止发送分组(1044)，但是仍然能够根据需要来请求重试。仅当从分发服务器809接收的第一片段被显示时，用户获得视频简档已经改变的视觉确认(1046)。取决于客户端缓冲器装满程度，这可花费数秒。
56.在图12和图13中，m2ap 805检测到一些上游约束，并且确定朝达到装置803实施特定策略。这些新策略应当迫使达到装置803几乎实时地切换简档。当这个过程开始时，达到装置803调谐到某个信道，并且以特定比特率进行消费。因此，m2ap 114已加入来自多播复制点807的对应多播(1210)。m2ap 805接收rtp多播分组，提取片段和简档清单，并且将它们缓存(1212)。达到装置803照常请求片段和清单更新(1214)，以及m2ap 805返回所请求的片段和清单(1216)。应当注意，虽然图13示出单个简档由m2ap 805向达到装置803展示，但是这是正被消费的简档；多个简档可出售，但是没有具体示出。在某个点，m2ap 805检测网络争用。如果争用不是大到足以影响当前简档，则m2ap 805能够只是将可供达到装置使用的简档限制到不引起附加争用的那些简档，即，5
‑
简档配置能够被限制到3
‑
简档配置。如果争用足够大，则m2ap 805判定这类装置不能消费当前使用的简档，并且必须被切换到所选简档。在片段边界之前不久，m2ap 805对当前多播执行“igmp离开”以及对所选多播执行“igmp加入”(1218/1219)。igmp离开(1218)在片段边界之前(l)毫秒被发送，其中(l)是平均离开等待时间，而igmp加入(1219)在片段边界被发送。在“离开”生效以前，m2ap 805继续接收来自旧简档的多播分组以完成旧片段。一旦实现加入，m2ap 805开始接收与新简档对应的多播分组(1224)。与igmp加入(1219)同时，m2ap 805指示(1220)分发服务器809以e速率发送来自旧简档的任何剩余片段数据，接着是来自新简档的新片段数据。分发服务器809向m2ap 805发送(1221)所请求数据。要确保空缺能够与下载对应于第一多播片段的所有rtp数据报
同时或接近同时通过“e”突发来填充，e将等于或大于igmp加入等待时间(j)减去igmp离开等待时间(l)所得的差除以片段时长(f)。如先前所述，任何额外的缺失的rtp数据报能够通过从m2ap 805到分发服务器809的特定请求来重试，从而请求填充该空缺所需的序列。
57.在这种情况下值得注意的是，正是m2ap 805指示分发服务器809转发片段。在先前的情况中，分发服务器809将首先清空其缓冲器，然后在以e速率开始转发片段之前指示m2ap 805加入多播流。
58.m2ap 805还更新信道清单，以将简档的数量限制为两个：一个是它为其缓存了来自多播流的片段的简档，以及一个是它迫使客户端转到的简档。在图13中向达到客户端展示的清单中应当注意，各个简档被附有(m)或(u)；这些所附标签指明对于各个简档所检索的片段的来源、即多播或单播，并且被提供以仅用于帮助理解如何构造m2ap高速缓存内容。如有必要，如果达到装置803尝试早点切换到这个简档，则m2ap 805能够通过单播来检索片段。m2ap 805开始接收从多播复制点807发送的rtp分组(1224)。理想地，一接收第一rtp多播分组，m2ap 805就指示分发服务器809停止转发多播分组(1226)，并且仅执行重试。但是，在某些条件和定时下，突发可持续更长时间，直到填充所有序列空缺。达到装置803按照调度来请求信道清单(1228)，接收和解析信道清单(1230)，并且检测到只有两个简档仍是可用的(1232)。达到装置803基于简档清单中提供的列表来请求片段(1234)。对于几个片段周期，取决于其内部缓冲器，达到装置803将一直请求来自先前简档的片段。但是，如在图13中所见，m2ap 805不再缓冲来自这个多播的片段，以及当片段到期时，这个简档清单将列出越来越少的可用片段。在图13中示出从达到客户端803到m2ap 805对于信道清单、简档清单和片段的附加请求，但是由于图示困难而没有具体标记。m2ap 805采用来自先前简档的仍然可用的片段或者对于第二简档所请求的片段来应答来自达到装置803的请求(1236)。如果片段尚未缓存，则m2ap 805能够使用先前在基于试探的简档切换中描述的机制向分发服务器(809)请求那些片段。一旦来自第一简档的所有片段已经到期，m2ap 805更新其信道清单以仅列出第二简档(1238)。达到装置803请求最近信道清单，检测到仅列出一个简档，并且检索对应简档清单，然后开始请求用于这个简档的片段(1240)。m2ap 805向达到装置803返回所请求片段(1242)。因为存在简档的改变，所以用户801将具有达到装置这时正在回放不同流的视觉确认(1244)。
59.图12b和图12c在方法1200b和1200c中提供图12a的过程的简化。在方法1200b中，m2ap 805检测拥塞，并且确定迫使客户端转到新简档(1260)。m2ap 805离开旧多播并且加入新多播(1261)；然后使用新简档经由单播向分发服务器809请求视频突发(1262)。m2ap 805然后把将提供给客户端的信道清单限制到两个简档—当前使用的简档和新简档—并且向客户端装置传递受限制信道清单(1264)。m2ap 805然后确定是否已经实现加入(1266)。如果已经实现加入，则m2ap 805指示分发服务器809停止转发分组(1268)。该方法然后转到方法1200c，方法1200c确定旧简档视频是否已经到期(1280)。当旧简档视频已经到期时，m2ap 805进一步将信道清单限制到新简档，并且在必要的情况下继续向客户端装置传递受限制清单(1282)。在方法1200b和1200c的时间帧期间，m2ap 805继续经由单播向客户端提
供视频，首先使用旧简档来传递先前所请求的视频，然后在适当的时候改变到在新简档的视频。
60.在本公开的各种实施例的以上描述中，要理解，本文所用的术语是仅为了描述具体实施例，而不是意在限制本发明。除非另加限定，否则本文所用的所有术语(包括技术和科学术语)都具有与本发明所属领域的技术人员通常所理解的相同的含义。还会理解，诸如常用词典中定义的那些术语之类的术语应当被解释为具有与它们在本说明书的上下文和相关领域中的含义一致的含义，而不可理想化地或过分刻板地解释，除非本文中这样明确定义。
61.此外，在至少一些附加或备选实现中，框中所述的功能/动作可不按照流程图所示的顺序发生。例如，接连示出的两个框实际上可基本同时执行，或者这些框有时可按照相反顺序执行，这取决于所涉及的功能性/动作。此外，流程图和/或框图的给定框的功能性可分为多个框，和/或流程图和/或框图的两个或更多框的功能性可至少部分相结合。此外，虽然有些附图包括通信路径上的箭头以表明通信的主要方向，但是要理解，通信可沿与所示箭头相反的方向发生。最后，在所示的框之间可添加或插入其它框。
62.因此，应当清楚地理解，本公开的附图中所示流程图的任一个中所示的动作、步骤、功能、组件或框的顺序或序列可在特定流程图中修改、变更、替代、定制或者以其它方式重新排列，包括特定动作、步骤、功能、组件或框的删除或省略。此外，特定流程图中所示的动作、步骤、功能、组件或框可与另一个流程图中所示的动作、步骤、功能、组件或框相互混合或者以其它方式相互排列或重新排列，以便为了实施本专利公开的教导而关于一个或多个过程实现附加变化、修改和配置。
63.虽然已经详细示出和描述了各种实施例，但是权利要求并不局限于任何具体实施例或示例。以上详细描述决不应当被解读为暗示任何具体组件、单元、步骤、动作或功能是必要的而使得它必须包含在权利要求的范围中。除非明确说明，否则以单数形式提到某个单元并非意在表示“唯一的”，而是表示“一个或多个”。本领域技术人员已知的上述实施例的单元的所有结构和功能等效物通过引用明确地结合于本文中，并且意在被本权利要求书涵盖。因此，本领域技术人员会认识到，本文所述的示范实施例能够采用以下所附权利要求书的精神和范围之内的各种修改和变更来实施。