CN105594219B - 用于广播信号的发射/接收处理的设备和方法 - Google Patents

Abstract

公开一种广播发射设备。广播发射设备包括：交付对象产生器，被配置为产生至少一个交付对象，交付对象被包括在服务的内容组件中并被单独地恢复；信令信息产生器，被配置为产生信令信息，信令信息提供服务和内容组件的发现和获取；以及发射器，被配置为通过单向信道发射至少一个交付对象和信令信息。

Description

用于广播信号的发射/接收处理的设备和方法

技术领域

本发明涉及用于发射/接收媒体信号的方法和设备。本发明尤其涉及用于处理在其中将宽带和广播组合的广播系统中通过宽带和广播的每一个来发射的媒体数据的方法和设备。

背景技术

随着模拟广播信号发射的终结，用于发射和接收数字广播信号的各种技术得到发展。与模拟广播信号相比，数字广播信号可包括更大量的视频/音频数据，并且除了视频/音频数据之外，还包括各种类型的附加数据。

发明内容

技术问题

被设计为解决问题的本发明目的在于提供一种用于处理混合广播系统中的数据的适当方法和设备，在混合广播系统中，通过传统广播网络发射数据的方案与通过宽带网络发射数据的方案交互操作。

技术方案

本发明目的可通过提供一种广播发射设备来实现，该广播发射设备包括：交付对象产生器，被配置为产生至少一个交付对象，交付对象被包括在服务的内容组件中并且被单独地恢复；信令信息产生器，被配置为产生信令信息，信令信息提供服务和内容组件的发现和获取；以及发射器，被配置为通过单向信道发射至少一个交付对象和信令信息。

优选地，其中，交付对象是文件、文件的一部分、文件的群组、超文本传送协议(HTTP)实体、以及HTTP实体的群组的其中一个。

优选地，其中，信令信息包括描述传输会话的第一信息，传输会话发射服务的内容组件。

优选地，其中，第一信息包括描述在传输会话中发射的源数据的第二信息。

优选地，其中，第二信息包括EFDT元素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier元素、和/或PayloadFormat元素的至少其中一个，EFDT元素指定文件交付数据的细节，idRef属性识别EFDT元素，realtime属性指示是否实时交付交付对象，minBufferSize属性限定需要存储在接收器中的数据的最大量，ApplicationIdentifier元素提供能够映射到应用的信息，PayloadFormat元素限定携带交付对象的分组的有效载荷格式。

优选地，其中，PayloadFormat元素包括codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFecPayloadID属性、以及FECParamenters元素的至少其中一个，codePoint属性限定将什么codePoint值用于有效载荷，deliveryObjectFormat属性指定交付对象的有效载荷格式，fragmentation属性指示交付对象的单元，deliveryOrder属性指示包含交付对象的数据的分组的交付顺序，sourceFecPayloadID属性限定源FEC有效载荷ID的格式，FECParamenters元素限定FEC参数。

优选地，其中，EFDT元素包括idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、以及FileTemplate元素的至少其中一个，idRef属性识别EFDT元素，version属性指示EFDT元素的版本，maxExpiresDelta属性指示在传输会话中用于对象的最大期满时间，所述maxTransportSize属性指示通过所述EFDT元素描述的对象的最大传输大小，FileTemplate元素指定文件URL。

本发明目的可通过提供一种广播接收设备来实现，该广播接收设备包括：广播接口，被配置为通过单向信道接收包括服务的广播信号；信令解析器，被配置为提取信令信息，信令信息提供服务以及服务的内容组件的发现和获取；以及交付对象处理器，被配置为基于信令信息恢复至少一个交付对象。

优选地，其中，交付对象是文件、文件的一部分、文件的群组、超文本传送协议(HTTP)实体、以及HTTP实体的群组的其中一个。

优选地，其中，信令信息包括描述传输会话的第一信息，传输会话发射所述服务的内容组件。

优选地，其中，第一信息包括描述在传输会话中发射的源数据的第二信息。

优选地，其中，第二信息包括EFDT元素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier元素、和/或PayloadFormat元素的至少其中一个，EFDT元素指定所述文件交付数据的细节，idRef属性识别EFDT元素，realtime属性指示是否实时交付交付对象，minBufferSize属性限定需要存储在接收器中的数据的最大量，ApplicationIdentifier元素提供能够映射到应用的信息，PayloadFormat元素限定携带交付对象的分组的有效载荷格式。

优选地，其中，PayloadFormat元素包括codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFecPayloadID属性、以及FECParamenters元素的至少其中一个，codePoint属性限定将什么codePoint值用于有效载荷，deliveryObjectFormat属性指定交付对象的有效载荷格式，fragmentation属性指示交付对象的单元，deliveryOrder属性指示包含交付对象的数据的分组的交付顺序，sourceFecPayloadID属性限定源FEC有效载荷ID的格式，FECParamenters元素限定FEC参数。

优选地，其中，EFDT元素包括idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、以及FileTemplate元素的至少其中一个，idRef属性识别述EFDT元素，version属性指示EFDT元素的版本，maxExpiresDelta属性指示在传输会话中用于对象的最大期满时间，maxTransportSize属性指示通过EFDT元素描述的对象的最大传输大小，FileTemplate元素指定文件URL。

本发明的有益效果

根据本发明实施例的广播信号发射设备在减少用于发射多媒体内容的发射待机时间方面有效。

此外，根据本发明实施例的广播信号接收设备在减少用于再现多媒体内容的再现待机时间方面有效。

此外，本发明在减少从获取多媒体内容到向用户显示多媒体内容所用的总时间方面有效。

此外，本发明在减少用户访问广播信道时的初始延时时间方面有效。

此外，根据本发明实施例，可以实时发射和/或接收MPEG-DASH媒体片段文件。

附图说明

图1是示出根据本发明实施例的广播系统的方框图；

图2是示出根据本发明实施例的ROUTE协议栈的示意图；

图3是示出根据本发明实施例的广播系统的示意图；

图4是示出根据本发明实施例的ROUTE协议的广播发射设备的操作的示意图；

图5是示出根据本发明实施例的分层编码传输会话实例描述(LSID)的示意图；

图6是示出根据本发明实施例的SourceFlow元素的示意图；

图7是示出根据本发明实施例的交付对象的格式的示意图；

图8是示出根据本发明实施例的文件模式中的ROUTE分配与FLUTE分配之间的比较的示意图；

图9是示出根据本发明实施例的扩展文件交付表(EFDT)的示意图；

图10是示出根据本发明实施例的用于文件模板的标识符的示意图；

图11是示出根据本发明实施例的ROUTE分组格式的示意图；

图12是示出根据本发明实施例的EXT_PRESENTATION_TIME报头的示意图；

图13是示出根据本发明实施例的广播发射设备的操作的流程图；

图14是示出根据本发明实施例的广播接收设备的方框图；

图15是示出根据本发明实施例的广播接收设备的操作的流程图；

图16是示出根据本发明实施例的广播接收设备的FEC分组产生的示意图；

图17是示出根据本发明实施例的FEC传输对象的示意图；

图18是示出根据本发明实施例的EXT_TOL报头的示意图；

图19是示出根据本发明实施例的RepairFlow元素的示意图；

图20是示出根据本发明实施例的ProtectedObject元素的示意图；

图21是示出根据本发明实施例的RepairFlow公告的示意图；

图22是示出根据本发明实施例的RepairFlow公告的示意图；

图23是示出根据本发明实施例的RepairFlow公告的示意图；

图24是示出根据本发明实施例的RepairFlow公告的示意图；

图25是示出根据本发明实施例的RepairFlow公告的示意图；

图26是示出根据本发明实施例的广播接收设备的方框图；

图27是示出根据本发明实施例的MPD的示意图；

图28是示出根据本发明实施例的URI形式的示意图；

图29是示出根据本发明实施例的URI形式的示意图；

图30是示出根据本发明实施例的用于MP4分段标识符的参数的示意图；以及

图31是示出根据本发明实施例的接收器的操作的流程图。

具体实施方式

下面，虽然参照附图及其描述详细描述了本发明的优选实施例，但是本发明不被实施例约束或限制。

虽然在考虑根据本发明所获得的功能时尽可能从当前广泛使用的一般术语中选择以下描述中所使用的术语，但是基于本领域技术人员的意图、习惯、新技术的出现等等，可以用其他术语代替这些术语。此外，在特殊情况下，可以使用本发明申请人任意选择的术语。在这种情况下，在本发明的对应描述部分中描述这些术语的含义。因此要注意，基于其实际含义以及本说明书的全部内容来解释本文使用的术语，而不是基于术语的名称简单地解释。

在本说明书中，术语“信令”表示广播系统、互联网广播系统和/或广播/互联网集成系统中提供的服务信息(SI)的发射/接收。服务信息包括每个现有广播系统中提供的广播服务信息(例如，ATSC-SI和/或DVB-SI)。

在本说明书中，术语“广播信号”被定义为包括通过双向广播，诸如除了陆地广播、有线广播、卫星广播和/或移动广播之外，还有互联网广播、宽带广播、通信广播、数据广播、视频点播(VOD)等等，提供的信号和/或数据的概念。

在本说明书中，术语“物理层管道(PLP)”表示用于发射物理层中包括的数据的某个单元。因此，在本说明书中，可将称为“PLP”的内容替代性地称作“数据单元”或“数据管道”。

使用广播网络与互联网协议网络之间链路的混合广播服务可以是要在数字电视(DTV)服务中使用的其中一个基本应用。混合广播服务通过经由互联网协议网络发射与经由陆地广播网络发射的音频/视频(A/V)内容有关的增强内容或者实时发射一部分A/V内容使得用户能够体验各种内容。

图1示出根据本发明实施例的广播系统C11。

参照附图，根据本实施例的广播系统C11可包括广播发射设备C110、广播接收设备C120、内容提供器C130和/或内容服务器C140的至少其中一个。

内容提供器C130可以向广播发射设备C110以及内容服务器C140提供广播服务。

广播发射设备C110可以利用卫星、地波和/或有线广播网络的至少其中一个来发射包括广播服务的广播信号。广播发射设备C110可包括控制器(未示出)和发射器(未示出)。控制器可以控制广播发射设备C110的操作。例如，广播发射设备C110还可包括内容提供器C130和/或内容服务器C140。

内容服务器C140可以基于来自广播接收设备C120的请求发射广播服务。

广播接收设备C120可以利用广播网络(例如广播)和/或互联网协议网络(例如宽带互联网)的至少其中一个来接收广播服务。广播接收设备C120可包括广播接口C1210、宽带接口C1230和/或控制单元C1250的至少其中一个。

广播接收设备C120可以利用广播接口C1210来接收包括广播服务的广播信号。在这种情况下，可以利用卫星、地波和/或有线广播网络的至少其中一个来发射广播信号。因此，广播接口C1210可包括卫星调谐器、地波调谐器和/或有线调谐器的至少其中一个来接收广播信号。

广播接收设备C120可以请求内容服务器C140利用宽带接口C1230来提供广播服务。广播接收设备C120可以利用宽带接口C1230接收来自内容服务器C140的广播服务。

广播接收设备C120可以利用解码器(未示出)将广播服务解码。

广播接收设备C120可以利用控制单元C1250控制广播接口C1210、广播接口C1230和/或解码器的至少其中一个。

图2示出根据本发明实施例的ROUTE协议栈。

根据本实施例的广播发射设备可以基于ROUTE协议栈发射广播服务。

除了媒体数据(例如视频数据、音频数据、以及隐藏字幕数据)之外，根据本实施例的广播服务还可包括附加服务，诸如HTML5应用、交互服务、ACR服务、第二屏幕服务、个性化服务等等。

例如，支持基于互联网协议(IP)的混合广播的下一代广播系统的广播服务可包括实时内容数据、信令数据、电子服务指南(ESG)数据、和/或非实时(NRT)内容数据。

广播服务可通过诸如地波、有线、卫星等等这样的广播网络(广播)来发射。此外，根据本实施例的广播服务可通过互联网协议网络(宽带)来发射。

首先，描述通过广播网络发射广播服务的方法。

媒体数据可包括视频数据、音频数据、和/或字幕数据。可将媒体数据封装在运动图像专家组(MPEG)-超文本传输协议(HTTP)上的动态自适应流(DASH)的片段和/或MPEG媒体传输(MMT)的媒体处理单元处理部(MPU)中。例如，MPEG-DASH的片段和/或MMT的MPU的文件格式可以是ISO基础媒体文件(以下称为ISO BMFF)。

可将信令数据、ESG数据、NRT内容数据、和/或实时内容数据封装在支持实时发射的应用层传输协议分组中。例如，实时内容数据可包括诸如视频数据、音频数据、和/或字幕数据这样的媒体数据。此外，NRT内容数据可包括媒体数据和/或应用。此外，应用层传输协议可包括单向传输(ROUTE)和/或MMT上的实时对象交付。应用层传输协议分组可包括ROUTE分组和/或MMT分组。下面用分组来简单表示应用层传输协议分组。

然后，可将封装在应用层传输协议分组中的数据封装在用户数据报协议(UDP)数据报中。

然后，可将UDP数据报封装在IP数据报中。例如，该IP数据报可以是基于IP多播或IP单播方案的数据报。

然后，可通过广播信号来发射IP数据报。例如，可通过物理层(广播PHY)来发射IP数据报。

根据信令属性，根据本实施例的信令数据可通过交付给广播网络的物理层以及下一代广播发射系统的传输帧(或帧)的特定PLP来发射。例如，信号可具有封装在比特流或IP数据报中的形式。

下面描述通过互联网协议网络发射广播服务的方法。

可将信令数据、ESG数据、NRT内容数据、和/或实时内容数据封装在HTTP分组中。

然后，可将封装在HTTP分组中的数据封装在传输控制协议(TCP)分组中。可将根据本实施例的广播服务直接封装在TCP分组中。

然后，可将TCP分组封装在IP数据报中。例如，IP数据报可以是基于IP多播或IP单播方案的数据报。

然后，可通过广播信号发射IP数据报。例如，可通过物理层(广播PHY)发射IP数据报。

在互联网协议网络中，可以响应于来自接收器的请求交付信令数据、ESG数据、NRT内容数据、和/或实时内容数据。

广播接收设备可基于上述ROUTE协议栈接收广播服务。

下面主要集中于将上述信令数据、ESG数据、NRT内容数据、和/或实时内容数据封装在ROUTE的传输分组中的情况进行描述。

通过单向传输的实时对象交付(ROUTE)是用于通过IP多播网络交付文件的协议。ROUTE协议采用异步分层编码(ALC)、为大规模可扩展多播分发设计的基本协议、分层编码传输(LCT)以及其他公知的互联网标准。ROUTE是具有附加特征的FLUTE的增强和功能替换。

附图示出在用于实时和非实时内容的混合(广播/宽带)交付的接收器协议栈的背景下的ROUTE。如图所示，ROUTE用于交付信令消息、电子服务指南(ESG)消息、以及NRT内容。它特别适合于交付流媒体，例如MPEG-DASH媒体片段文件。与FLUTE相比，ROUTE通过交付链提供更低的端到端延迟。

ROUTE协议是通用传输应用，提供任何类型对象的交付。它支持丰富的呈现，包括场景描述、媒体对象和DRM相关信息。ROUTE特别适合于实时媒体内容的交付，并提供很多特征。

例如，ROUTE提供个别交付以及对不同媒体组件，例如语言音轨、副标题、替代性视频视图，的访问。此外，ROUTE通过实现不同传输会话乃至ROUTE会话上的交付，提供分层编码的支持。此外，ROUTE提供对灵活FEC保护的支持，包括多级式。此外，ROUTE提供与MPEG-DASH的方便组合，实现DASH的广播与宽带交付模式之间的协同。此外，ROUTE在加入ROUTE和/或传输会话时提供对媒体的快速访问。此外，ROUTE通过集中于交付概念来提供高扩展性。此外，ROUTE通过现有IETF协议以及IETF支持的扩展机制的使用来提供兼容性。

ROUTE协议分为两个主要组件。第一组件是源协议，用于对象或流的交付/对象的收集。第二组件是修复协议，用于灵活保护交付对象或通过源协议交付物交付的交付对象的捆绑。

源协议独立于修复协议，即，可以在没有ROUTE修复协议的情况下部署源协议。可以仅对于某些部署场景添加修复，例如仅对于移动接收，仅在某些地理区域中，仅对于某些服务等等。

源协议符合RFC 6726中限定的FLUTE以及3GPP TS 26.346中限定的扩展，但是也使用RFC 6968中限定的FCAST的一些原理，例如，可以在复合对象中一起发送对象元数据和对象内容。

除了基本FLUTE协议之外，还添加某些优化和约束，以实现对媒体数据的实时交付的优化支持；因此，协议的名称。此外还有，源ROUTE协议提供基于对象的媒体数据的实时交付。此外，源ROUTE协议提供灵活的分组化，包括实现交付对象的媒体方面的分组化以及传输方面的分组化。此外，源ROUTE协议提供文件和交付对象的独立，即，交付对象可以是文件的一部分，也可以是文件的群组。

ROUTE修复协议基于FEC，并且被实现为传输层(例如UDP)与对象交付层协议之间的附加层。FEC重新使用RFC 6363中限定的FEC框架的概念，但是与RFC 6363中的FEC框架对比，ROUTE修复协议不保护分组，而是保护在源协议中交付的交付对象。每个FEC源块可包括交付对象的各部分，作为单个交付对象(类似于FLUTE)，或者通过在FEC保护之前捆绑的多个交付对象。ROUTE FEC按照与RFC 5052中限定的类似含义使用FEC方案，并使用该文档的术语。FEC方案限定FEC编码和解码，并限定在FEC方案背景下用于识别分组有效载荷数据的协议字段和过程。

在ROUTE中，所有分组都是在RFC 5651中限定的LCT分组。可通过不同的ROUTE会话来区分源和修复分组，即，在不同的IP/UDP端口组合上携带不同的ROUTE会话。此外，可通过不同的LCT传输会话来区分源和修复分组，即，不同的LCT传输会话在LCT报头中使用不同的TSI值。此外，如果被携带在相同的LCT传输会话中，那么可通过LCT中的PSI比特来区分源和修复分组。这种操作模式最适合于FLUE兼容部署。

ROUTE限定源协议，包括分组格式、发送行为、和/或接收行为。此外，ROUTE限定修复协议。此外，ROUTE限定用于传输会话建立的元数据以及用于对象流交付的元数据。此外，ROUTE限定用于MPEG DASH配置的推荐以及向ROUTE的映射，以实现丰富和高质量的线性TV广播服务。

图3示出根据本发明实施例的广播系统。

根据本实施例的广播系统可包括广播发射设备和/或广播接收设备的至少其中一个。广播发射设备可包括控制器C3150和发射器(未示出)的至少其中一个。广播接收设备可包括广播接口(未示出)、宽带接口(未示出)、和/或控制器C3250的至少其中一个。根据本实施例的广播系统的基本描述类似于以上描述。

广播发射设备可将广播服务交付给广播接收设备。例如，广播发射设备可将媒体数据和/或DASH格式交付给广播接收设备。

广播发射设备的控制器C3150可包括编码器&DASH器C31530和/或ROUTE发送器C31550的至少其中一个。

编码器&DASH器C31530可将广播服务编码，以及将编码的广播服务封装在MPEG-DASH的至少一个片段中。

例如，编码器&DASH器C31530可将信令数据、ESG数据、NRT内容数据、以及实时内容数据的至少其中一个编码，并将编码数据封装在MPEG-DASH的至少一个片段中。MPEG-DASH的片段的文件格式可以是ISO BMFF。

基于至少一个片段，ROUTE发送器C31550可以生成信令信息和/或至少一个交付对象(或对象)。

信令信息可包括广播服务的发现和/或描述信息。例如，信令信息可包括链路层信令信息和/或服务层信令信息。此外，信令信息可包括ROUTE会话描述、LCT传输会话描述(或LCT会话描述)、和/或交付对象元数据(或对象元数据)。ROUTE会话描述可包括与ROUTE会话有关的信令信息。LCT传输会话描述可包括与LCT传输会话有关的信令信息。交付对象元数据可包括与交付对象有关的信令信息。

交付对象可包括与片段有关的数据。例如，交付对象可包括片段中包括的数据的一部分和/或全部。

ROUTE发送器C31550可将信令信息和/或至少一个交付对象分组化在分组中。例如，分组可包括LCT分组。

然后，广播发射装置可以使用ROUTE发送器C31550和/或发射器(未示出)来发射包括信令信息和/或至少一个交付对象的分组。

广播接收设备可以接收广播服务以及将广播服务解码。例如，广播接收设备可以使用广播接口和/或宽带接口接收包括广播服务的广播信号。广播接收设备可以使用控制器C3250将广播服务解码。广播接收设备的控制器C3250可包括ROUTE接收器C32530和/或DASH客户端C32550的至少其中一个。

ROUTE接收器C32530可以接收广播服务以及还原信令信息和/或至少一个交付对象。ROUTE接收器C32530可以基于包括广播服务的分组来还原信令信息和/或至少一个交付对象。信令信息可包括物理层信令信息、链路层信令信息、服务层信令信息、交付对象元数据、和/或定时信息的至少其中一个。例如，信令信息可包括ROUTE会话描述、LCT传输会话描述、和/或交付对象元数据的至少其中一个。交付对象可包括与源协议有关的交付对象和/或与修复协议有关的交付对象的至少其中一个。ROUTE接收器C32530可包括分组接收器C32531、对象恢复块C32533、FEC解码器C32535、和/或交付对象缓存C32537的至少其中一个。

分组接收器C32531可接收包括广播服务的至少一个分组。例如，分组可包括LCT分组。

对象恢复块C32533可基于包括广播服务的至少一个分组，还原至少一个交付对象和/或与源协议有关的信令信息。

FEC解码器C32535可基于包括广播服务的至少一个分组，还原至少一个交付对象和/或与修复协议有关的信令信息。

交付对象缓存C32537可存储信令信息和/或至少一个交付对象，并将信令信息和/或至少一个交付对象交付给DASH客户端C32550。交付对象缓存C32537可基于定时信息，将信令信息和/或至少一个交付对象交付给DASH客户端C32550。

例如，定时信息可包括同步信息、节目时钟参考(PCR)、解码时间戳(DTS)、和/或呈现时间戳(PTS)的至少其中一个，PCR指示用于一个频道节目的参考时间，DTS指示解码时间，PTS指示再现时间。

DASH客户端C32550可基于信令信息将至少一个交付对象解码。例如，DASH客户端C32550可基于DASH媒体呈现和/或定时信息将至少一个交付对象解码。

ROUTE协议的范围是交付对象以及使用LCT分组的关联元数据的可靠交付。通过交付对象缓存，使得对象可用于应用。该缓存的实施方式依赖于应用。

ROUTE协议集中于LCT分组的格式，以交付交付对象。此外，ROUTE协议集中于基于FEC，利用修复协议可靠地交付交付对象。此外，ROUTE协议集中于连同交付对象一起，限定和交付对象元数据，以实现交付对象缓存与应用之间的接口。此外，ROUTE协议集中于ROUTE和LCT会话描述，以连同它们的元数据一起建立对象的接收。此外，ROUTE协议集中于要连同分组一起交付的辅助信息的规范性方面(格式、语义)，以优化例如实时交付的特定应用的性能。

此外，ROUTE协议向ROUTE交付提供特定的DASH媒体呈现格式，以及要用于交付的合适的DASH格式。关键问题在于，通过利用ROUTE，可以照原样使用DASH媒体格式。这种体系结构设计实现融合的单播/广播服务。

图4是示出根据本发明实施例的ROUTE协议的广播发射设备的操作的示意图。

附图示出基本发送器概念。建立交付LCT分组的ROUTE会话。这些分组可以携带源对象或FEC修复数据。根据自上而下的方法，源协议包括一个或多个LCT会话，分别连同它们的元数据一起携带关联对象。元数据可以在LCT会话实例描述(LSID)中静态地交付，也可以动态地交付，或者作为实体模式中的复合对象，或者作为分组报头中的LCT扩展报头。使用特定FEC方案在ALC中携带分组，该特定FEC方案允许在任意字节边界将对象灵活划分。此外，单独地或者捆绑地，交付对象可以是FEC保护的。在任何情况下，捆绑的对象被编码，并且只交付修复分组。在与源分组的组合中，这样允许恢复交付对象捆绑。注意，可以产生一个或多个修复流，每个流有不同的特性，例如支持不同的延迟要求、不同的保护要求等等。

DMD(动态元数据)是在客户端动态地产生FDT等效描述的元数据。在实体模式中它携带在实体报头中，而在交付的其他模式中它携带在LCT报头中。

ROUTE协议支持源数据的不同保护和交付方案。它还支持用于NRT交付的所有现有使用情况，因为它可以部署在向后兼容模式中。

对于实时交付的情况，交付对象和可能的关联FEC需要被交付为使得交付对象在它们适当时可用于应用。

仅源协议能够被交付。ROUTE协议可用于实时交付。在这种情况下，可将LSID中的@realtime标记设置为真。

如果将@realtime标记设置为真，则以下应当成立。所有对象应当被交付为使得最后的分组在应用特定期限之前可用。通过应用提供更多的细节。对于所有的随机访问点，应当提供EXT_PRESENTATION_TIME报头。为了在它们的接收与它们的呈现时间之间存储所有分组，@minBufferSize可以提供以kByte为单位的最小要求大小。LSID中的EFDT应当被嵌入，或者被提供作为参考。

可以交付修复协议。如果包括FEC并呈现修复流公告的@minBufferTime，则@minBufferTime表达用于修复流的最小缓冲时间。

参照安全性考虑，与RFC 5775中限定的ALC有关。

参照规则的NRT内容交付，通过FLUTE或ROUTE可以实现规则的文件交付。通过FLUTE或ROUTE可以实现元数据交付。

图5示出根据本发明实施例的LSID。

ROUTE会话与IP地址/端口组合相关联。通常，通过加入这种会话，可以接收会话的所有分组，并且应用协议可以申请进一步处理。

每个ROUTE会话包括一个或多个LCT传输会话。LCT传输会话是ROUTE会话的子集。对于媒体交付，LCT传输会话通常会携带媒体组件，例如DASH表现(Representation)。从广播DASH的角度看，可将ROUTE会话视为携带一个或多个DASH媒体呈现的组成媒体组件的LCT传输会话的复用。在每个LCT传输会话中，携带一个或多个对象，通常是有关的对象，例如，与一个表现相关联的DASH片段。连同每个对象一起交付元数据特性，使得能够在应用中使用对象。应用包括但不限于DASH媒体呈现、HTML-5呈现、或者任何其他对象消耗应用。

从时间的角度看，可以限制ROUTE会话，也可以解除限制。ROUTE会话包含一个或多个LCT传输会话。每个传输会话通过LCT报头中的唯一传输会话标识符(TSI)唯一地识别。

在接收器能够加入ROUTE会话之前，接收器需要获得ROUTE会话描述。ROUTE会话描述包含下述中的至少一个，发送器IP地址、用于会话的地址和端口号、会话为ROUTE会话并且所有分组为LCT分组的指示、和/或在IP/UDP级上加入和消耗会话所必要的其他信息。

会话描述还可包括但不限于用于ROUTE会话的数据速率以及关于ROUTE会话的持续时间的任何信息。

会话描述可以采用诸如RFC4566中限定的会话描述协议(SDP)或者RFC3023中限定的XML元数据这样的形式。它可被以携带在使用专有会话控制协议的任何会话通告协议中、位于具有调度信息的网页中、或者经由电子邮件或其他带外方法来表达。

传输会话不是在ROUTE会话描述中而是在LCT会话实例描述(LSID)中描述。传输会话(即LCT传输会话或简单LCT会话)可包含源流和修复流的任一个或全部。源流携带源数据。此外，修复流携带修复数据。

ROUTE会话中包含的LCT传输会话通过LCT会话实例描述(LSID)来描述。具体而言，它限定在ROUTE会话的每个组成LCT传输会话中携带什么。每个传输会话通过LCT报头中的传输会话标识符(TSI)唯一地识别。

LSID描述在该ROUTE会话上携带的所有传输会话。可以在包含LCT传输会话的相同ROUTE会话中交付LSID，或者可以通过在ROUTE会话外部，例如，通过单播或者通过不同的ROUTE会话，交付LSID。在前一种情况下，LSID应当在TSI＝0的专用LCT传输会话上交付，进而，它应当是通过TOI＝0来识别的交付对象。对于在TSI＝0上交付的任何对象，应当使用实体模式。如果不在实体模式中交付这些对象，那么对于接收的对象，必须在获得扩展FDT之前恢复LSID。

LSID的互联网媒体类型是应用/xml+route+lsid。

LSID可以参考其他数据分段。在LSID中参考的任何对象也可以在TSI＝0上交付，但是与该LSID本身相比具有不同的TOI的值，或者它可以在专用TSI≠0的单独LCT会话上交付。

附图示出LSID元素。LSID元素可包含version属性、有效性属性、和/或期满属性。LSID元素可以因此利用version属性以及有效性属性和期满属性来更新。例如，在一定时间之后可以终止某些传输会话，并且可以启动新的会话。

version属性指示该LSID元素的版本。当描述符更新时将版本加一。所接收的有最高版本号的LSID是当前有效版本。

有效性属性指示LSID元素有效的日期和/或时间。有效性属性可以呈现，也可以不呈现。如果不呈现，则接收器应当假定LSID元素版本立即有效。

期满属性指示LSID元素期满的日期和时间。期满属性可以呈现，也可以不呈现。如果不呈现，则接收器应当假定LSID元素总是有效，或者直到它接收具有关联期满值的更新LSID元素。

LSID元素可包含至少一个TransportSession元素。TransportSession元素提供关于LCT传输会话的信息。每个TransportSession元素可包含tsi属性、SourceFlow元素、和/或RepairFlow元素的至少其中一个。

tsi属性指定传输会话标识符。会话标识符不能为0。

SourceFlow元素提供该tsi上携带的源流的信息。

RepairFlow元素提供该tsi上携带的修复流的信息。

图6示出根据本发明实施例的SourceFlow元素。

源协议是ROUTE为了通过单向信道发射交付对象的核心组件。为了在对象流中交付有关对象，源协议在ROUTE会话中建立一个或多个源流。每个对象单独地被恢复。

源协议符合RFC 6726中限定的FLUTE以及3GPP TS 26.346中限定的扩展，但是也使用RFC 6968中限定的FCAST的一些原理，例如，可以在复合对象中一起发送对象元数据和对象内容。源协议独立于修复协议，即，可以在没有ROUTE修复协议的情况下部署源协议。可以仅对于某些部署场景添加修复，例如对于移动接收，在某些地理区域中，对于某些服务等等。

通过源流的描述来限定源协议。源流发送交付对象。源协议使用ALC和LCT来交付对象。

附图示出SourceFlow元素的语义。以下元素描述源流。

SourceFlow元素限定会话中的源流。SourceFlow包括EFDT元素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier元素、和/或至少一个PayloadFormat元素的至少其中一个。

EFDT元素指定文件交付数据的细节。这是扩展FDT实例。EFDT可以被嵌入，也可以被提供作为参考。如果被提供作为参考，则可以独立于LSID来更新EFDT。如果被参考，则应当在所包括的源流的TOI＝0上将其作为带内对象交付。

idRef属性是EFDT的身份，通过对应的传输会话，可以将其表示为URI。

realtime属性指示是否实时交付交付对象和/或可能的关联FEC。如果realtime属性呈现并设置为真，则LCT分组包含扩展报头，扩展报头包括NTP时间戳，NTP时间戳表示所包括的交付对象的呈现时间。如果realtime属性不呈现，则它为假。

minBufferSize属性限定需要存储在接收器中的数据的最大量。如果将@realtime设置为真，则可以呈现该值。

为了选择用于展示的LCT传输会话，ApplicationIdentifier元素提供能够映射到在该传输会话中携带的应用的附加信息，例如，DASH内容的表现ID或者DASH表现的适配集参数。

例如，ApplicationIdentifier元素可包括映射信息。映射信息可以指示信令信息的统一资源定位符(URL)。此外，除了交付对象的唯一地址、对象、或会话之外，映射信息可包括在信令信息中分配的标识符。标识符可包括周期ID、适配集ID、表现ID、和/或组件ID。因此，在MPEG-DASH内容中，映射信息可包括片段URL、表现ID、组件ID、适配集ID、周期ID等等。

对于更完善的映射，根据本实施例的ApplicationIdentifier元素还可包括用于将对象的标识符或URL映射到TOI或TSI的映射信息。换言之，ApplicationIdentifier元素还可包括指示当前发射的TOI和/或TSI所映射的对象的标识符和/或URL的信息。在这种情况下，映射信息可以是在一对一基础、一对多基础、或者多对一基础上用于将对象的标识符和/或URL映射到TOI和/或TSI的信息。

PayloadFormat限定携带源流的对象的ROUTE分组的有效载荷格式。PayloadFormat可包括codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFecPayloadID属性、和/或FECParamenters的至少其中一个。

codePoint属性限定将什么codePoint值用于该有效载荷。在LCT报头中这是CP字段的值。在发信号通知该值的时候，对象的交付应当服从以下规则。

deliveryObjectFormat属性指定交付对象的有效载荷格式。

fragmentation属性指示交付对象的单元。例如，如果将fragmentation属性设置为0，则单元可以是任意单元。如果将fragmentation属性设置为1，则单元可以是作为基于样本的单元的应用特定单元。如果将fragmentation属性设置为2，则单元可以是作为盒子的聚合的应用特定单元。

fragmentation属性可以指示通过分组发射的交付对象的单元。或者，fragmentation属性可以指示划分交付对象的规则。例如，fragmentation属性可以指示是否将DASH片段划分为样本、盒子、和/或某长度的其中一个。

对象可以对应于MPEG-DASH的片段和/或MMT的MPU，并且交付对象可以对应于对象中包括的子组件。交付对象表示可以独立解码和/或在不依赖在先数据的情况下再现的数据单元。

交付对象的单元的示例可包括文件、分段、数据块、GOP、访问单元、和/或NAL单元。交付对象的单元不限于此，还可以包括有意义的单元。

分段可以表示包括一对电影分段盒子(moof)和媒体数据容器盒子(mdat)的数据单元。例如，分段可以对应于MPEG-DASH的子片段，以及对应于MMT的分段。分段可包括至少一个数据块或者至少一个GOP。

数据块对应于具有相同媒体类型的相邻样本的集合，以及具有可变大小的数据单元。

GOP对应于用于进行在视频编码中使用的编码的基本单元，以及具有可变大小的数据单元，其指示包括至少一个I帧的帧的集合。根据本发明实施例，在对应于有意义的数据单元的交付对象中独立发射媒体数据，并且因此，GOP可包括开放GOP和/或封闭GOP。

在开放GOP中，一个GOP中的B帧可以表示相邻GOP的I帧或P帧。因此，开放GOP可以显著提升编码效率。在封闭GOP中，B帧或P帧只表示GOP中的帧，不表示GOP之外的帧。

访问单元对应于编码的视频或音频的基本数据单元，并且可包括一个图像帧或音频帧。

基于与网络装置的通信，NAL单元对应于封装和压缩的视频流，视频流包括关于压缩片的摘要信息。例如，NAL单元可以对应于通过将数据分组化所获得的数据单元，例如以字节为单位的NAL单元片、参数集合、SEI等等。

deliveryOrder属性指示包含交付对象的数据的分组的交付顺序。例如，如果将deliveryOrder属性设置为0，则deliveryOrder属性指示任意顺序。如果将deliveryOrder属性设置为1，则deliveryOrder属性指示顺序交付。如果将deliveryOrder属性设置为2，则deliveryOrder属性指示按照顺序交付来交付媒体样本，并且在电影分段盒子之前交付媒体样本。

交付对象可包括报头和有效载荷。产生和/或消耗交付对象的报头的顺序可以不同于产生和/或消耗交付对象的有效载荷的顺序。根据本实施例的接收器可以按照消耗顺序，通过重新布置按照产生顺序接收的分组来再现交付对象。

下面详细描述将deliveryOrder属性设置为0的情况。

广播发射设备可以按照任意顺序发射包括交付对象的数据的分组。广播接收设备可以按照任意顺序接收分组并重新布置分组。然后，广播接收设备可以准确地还原、解析、和/或再现交付对象。

下面详细描述将deliveryOrder属性设置为1的情况。

当先前将媒体数据编码或者先前产生源块时，包括交付对象的数据的分组的发射顺序可以与解析分组的顺序相同。例如，广播发射设备可以先发射对应于交付对象的报头的分组，然后发射对应于交付对象的有效载荷的分组。广播接收设备可以先接收对应于交付对象的报头的分组，然后接收对应于交付对象的有效载荷的分组。之后，广播接收设备可以准确地还原、解析、和/或再现交付对象。

下面详细描述将deliveryOrder属性设置为2的情况。

为了产生交付对象，根据本实施例的广播发射设备可以先产生交付对象的有效载荷，然后产生交付对象的报头。在这种情况下，广播发射设备可以产生包括交付对象的有效载荷中的媒体数据的源块。例如，可以依次产生包括在媒体数据盒子(mdat)中包括的媒体数据的至少一个源块。之后，广播发射设备可以产生包括交付对象的报头的源块。

为了实时发射媒体内容，广播发射设备可以按照产生顺序来发射源块。换言之，广播发射设备可以先发射包括交付对象的有效载荷的源块(或分组)，然后发射包括交付对象的报头的源块(或分组)。

在这种情况下，根据本实施例的广播接收设备可以接收并重新布置分组。然后，广播接收设备可以准确地还原交付对象。广播接收设备可以先解析交付对象的报头，然后解析交付对象的有效载荷。

sourceFecPayloadID属性限定Source FEC Payload ID的格式。例如，如果将sourceFecPayloadID属性设置为0，则Source FEC Payload ID不存在并且全部交付对象都包含在此分组中。FECParameters将不存在。如果将sourceFecPayloadID属性设置为1，则Source FEC Payload ID为32比特并且表示对象中的起始偏移。FECParameters将不存在。如果将sourceFecPayloadID属性设置为2，则FECParameters限定Source FEC Payload ID的格式。

下面详细描述sourceFecPayloadID为1的情况。

在这种情况下，Source FEC Payload ID可以指示发射交付对象的分组的有效载荷的第一字节的位置。Source FEC Payload ID可以指示在对象中当前发射的分组有效载荷的偏移(时间位置或空间位置)。

基于Source FEC Payload ID，广播接收设备可以识别交付对象和/或在对象中当前发射的分组的顺序。广播接收设备可以基于Source FEC Payload ID，依次对准接收的分组，并准确地还原、解析、和/或解码每个交付对象和/或对象。

FECParameters限定FEC参数。FEC参数包括FEC-encoding-id、instance-id等等。它具体用于发信号通知所采用的Source FEC Payload ID。

图7示出根据本发明实施例的交付对象的格式。

ROUTE协议实现全部交付对象的交付。当接收器恢复交付对象并将它们传递给应用时，交付对象是该协议的关键组件。交付对象对于应用而言是独立的，通常与对于应用而言相关的某特性、元数据以及时间相关信息相关联。在有些情况下，连同对象一起在带内提供这些特性，在其他情况下，数据需要按照静态或动态的方式在带外交付。

交付对象可包括通过“FDT实例”描述或伴随的全部或部分文件。此外，交付对象可包括HTTP实体(HTTP实体报头和HTTP实体主体)和/或交付对象的分组。

在交付对象是全部或部分文件的情况下，连同FDT实例一起，通过它是对应于整个文件还是文件的字节范围，可以进一步区分交付对象。此外，通过它是对应于定时交付还是非定时交付，可以进一步区分交付对象。如果是定时的，那么某实时和缓冲限制适用，并且可以使用特定扩展报头。此外，通过使用动态和/或静态元数据来描述交付对象特性，可以进一步区分交付对象。此外，通过交付特定数据结构，特别是ISO BMFF结构，可以进一步区分交付对象。在这种情况下，可以应用媒体方面的分组化或一般的分组化。

DeliveryObjectFormatID指定为了向应用提供信息，使用哪种格式。交付对象格式包括文件模式、实体模式、分组模式的至少其中一个。

在文件模式中，交付对象表示文件或文件的字节范围。

在实体模式中，交付对象表示在RFC 2616中限定的实体。实体包括实体报头字段和实体主体。该模式重新使用如RFC 6968中限定的FCAST的主要概念，但是允许交付任何类型的HTTP实体报头(包括扩展报头等等)。连同文件一起发送的实体报头字段提供用于所包含的全部或部分文件的所有信息。注意，如果报头包含内容范围实体报头，则交付对象只包含所交付文件的字节范围。此外，在实体报头包含信令的情况下，该模式还允许成块交付。

在分组模式中，交付对象包括仅为了交付而分组的文件的群组。如果应用，那么该分组仅用于交付的目的，并且客户端会将分组解封，将每个文件作为独立文件提供给应用。通过Multipart MIME支持分组，其中将对象分组在一个文档中用于传输。分组文件将使用具有为多部件设置的内容类型的文件模式来交付。如果在分组模式中交付文件，那么ROUTE接收器必须将数据解封，而如果在规则的文件模式中交付格式，那么将分组传给应用。

图8示出根据本发明实施例在文件模式中的ROUTE分配与FLUTE分配之间的比较。

图8(a)示出使用FLUTE的广播发射设备(例如，FLUTE发送器C81550-1)和/或广播接收设备(例如，FLUTE接收器C82550-1)。

FLUTE发送器C81550-1可以发射包括至少一个对象和/或信令信息的至少一个LCT分组。信令信息可包括FDT实例。LCT分组可包括报头(LCT报头)和/或有效载荷(LCT有效载荷)。

在FLUTE中，如果在发送器实时产生对象，则FDT实例在带内交付并需要实时产生和交付。

文件交付表(FDT)提供描述与在文件交付会话中要交付的文件相关联的各种属性的手段。FDT是文件描述条目的集合，用于在会话中要交付的文件。每个文件描述条目都必须包括用于它所描述的文件的TOI以及识别文件的URI。

在能够恢复文件(或对象)本身之前，FDT实例描述文件(或对象)。在文件交付会话中，交付FDT作为FDT实例。FDT实例包含FDT的一个或多个文件描述条目。任何FDT实例都可以等同于任何其他FDT实例，任何FDT实例都可以是任何其他FDT实例的子集，任何FDT实例都可以是任何其他FDT实例的超集，任何FDT实例都可以与任何其他FDT实例重叠，任何FDT实例都可以补充任何其他FDT实例。在会话期间，某个FDT实例可以重复多次，即使在发射后来的FDT实例(具有更高的FDT实例ID号)之后。每个FDT实例至少包含单个文件描述条目，至多包含在文件交付会话中交付的文件的文件描述条目的完备集合。

FLUTE接收器C82550-1可以接收包括至少一个对象和/或信令信息的至少一个LCT分组。基于信令信息，FLUTE接收器C82550-1可以还原和/或再现至少一个对象(或文件)。

FLUTE协议可以不实时发射和/或接收至少一个对象。

图8(b)示出使用ROUTE的广播发射设备和/或广播接收设备。

广播发射设备可以发射包括至少一个交付对象和/或信令信息的至少一个LCT分组。信令信息可包括EFDT实例描述。LCT分组可包括报头(LCT报头)和/或有效载荷(LCT有效载荷)。

广播发射设备的控制器可包括信令信息产生器(EFDT产生器)C81540和/或ROUTE发送器C81550的至少其中一个。信令信息产生器C81540可被包括在ROUTE发送器C81550中并独立于ROUTE发送器C81550存在。

信令信息产生器C81540可产生包括关于广播服务的发现和描述的信息的信令信息。信令信息产生器C81540可包括EFDT产生器。

信令信息产生器C81540可产生EFDT实例描述。EFDT实例描述是包括能够产生FDT实例描述的数据的扩展FDT实例描述符。

ROUTE发送器C81550可产生至少一个交付对象。

广播接收设备可以接收包括至少一个交付对象和/或信令信息的至少一个LCT分组。基于至少一个LCT分组，广播接收设备可以还原和/或再现至少一个交付对象和/或信令信息。基于信令信息，广播接收设备可以还原和/或再现至少一个交付对象。

广播接收设备的控制器可包括ROUTE接收器C82550。ROUTE接收器C82550可以接收包括至少一个交付对象和/或信令信息的至少一个分组。基于至少一个分组，ROUTE接收器C82550可以还原至少一个交付对象和/或信令信息。基于信令信息，ROUTE接收器C82550可以还原至少一个交付对象。信令信息可包括EFDT实例描述。

例如，ROUTE接收器C82550可包括FDT实例产生器C82553和/或FLUTE接收器C82555。基于EFDT实例描述和/或LCT报头，FDT实例产生器C82553可以产生至少一个FDT实例。基于至少一个LCT报头和/或至少一个FDT实例，FLUTE接收器C82555可以还原至少一个交付对象。

在文件模式中，交付对象表示文件或文件的字节范围。该模式复制RFC 6726中限定的FLUTE，但是具有按照附图所示的静态方式发送元数据的能力。

与RFC 6726以及TS26.346中的FDT相比，在ROUTE中，通过一些功能性来扩展FDT，包括提供规则，以基于使用扩展FDT以及LCT报头中的信息，在运行中(on-the-fly)产生文件元素的能力。

连同LCT分组报头一起，可将扩展FDT用于产生FDT等效描述(用于交付对象)。这样避免了对于实时对象连续发送FDT的必要性。

附图不强制任何实施方式，只提供参考模型。

可将以下方法(非穷尽)用于交付扩展FDT(注意：ATSC可以选择这些选项的子集)。

可将扩展FDT交付作为在LSID的SourceFlow元素中嵌入的元素。

此外，可将扩展FDT交付作为通过LSID参照的单独交付对象，并且继而a)在其组成LCT会话携带通过该EFDT描述的交付对象的相同ROUTE会话中；和/或b)在与携带通过该EFDT描述的交付对象的ROUTE会话和组成LCT会话分离的ROUTE会话或者IP多播流中；和/或c)宽带网络上携带。

此外，可在带内交付扩展FDT，不需要参考符合FDT。

根据本发明实施例的ROUTE协议可通过划分对象来产生交付对象。结果，ROUTE协议可以实时发射和/或接收至少一个交付对象。

图9示出根据本发明实施例的EFDT。

EFDT是扩展FDT实例描述符(注意，也包括全部FDT参数)。EFDT包括route:idRef属性、route:version属性、route:maxExpiresDelta属性、route:maxTransportSize属性、和/或route:FileTemplate元素的至少其中一个。

route:idRef属性指示EFDT的身份。

route:version属性指示该扩展FDT实例描述符的版本。当描述符更新时将版本加一。所接收的有最高版本号的EFDT是当前有效版本。

route:maxExpiresDelta属性指示在发送与该对象相关联的第一分组之后，用于传输会话中的对象的最大期满时间。

route:maxTransportSize属性指示通过该EFDT描述的任何对象的最大传输大小。如果在FEC_OTI中没有呈现，则要呈现。

route:FileTemplate元素指定文件URL或者主体中的文件模板。

如果FileTemplate元素不存在，那么EFDT将符合根据TS 26.346的FDT实例。这意味着必须呈现至少一个文件元素；并且必须呈现@expires属性。

如果呈现FileTemplate元素，那么发送器将包括以下信息。TOI将被设置为使得能够导出Content-Location。在发送TOI的第一分组之后，不应有属于该TOI的分组迟于@maxExpiresDelta所指示的被发送。此外，如果认为有用，那么为了表达更准确的期满时间，可以使用具有期望剩余时间(ERT)的EXT_TIME报头。如果@maxExpiresDelta不呈现，那么应当使用具有期望剩余时间(ERT)的EXT_TIME报头来发信号通知@Expires的值。

如果FileTemplate元素呈现，则通过下文限定的处理产生FDT实例。在产生FDT实例时可以照原样使用EFDT中包含的任何数据。在接收具有特定TOI值的LCT分组的情况下，将FileTemplate元素中的数据用于产生FDT实例。

如果接收具有新TOI的LCT分组用于该传输会话，则通过如下的新文件条目产生FDT实例。将TOI用于产生File@Content-Location。将EFDT元素中呈现的所有其他参数都关联到文件属性。可将EXT_FTI或者EXT_TOL报头用于提取任何相关的FEC传输信息，并将其映射到文件参数。注意，在ROUTE中，该报头不需要被呈现，因为可以从最后的分组(用B标记指示)中导出TOL，并且TOL提供起始偏移与分组持续时间的总和。如果呈现，则应当将@maxExpiresDelta用于产生@Expires属性的值。接收器应当将该值添加到接收器的当前时间，以获得@Expires的值。如果不呈现，则应当将具有期望剩余时间(ERT)的EXT_TIME报头用于提取FDT实例的期满时间。如果两者都呈现，则将两个值中的较小值用作@Expires的值。

图10示出根据本发明实施例用于文件模板的标识符。

如果FileTemplate元素呈现，则FileTemplate元素的值可包含附图中所列出的标识符。

如果没有FileTemplate元素呈现，则FileTemplate应当是有效URL，并且在该传输会话中，将URL关联到具有传输对象标识符(TOI)号的对象。

如果$TOI$呈现，则将该元素用于产生TOI与URL之间的一一映射。

在每个URL中，可以用附图中限定的替代参数来代替来自附图的标识符。标识符匹配区分大小写。如果URL包含非转义的$符号，其不封入有效标识符，则URL形成的结果未限定。附图中还指定标识符的格式。

在该原型后面的包围“$”字符中，每个标识符可以加后缀。

“％0[width]d”

宽度参数是无符号整数，提供要打印的字符的最小数量。如果要打印的值短于此数量，则要用零填充该结果。即使结果较大，也不将值截断。

FileTemplate应当被编写为使得替代处理的应用能够导致有效的URL。

标识符外面的字符串应当只包含根据RFC 3986在URL中允许的字符。

图11示出根据本发明实施例的ROUTE分组格式。

附图中示出全部的ROUTE分组格式。分组是IP分组，或者是IPv4，或者是IPv6，并且IP报头在UDP报头前面。ROUTE分组格式对于IP版本号没有依赖关系。

ROUTE使用的分组格式遵循ALC分组格式，即，UDP报头后面是LCT报头，Source FECPayload ID后面是分组有效载荷。在RFC 5651中的LCT构建块中限定LCT报头。ROUTE中的Source FEC Payload ID通常是start_offset，或者直接提供，或者由任何FEC方案提供。

ROUTE分组可包括UDP报头、LCT报头、ROUTE(ALC)报头、和/或有效载荷数据的至少其中一个。

UDP是传输层的通信协议，当利用IP在网络中的计算机之间交换消息时，传输层只提供有限服务。UDP报头可包括源端口字段、目的地端口字段、长度字段、和/或校验和字段的至少其中一个。源端口字段可指示发射侧的端口。目的地端口字段可指示接收侧的端口。长度字段可指示整个分组的长度。校验和字段可包括用于错误检测的信息。

ALC对应于这样的协议，该协议被标准化为使得在单个发射器向若干接收器发射文件时可通过若干信道来控制可靠性和复杂性。ALC对应于用于错误控制的FEC构建块、用于复杂性控制的WEBRC构建块、和/或用于会话和信道管理的LCT构建块的组合，并且如果必要的话，可以基于服务来配置构建块。根据本发明实施例的ROUTE报头可包括ALC报头。

LCT支持用于流发射协议的发射等级和可靠的内容发射。LCT提供关于要交付给接收器的基本信息的内容和特征的信息。LCT分组报头字段应当像RFC 5651中的LCT构建块限定的那样来使用。LCT报头可包括LCT版本号字段(V)、拥塞控制标记字段(C)、保留字段(R)、传输会话标识符标记字段(S)、传输对象标识符标记字段(O)、半字标记字段(H)、发送器当前时间呈现标记字段(T)、期望剩余时间呈现标记字段(R)、关闭会话标记字段(A)、关闭对象标记字段(B)、LCT报头长度字段(HDR_LEN)、码点字段(CP)、拥塞控制信息字段(CCI)、传输会话标识符字段(TSI)、传输对象标识符字段(TOI)、报头扩展字段、和/或FEC有效载荷ID字段的至少其中一个。

LCT版本号字段(V)指示协议版本号。例如，该字段指示LCT版本号。LCT报头的版本号字段必须解释为ROUTE版本号字段。该ROUTE版本隐含地使用RFC 5651中限定的LCT构建块的版本1。例如，版本号为“0001b”。

拥塞控制标记字段(C)指示拥塞控制信息字段的长度。

保留字段(R)为将来的使用而保留。例如，保留字段(R)可以是协议专用指示字段(PSI)。在LCT上层协议中，可将协议专用指示字段(PSI)用作特定目的的指示符。PSI字段指示当前分组是源分组还是FEC修复分组。当ROUTE源协议只交付源分组时，应当将该字段设置为“10b”。

传输会话标识符标记字段(S)指示传输会话标识符字段的长度。

传输对象标识符标记字段(O)指示传输对象标识符的长度。例如，TOI可以对应于交付对象的身份信息。

半字标记字段(H)指示是否将半字(16比特)添加到TSI和TOI的长度。

发送器当前时间呈现标记字段(T)指示发送器当前时间(SCT)字段是否呈现。T＝0指示发送器当前时间(SCT)字段不呈现。T＝1指示SCT字段呈现。通过发送器来插入SCT，向接收器指示会话进行了多久。

期望剩余时间呈现标记字段(R)指示期望剩余时间(ERT)字段是否呈现。R＝0指示期望剩余时间(ERT)字段不呈现。R＝1指示ERT字段呈现。通过发送器来插入ERT，向接收器指示会话/对象发射还将要继续多久。

关闭会话标记字段(A)指示会话已经结束或者即将结束。

关闭对象标记字段(B)指示正在发射的交付对象已经结束或者即将结束。

LCT报头长度字段(HDR_LEN)指示LCT报头以32比特字为的单位的总长度。

码点字段(CP)指示通过该分组携带的有效载荷的类型。根据有效载荷的类型，可以添加附加有效载荷报头，为有效载荷数据加前缀。

拥塞控制信息字段(CCI)用于发射拥塞控制信息，例如层数量、逻辑信道数量、序列数量等等。LCT报头中的拥塞控制信息字段包含要求的拥塞控制信息。

传输会话标识符字段(TSI)是会话的唯一标识符。在来自特定发送器的所有会话中，TSI唯一地识别会话。该字段识别ROUTE中的传输会话。传输会话的背景由LSID(LCT会话实例描述)提供。

传输对象标识符字段(TOI)是对象和/或交付对象的唯一标识符。TOI指示该分组属于会话中的哪个对象。该字段指示当前分组的有效载荷属于该会话中的哪个对象。TOI字段到对象的映射由扩展FDT提供。扩展FDT指定文件交付数据的细节。这是扩展FDT实例。如果在会话中携带一个以上对象，则LCT报头中的发射对象ID(TOI)必须用于识别从哪个对象产生分组有效载荷数据。

报头扩展字段被用作LCT报头扩展部分，用于附加信息的发射。在LCT中使用报头扩展以容纳并非总是使用或者具有可变大小的选择性报头字段。例如，EXT_TIME扩展用于携带若干类型的定时信息。它包括通用定时信息(SCT)、期望剩余时间(ERT)、以及本文献所述的发送器最后改变(SLC)时间扩展。它也可以用于具有更窄应用性(例如，为单个协议示例限定)的定时信息；在这种情况下，在单独的文献中描述它。

FEC有效载荷ID字段可包括发射时钟或编码符号的身份信息。FEC有效载荷ID可以指示与将文件FEC编码的情况相对应的标识符。

有效载荷数据可包括至少一个发射时钟和/或编码符号的数据。分组有效载荷包含由对象产生的字节。如果在会话中携带一个以上对象，则LCT报头中的发射对象ID(TOI)必须用于识别从哪个对象产生分组有效载荷数据。

ROUTE源协议基于RFC 5775中限定的ALC，细节如下。

首先，在以下约束下使用RFC 5651中限定的分层编码传输(LCT)构建块。可将LCT报头中的拥塞控制信息(CCI)字段设置为0。LCT报头中的TSI应当根据LCT传输会话来设置；该分组的应用如LSID中限定的。LCT报头中的码点应当用于发信号通知所应用的格式，如LSID中限定的。PSI的第一位应当设置为1，以指示源分组。

根据ALC，使用source FEC Payload ID指定交付对象的八位字节中的开始地址。可以按照若干方式来发送该信息，包括简单的新FEC方案、现有FEC方案、和/或LSID的至少其中一个。

简单的新FEC方案实现将source FEC Payload ID设置为大小0的方案。在这种情况下，分组应当包含整个对象。此外，source FEC Payload ID可以指示使用32比特的直接地址(起始偏移)。

使用如RFC 5445中限定的紧凑No-Code，广泛部署现有FEC方案。此外，按照与RFC6330兼容的方式，广泛部署现有FEC方案，其中SBN和ESI连同符号大小T一起限定起始偏移。

使用@sourceFecPayloadID属性以及FECParameters元素，LSID提供适当的信令，以发信号通知上述模式的任何一个。

第二，可以按照以下方式通过发送器使用RFC 5651中限定的LCT报头EXT_TIME扩展。根据应用，发送器当前时间可用于偶尔或经常发信号将当前时间通知发送器。这样可以用于将发送器与接收器的时钟同步，或者测量抖动和交付延迟。可将期望剩余时间(ERT)用于指示当前对象的期望剩余时间。SLC标记通常没有作用，但是可用于指示片段的添加/消除。

第三，可将附加扩展报头用于支持实时交付。这种扩展报头被限定如下。

第四，通过LCT会话实例描述(LSID)来传达LCT会话描述信息。

第五，通过外部手段来传达ROUTE会话描述。

ROUTE引入LCT构建块的使用的主要改变如下。ROUTE将LCT构建块的使用限制为每个会话单个信道。因此在ROUTE中拥塞控制是发送器驱动。接收器驱动的分层多播的功能性可以仍然由应用提供，允许接收器应用基于该会话的带宽要求选择适当的交付会话。

在一些特殊情况下，ROUTE发送器可能需要产生不包含任何有效载荷的ROUTE分组。例如这可以被要求以发信号通知会话的结束，或者表达拥塞控制信息。这些无数据分组不包含ROUTE报头或有效载荷数据，而只有LCT报头字段。由外部协议报头(例如，IP或UDP报头)表达的总数据报长度使得接收器能够检测ROUTE(ALC)报头和有效载荷的不存在。

图12示出根据本发明实施例的EXT_PRESENTATION_TIME报头。

为了协议在不同环境下的正确操作，将LCT扩展报头限定为为了不同目的支持ROUTE协议的操作。根据RFC 5651的第9节，报头需要注册到IANA。

LCT扩展报头可包括EXT_PRESENTATION_TIME报头和/或EXT_TIME报头的至少其中一个。

EXT_PRESENTATION_TIME报头表示分组中包含的对象按照壁钟时间应当呈现时的时间。可将EXT_PRESENTATION_TIME报头添加到LCT分组。要注册固定长度的报头。

如果呈现，那么它表示64比特时间戳的第三、第四和第五个八位字节。该值必须总是大于SCT(发送器当前时间)。或者，它表示64比特NTP(网络时间协议)时间戳值，如图所示。

附图示出根据本发明实施例的EXT_PRESENTATION_TIME报头。

EXT_PRESENTATION_TIME报头可包括Header Extension Type(报头扩展类型)(HET)字段、Header Extension Length(报头扩展长度)(HEL)字段、保留字段、和/或NTP时间戳的至少其中一个。

HET字段可以指示对应的报头扩展类型。HET字段可以是8比特整数。从0到127的HET值(待定，TBD)用于可变长度的报头扩展。从128到255的HET值用于固定长度的32比特报头扩展。

HET字段可以指示整个报头扩展字段的长度，用32比特字的倍数表示。HET字段可以是8比特整数。该字段必须呈现用于可变长度的扩展(0与127之间的HET)，并且不能呈现用于固定长度的扩展(128与255之间的HET)。

NTP时间戳可以表示分组中包含的对象按照壁钟时间应当呈现时的时间。NTP时间戳是64比特二进制值，在两个32比特半数之间具有隐含分数点。NTP时间戳可包括跨越136年的32比特秒字段(最高有效字)以及分辨率232皮秒的32比特分数字段(最低有效字)。

此外，可以使用如RFC 5651中限定的EXT_TIME报头，并且可以设置SCT-high和SCT-low标记。EXT_TIME报头用于携带若干类型的定时信息。它包括HET字段、HEL字段、使用字段、和/或至少一个通用定时信息。

使用字段指示以下(一个或多个)32比特时间值的语义。使用字段可包括SCT-high标记、SCT-low标记、ERT标记、和/或SLC标记。在给定的EXT_TIME报头扩展中可以呈现若干“时间值”字段，如使用字段中指定的。

通用定时信息可包括发送器当前时间(SCT)、期望剩余时间(ERT)、和/或发送器最后改变(SLC)时间扩展的至少其中一个。

SCT表示发射该分组时发送器的当前时间。根据应用，SCT可用于偶尔或经常发信号将当前时间通知发送器。这样可以用于将发送器与接收器的时钟同步，或者测量抖动和交付延迟。

ERT表示发送器期望的剩余发射时间，用于当前对象的发射。ERT可用于指示当前对象的期望剩余时间。

SLC时间是服务器壁钟时间，以秒为单位，此时出现对会话数据的最后改变。SLC标记通常没有作用，但是可用于指示片段的添加/消除。

图13示出根据本发明实施例的广播发射设备的操作。

广播发射设备可以利用编码器&DASH器将广播服务编码。例如，广播服务可包括信令数据、ESG数据、NRT内容数据、和/或实时内容数据的至少其中一个。NRT内容数据、和/或实时内容数据可包括媒体数据。媒体数据可包括视频数据、音频数据、和/或隐藏字幕数据中的至少其中一个。

可将编码的广播服务封装在MPEG-DASH的至少一个片段中。MPEG-DASH的片段的文件格式可以是ISO BMFF。例如，可将视频数据、音频数据、和/或隐藏字幕数据封装在MPEG-DASH的至少一个片段中。

利用ROUTE发送器和/或交付对象产生器，广播发射设备可以产生至少一个交付对象，交付对象包括在服务的至少一个内容组件中并个别地恢复(CS13100)。

交付对象可以是文件、文件的一部分、文件的群组、HTTP实体、以及HTTP实体的群组的其中一个。

交付对象可包括基于对象的媒体数据。例如，交付对象可包括MPEG-DASH媒体片段文件和/或MPEG-DASH媒体片段文件的一部分。

交付对象可包括与片段有关的数据。

在基本操作中，假定交付对象在ROUTE发送器完全可用。此外，假定T>0是以字节为单位的对象的传送长度。已知第一数据分组的最大传送单元为Y。传送单元通过底层的传输块大小的知识来确定，或者通过其他约束来确定。

在Y大于等于T的情况下，这是用于该交付对象的唯一分组。因此，可以设置Codepoint字段(CP)，指示分组报头大小为0。然后携带整个交付对象，作为分组的有效载荷。

如果Y小于T，则分组的有效载荷中携带的数据包括对象的连续部分。然后，对于任何任意的X以及任何任意的Y>0，只要X+Y不超过T，就可以产生ROUTE分组。在这种情况下，以下应当成立：分组的有效载荷中携带的数据将包括对象从字节X的起点开始到字节X+Y的起点的连续部分。此外，应当将ROUTE分组报头中的起始偏移设置为X，并将有效载荷数据添加到分组中发送。如果X+Y等于T，则应当将有效载荷报头标记B(即，关闭对象标记字段(B))设置为“1”，否则应当将有效载荷报头标记B设置为“0”。

利用信令信息产生器，广播发射识别可以产生信令信息，信令信息提供服务以及至少一个内容组件的发现和获取(CS13200)。

信令信息可包括描述传输会话的第一信息，传输会话用于发射服务的至少一个内容组件。例如，第一信息可包括服务层信令(SLS)、LCT会话实例描述(LSID)、和/或基于服务的传输会话实例描述(S-TSID)。

信令信息可包括ROUTE会话描述、LCT传输会话描述(或LCT会话描述)、和/或交付对象元数据(或对象元数据)。ROUTE会话描述可包括与ROUTE会话有关的信令信息。LCT传输会话描述可包括与LCT传输会话有关的信令信息。交付对象元数据可包括与交付对象有关的信令信息。

信令信息(例如，服务信令)可提供服务和描述对象的发现。信令信息可包括引导信令信息(快速信息表(FIT))和/或服务层信令信息(服务层信令(SLS))。信令信息可包括发现或获取至少一个用户服务所必须的信息。

FIT使得接收器能够构建基本服务列表以及用于每个服务的服务层信令的引导发现。在实施例中，可通过服务列表表格(SLT)来表示FIT。可通过链路层信令来发射FIT(或SLT)。或者，为了快速获取，可以在每个物理层帧中发射FIT(或SLT)。在实施例中，可通过物理层帧、用于信号发射的PLP、和/或分配给每个广播者的PLP的至少其中一个来发射FIT(或SLT)。

SLS使得接收器能够发现和访问至少一个服务和/或至少一个内容组件。在通过广播发射SLS时，通过ROUTE/UDP/IP，可以在ROUTE会话中包括的至少一个LCT传输会话中发射SLS。在这种情况下，可以在支持快速信道加入和切换的适当传送带速度下发射SLS。在通过宽带发射SLS时，可通过HTTP(S)/TCP/IP发射SLS。

LSID可以描述通过ROUTE会话发射的所有传输会话。可通过与包括LCT传输会话的ROUTE会话相同的ROUTE会话发射LSID，或者通过除了ROUTE会话之外的其他手段发射LSID。例如，可通过单播或另一个ROUTE会话发射LSID。

S-TSID是包括至少一个ROUTE会话、至少一个ROUTE中包括的LCT会话、和/或用于至少一个MMTP会话的全部传输会话描述信息的SLS元数据分段。可通过ROUTE会话和/或MMTP会话发射服务中包括的至少一个媒体内容组件。此外，S-TSID可包括在服务中包括的至少一个LCT会话、用于对象流的文件元数据、和/或描述中发射的交付对象。此外，S-TSID可包括有效载荷格式和/或用于在至少一个LCT会话中发射的至少一个内容组件的附加信息。

第一信息可包括描述通过发射会话发射的源数据的第二信息。例如，第二信息可包括SourceFlow元素。SourceFlow元素可以限定会话中的源流。

第二信息可包括EFDT元素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier元素、和/或PayloadFormat元素的至少其中一个，EFDT元素指定文件交付数据的细节，idRef属性识别EFDT元素，realtime属性指示是否实时发射交付对象，minBufferSize属性限定必须存储在接收器中的数据的最大量，ApplicationIdentifier元素提供能够映射到应用的信息，PayloadFormat元素限定发射交付对象的分组的有效载荷格式。

PayloadFormat元素可包括codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFecPayloadID属性、和/或FECParamenters元素的至少其中一个，codePoint属性限定用于有效载荷的codePoint值，deliveryObjectFormat属性指定交付对象的有效载荷格式，fragmentation属性指示交付对象的单元，deliveryOrder属性指示包括交付对象的数据的分组的发射顺序，sourceFecPayloadID属性限定源FEC有效载荷ID的格式，FECParamenters元素限定FEC参数。

EFDT元素可包括idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、和/或FileTemplate元素的至少其中一个，idRef属性识别EFDT元素，version属性指示EFDT元素的版本，maxExpiresDelta属性指示在发射会话中用于对象的最大期满时间，maxTransportSize属性指示通过EFDT元素描述的对象的最大发射大小，FileTemplate元素指定文件的URL。

利用发射器，广播发射设备可通过单向信道发射至少一个交付对象和信令信息(CS13300)。

例如，广播发射设备可利用LCT分组发射至少一个交付对象和信令信息。

分组交付的顺序任意，但是在没有其他约束的情况下，推荐具有增加的起始偏移号码的交付。某些应用可以要求具有增加的起始偏移号码的严格发送顺序。

在其他情况下，在发送较早的数据块之前，传送长度可能是未知的，并且只知道最大传送长度，如在EFDT参数@route:maxTransportSize中发信号通知的。在这种情况下，可以在以后确定T。但是，这不会影响以上发送处理。可以按照以上规则发送附加分组。在这种情况下，对于包含对象的最后部分的有效载荷，可以只将B标记设置为“1”。

因此，广播发射设备可实时通过广播网络发射基于对象的媒体数据。

图14示出根据本发明实施例的广播接收设备。

广播接收设备的控制器C14250可包括ROUTE接收器C142530和/或DASH客户端(应用/DASH播放器)C142550的至少其中一个。

ROUTE接收器C142530可接收广播服务，并还原信令信息和/或至少一个交付对象。ROUTE接收器C142530可基于包括广播服务的分组还原信令信息和/或至少一个交付对象。ROUTE接收器C142530可包括分组接收器(未示出)、信令解析器(LSID)C142532、交付对象处理器(对象恢复或交付对象恢复块)C142533、和/或交付对象缓存(交付对象处理)C142537的至少其中一个。

分组接收器可接收至少一个包括广播服务的分组。例如，分组可包括LCT分组。

信令解析器C142532可提取信令信息，信令信息提供服务的至少一个内容组件的发现和获取。

信令信息可包括描述发射会话的第一信息，发射会话用于发射服务的至少一个内容组件。例如，第一信息可包括SLS、LSID、和/或S-TSID。第一信息可包括描述通过发射会话发射的源数据的第二信息。例如，第二信息可包括SourceFlow元素。SourceFlow元素可以限定会话中的源流。

交付对象处理器C142533可基于信令信息还原至少一个交付对象。利用交付对象恢复块，交付对象处理器C142533可基于包括广播服务的至少一个分组还原至少一个交付对象和/或信令信息。

附图提供基本接收器操作的概述。接收器接收分组并因此过滤这些分组。根据ROUTE会话以及每个包含的LCT传输会话，它重新产生被传递给适当处理者的交付对象，以进一步处理数据。

下面提供基本接收器信息。此外，在本节的剩余部分中提供对于不同接收对象的处理。

LCT会话实例描述(LSID)包含描述所携带的对象流的信息。在接收每个有效载荷时，接收器按照所列顺序进行以下步骤。

首先，ROUTE接收器解析LCT和ROUTE(ALC)报头，并确认它是有效报头。如果它无效，则应当丢弃该有效载荷，不做进一步处理。

第二，ROUTE接收器宣称TSI和CodePoint在LSID中提供有效操作点，即，LSID包含用于分组报头中提供的TSI值的条目以及用于该TSI的条目，该TSI包含将PayloadFormat@codePoint设置为LCT报头中CodePoint字段的值的条目。

第三，ROUTE接收器应当处理有效载荷的剩余部分，包括适当地解释其他有效载荷报头字段，并利用源FEC有效载荷ID(以导出起始偏移)和有效载荷数据重构对应的对象如下：

a.ROUTE接收器可经由LSID以及LCT报头中携带的TOI确定与所接收的ROUTE分组有效载荷相关联的对象。

b.在接收用于对象的第一ROUTE有效载荷时，ROUTE接收器利用EFDT的maxTransportSize属性确定对象的最大长度T'。

c.ROUTE接收器为对象可能占据的T'字节分配缓冲器空间。

d.此外ROUTE接收器通过从所接收的有效载荷的总长度减去有效载荷报头长度，计算有效载荷的长度Y。

e.ROUTE接收器向布尔阵列RECEIVED[0..T'-1]分配被初始化为假的所有T条目，以跟踪所接收的对象符号。ROUTE接收器保持接收用于对象块的有效载荷，只要RECEIVED中有至少一个条目仍然被设置为假或者直到对象期满或者直到应用决定放弃该对象。下面提供更多细节。

f.对于用于对象的每个接收的ROUTE有效载荷(包括第一有效载荷)，要用来帮助恢复对象的步骤如下：i)令X为ROUTE分组报头中start_offset字段的值，并且令Y为有效载荷的长度(通过从所接收的分组的总长度减去LCT报头大小和ROUTE(ALC)报头大小所计算的Y)。ii)ROUTE接收器将数据复制到为对象保留的空间中的适当位置，并将RECEIVED[X...X+Y-1]设置为真。iii)如果RECEIVED的所有T条目都为真，则接收器恢复了整个对象。

g.一旦ROUTE接收器收到将B标记设置为1的ROUTE分组，它就可将对象的传送长度T确定为对应ROUTE有效载荷的X+Y，并将布尔阵列RECEIVED[0..T'-1]调节为RECEIVED[0..T-1]。

一旦恢复了完整的TOI，就恢复了用于交付对象的元数据，并且对象被传给应用。

元数据恢复取决于所采用的交付模式。

如果接收了交付对象，那么相应地应用可以利用接收的交付对象。通常，如果交付对象是完整和完好的，那么只将交付对象传给应用。

但是在某些情况下，如果应用API允许这样并且如果有充足的元数据可用于实现该处理，那么可以移交部分接收的对象。在3GPP TR26.946中描述了用于这样的一个限定机制。如果在文件模式中接收对象，则将扩展FDT用于恢复所有元数据。如果在实体模式中接收对象，则根据RFC2616来处理实体报头和实体主体。如果在分组模式中接收对象，则接收器应当在将它们传给应用之前将文件解分组，并提供分组中包括的元数据。

交付对象缓存C142537可以存储信令信息和/或至少一个交付对象，并将信令信息和/或至少一个交付对象交付给DASH客户端C142550。交付对象缓存C142537可基于定时信息将信令信息和/或至少一个交付对象交付给DASH客户端C142550。

DASH客户端C142550可将广播服务解码。DASH客户端C142550可以利用应用将至少一个交付对象解码。应用可以消耗至少一个交付对象。例如，应用可包括DASH媒体呈现。

图15示出根据本发明实施例的广播接收设备的操作。

广播接收设备可以利用广播网络(例如广播)和/或互联网协议网络(例如宽带互联网)的至少其中一个来接收广播服务，并将广播服务解码。广播接收设备可包括广播接口、宽带接口、和/或控制器的至少其中一个。广播接收设备的控制器可包括ROUTE接收器和/或DASH客户端的至少其中一个。ROUTE接收器可包括分组接收器、信令解析器、交付对象处理器、和/或交付对象缓存的至少其中一个。上面描述了广播接收设备的细节。

广播接收设备可以利用广播接口和/或宽带接口的至少其中一个来接收包括广播服务的广播信号。例如，广播接收设备可通过单向信道接收包括服务的广播信号(CS15100)。

广播接收设备可以利用控制器提取信令信息，信令信息提供服务的至少一个内容组件的发现和获取(CS15200)。

信令信息可包括描述发射会话的第一信息，发射会话用于发射服务的至少一个内容组件。例如，第一信息可包括SLS、LSID、和/或S-TSID。或者，信令信息可包括ROUTE会话描述、LCT传输会话描述(或LCT会话描述)、和/或交付对象元数据(或对象元数据)。

第一信息可包括描述通过发射会话发射的源数据的第二信息。例如，第二信息可包括SourceFlow元素。SourceFlow元素可以限定会话中的源流。

第二信息可包括EFDT元素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier元素、和/或PayloadFormat元素的至少其中一个，EFDT元素指定文件交付数据的细节，idRef属性识别EFDT元素，realtime属性指示是否实时发射交付对象，minBufferSize属性限定必须存储在接收器中的数据的最大量，ApplicationIdentifier元素提供能够映射到应用的信息，PayloadFormat元素限定发射交付对象的分组的有效载荷格式。

PayloadFormat元素可包括codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFecPayloadID属性、和/或FECParamenters元素的至少其中一个，codePoint属性限定用于有效载荷的codePoint值，deliveryObjectFormat属性指定交付对象的有效载荷格式，fragmentation属性指示交付对象的单元，deliveryOrder属性指示包括交付对象的数据的分组的发射顺序，sourceFecPayloadID属性限定源FEC有效载荷ID的格式，FECParamenters元素限定FEC参数。

EFDT元素可包括idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、和/或FileTemplate元素的至少其中一个，idRef属性识别EFDT元素，version属性指示EFDT元素的版本，maxExpiresDelta属性指示在发射会话中用于对象的最大期满时间，maxTransportSize属性指示通过EFDT元素描述的对象的最大发射大小，FileTemplate元素指定文件的URL。

利用控制器，广播接收设备可基于信令信息还原至少一个交付对象(CS15300)。

利用控制器，广播接收设备可将广播服务和/或至少一个交付对象解码。

图16示出根据本发明实施例的广播接收设备的FEC分组产生。

通过FEC可以保护通过以上协议交付的交付对象和交付对象的捆绑。基本协议避免了包括任何FEC专用信令。

FEC框架被限定为在使用源协议时实现交付对象的个体或捆绑的FEC保护。FEC框架使用RFC 6363中限定的FECFRAME工作以及现有FLUTE/ALC/LCT规范中采用的FEC构建块(RFC 5052)的概念。

FEC设计遵守以下原理。FEC相关信息仅在需要时提供。不符合该框架的接收器可以忽略修复分组。FEC是基于符号的，按照每个被保护的修复流具有固定的符号大小。ALC协议和现有FEC方案被重新使用。FEC修复流提供来自一个或多个源流的交付对象的保护。FEC框架的FEC专用组件是FEC修复流公告、FEC传输对象、FEC超级对象、FEC协议、和/或分组结构。FEC修复流公告包括所有FEC专用信息。为了形成符号对准的数据块，FEC传输对象是交付对象、填充八位字节、以及大小信息的级联。为了将FEC传输对象捆绑用于FEC保护，FEC超级对象是一个或多个FEC传输对象的级联。

接收器需要能够基于可用的FEC信息从修复分组恢复交付对象。

FEC协议指定用于FEC框架的协议元素。协议的5个组件被限定和描述。这些组件是1)FEC传输对象构造，2)FEC超级对象构造，作为FEC传输对象的级联，3)TOI映射，和/或4)修复分组产生。

FEC框架的操作由修复流定义约束。

附图市场基于两个交付对象的FEC分组产生。

FEC传输对象构造

为了在修复协议的背景下识别交付对象，需要以下信息。信息是交付对象的TSI和TOI。此外，信息是交付对象的八位字节范围，即，交付对象中的起始偏移以及构成FEC对象的交付对象的随后的连续八位字节的数量(即，源对象的FEC保护部分)。

通常，应用第一映射，即，交付对象是FEC对象。

对于每个交付对象，关联的FEC传输对象包括交付对象、填充八位字节(P)以及八位字节中FEC对象大小(F)的级联，其中在4-八位字节字段中携带F。在符号中，FEC传输对象大小S应当是符号大小T的整数倍。

S由会话信息和/或修复分组报头确定。在FEC传输对象的最后4个八位字节中携带F。

具体而言，令F为交付对象的大小，以八位字节为单位。令F为交付对象的数据的F个八位字节。令f表示按照网络八位字节顺序(首先是高阶八位字节)携带F的值的数据的4个八位字节。令S为FEC传输对象的大小，S＝ceil((F+4)/T。令P为S*T-4-F零八位字节数据，即，在FEC传输对象的结尾，在交付对象与F的值之间放置的填充。令O为F、P和f的级联。然后O构成大小为S*T八位字节的FEC传输对象。注意，填充八位字节和对象大小F不是在交付对象的源分组中发送，而仅仅是为了提取FEC对象并因此提取构成FEC对象的交付对象或交付对象的一部分，FEC解码所恢复的FEC传输对象的一部分。在以上背景下，FEC传输对象大小在符号中为S。

关于向FEC启用接收器表达的FEC传输对象的一般信息是源TSI、源TOI以及在包括关联FEC对象的交付对象中的关联的八位字节范围。但是，当在FEC传输对象中的附加字段中提供FEC对象的八位字节中的大小时，可将剩余信息表达为由其产生与FEC传输对象相关联的FEC对象的交付对象的TSI和TOI。此外，可将剩余信息表达为用于关联FEC对象的交付对象中的起始八位字节。此外，可将剩余信息表达为FEC传输对象的符号中的大小。

超级对象以及用于交付对象的FEC修复

根据FEC修复流公告，可以确定作为一个或多个FEC传输对象的级联的FEC超级对象的构造。FEC超级对象包括关于在前面的小节中描述的FEC传输对象以及FEC超级对象中的FEC传输对象的顺序的一般信息。令N为用于FEC超级对象构造的FEC传输对象的总数量。此外，对于i＝0，...，N-1，令S[i]为FEC传输对象i的符号中的大小。此外，令B为按照顺序的FEC传输对象的级联的FEC超级对象，其包括K＝sum(i＝0)(N-1)S[i]个源符号。

对于每个FEC超级对象，需要向FEC启用接收器表达的剩余一般信息(超出构成FEC超级对象的FEC传输对象中已经携带的信息)是FEC传输对象的总数量N。此外，对于每个FEC传输对象，需要向FEC启用接收器表达的剩余一般信息是由其产生与FEC传输对象相关联的FEC对象的交付对象的TSI和TOI、用于关联FEC对象的交付对象中的起始八位字节、FEC传输对象的符号中的大小。

下面描述信息的携带。

修复分组结构

修复协议基于RFC 5775中限定的异步分层编码(ALC)以及RFC 5651中限定的LCT分层编码传输(LCT)构建块，细节如下。

RFC 5651中限定的分层编码传输(LCT)构建块如同异步分层编码(ALC)中限定的那样使用。此外，以下约束适用。LCT报头中的TSI识别该分组所应用的修复流，如同@tsi属性所限定的。SPI的第一位应当设置为0，即，它指示修复分组。可以在LCT扩展报头中携带FEC配置信息。

根据RFC 5053和RFC 6330使用FEC构建块，但是只要交付修复分组。修复流范围中的每个修复分组(如LCT报头中的TSI字段所示)应当携带适当的修复TOI。对于在TSI范围内产生的每个FEC超级对象而言，修复TOI应当是唯一的。

摘要FEC信息

对于所产生的每个超级对象(通过修复流中的唯一TOI识别并通过LCT报头中的TSI关联到修复流)，需要将以下信息传达给接收器。例如，包括FEC编码ID、FEC OTI、和/或附加FEC信息的FEC配置。此外，在FEC超级对象中包括的FEC对象的总数量。此外，对于每个FEC传输对象，用于产生与FEC传输对象、关联FEC对象的交付对象中的起始八位字节(如果可用)、和/或FEC传输对象的符号中的大小相关联的FEC处对象的交付对象TSI和TOI。

该信息可以在修复流公告中静态地交付和/或在LCT扩展报头中动态地交付、和/或作为上述的组合等等。

图17示出根据本发明实施例的FEC传输对象。

附图示出FEC传输对象构造(示例为S＝3)。

图18示出根据本发明实施例的EXT_TOL报头。

EXT_FTI或者EXT_TOL报头应当用于提取任何相关的FEC传输信息。

附图示出EXT_TOL24和EXT_TOL56报头。它是实现传输对象长度的分配的扩展报头。传送长度的大小可以是24比特，也可以是56比特。

图19示出根据本发明实施例的RepairFlow元素。

在交付ATSC服务时，可将修复流公告包括为捆绑描述或者使用服务描述的分段。

作为修复流公告的一部分，修复流标识符被提供用于@tsi属性中的修复流，并且应当将所有修复流公告为RepairFlow类型。IP地址、端口和修复流标识符的组合在用户服务中的所有流中提供唯一标识符。注意，IP/端口组合可以携带不同的FEC修复数据以及源数据。在这种情况下，通过LCT报头中的不同TSI值来区分数据。

修复流公告指示来自要通过修复流保护的源流的交付对象的图案(或交付对象的八位字节范围)。

附图示出修复流的语义。

RepairFlow元素限定会话中的修复流。RepairFlow元素包括FECParameters元素。FECParameters元素限定FEC参数(更好的结构是适当必要的)。FECParameters元素包括fecEncodingId属性、maximumDelay属性、overhead属性、minBufferSize属性、FECOTI元素、和/或ProtectedObject元素的至少其中一个。

fecEncodingId属性指定所应用的FEC方案。

maximumDelay属性指定源流中的任何源分组与修复流之间的最大交付延迟。

overhead属性指定以百分比表示的开销。

minBufferSize属性指定要求的缓冲器大小。如果呈现，则该属性限定处理分配给超级对象的所有关联对象所需的最小缓冲器大小。

FECOTI元素指定RFC 5052中限定的FEC对象发射信息(FEC OTI)。FEC OTI对应于与对象相关联的FEC相关信息，此外，与对象的编码符号相关联的FEC信息要包括在该公告中并应用于具有修复流的所有修复分组。

ProtectedObject元素指定通过该修复流保护的源流以及怎样进行保护的细节。

图20示出根据本发明实施例的ProtectedObject元素。

ProtectedObject元素限定对象集合的某些交付对象怎样被包括在修复流中。ProtectedObject元素包括sessionDescription属性、tsi属性、sourceTOI属性、和/或fecTransportObjectSize属性的至少其中一个。

sessionDescription属性参考包含源流的会话描述。如果不呈现，则源流包含在与修复流相同的会话中。

tsi属性指定用于要保护的源流的传输会话标识符。

sourceTOI属性指定与修复流中包括的TOI相对应的交付对象的TOI。如果不呈现，则源TOI与修复TOI相同。

fecTransportObjectSize属性指定每个FEC传输对象的默认大小，以符号为单位。如果不呈现，则利用EXT_TOL报头在修复分组中提供这些值。如果呈现，则EXT_TOL报头不会呈现。

TOI映射

如果修复流公告包含ProtectedObject，则@sourceTOI属性指定修复流中包含的修复TOI值到修复流保护的交付对象的源TOI的映射。

映射通过采用C语言格式的等式来描述，由此将修复流的TOI字段指定为可变TOI，并且等式的结果确定源TOI。属性的值应当是具有至多一个可变TOI的正确C等式，并且不添加“；”符号。如果在ProtectedObject中不提供@sourceTOI属性，则应用默认等式sourceTOI＝"TOI"，以从修复TOI导出源TOI。

图21示出根据本发明实施例的RepairFlow公告。

在附图中，具有TSI值10和TOI 20的修复分组保护来自具有TSI 1的源流的具有TOI 20的交付对象。FEC传输对象大小被限定并且是892个符号。修复流公告被提供如下：

图22示出根据本发明实施例的RepairFlow公告。

在附图中，因为在ProtectedObject中不提供@sourceTOI属性，所以将默认等式sourceTOI＝"TOI"用于从TOI导出源TOI。因此，通过具有TSI 11和TOI 20的修复分组保护的超级对象是用于具有TSI 2和TOI 20的交付对象的FEC传输对象以及用于具有TSI 3和TOI 20的交付对象的FEC传输对象的级联。两种情况下FEC传输对象大小被限定并且FEC超级对象具有2232个符号的总大小。

所有三个流在相同的会话中交付。

图23示出根据本发明实施例的RepairFlow公告。

在附图中，通过具有TSI 12和TOI 20的修复分组保护的FEC超级对象是用于具有TSI 4和TOI 40的交付对象的FEC传输对象、用于具有TSI 5和TOI 20的交付对象的FEC传输对象、以及用于具有TSI 4和TOI 41的交付对象的FEC传输对象的级联。在该示例中，交付对象的FEC传输对象大小不包括在修复流公告中。

注意，RepairFlow公告中ProtectedObject公告的序列确定在超级对象中用于交付对象的FEC传输对象的顺序。

图24示出根据本发明实施例的RepairFlow公告。

在附图中，具有TSI 13和TOI 20的修复分组保护具有TSI 6和TOI 21的交付对象。

图25示出根据本发明实施例的RepairFlow公告。

在附图中，具有TSI 14和TOI 10的修复分组保护用于两个交付对象的FEC传输对象的级联：具有TSI 7和TOI 20的交付对象以及具有TSI 7和TOI 21的交付对象。以下具有TSI 14的修复流公告提供静态FDD。

FEC超级对象中FEC传输对象的顺序与在RepairFlow公告中进行ProtectedObject公告的顺序相同。因此在示例5中，与具有TSI 14和TOI 10的修复分组相对应的FEC超级对象是用于具有TSI 7和TOI 20的交付对象的FEC传输对象以及用于具有TSI 7和TOI 21的交付对象的FEC传输对象的级联。

图26示出根据本发明实施例的广播接收设备。

广播接收设备的控制器C26250可包括ROUTE接收器C262530和/或DASH客户端(应用/DASH播放器)C262550的至少其中一个。

ROUTE接收器C262530可接收广播服务，并还原信令信息和/或至少一个交付对象。ROUTE接收器C262530可基于包括广播服务的分组还原信令信息和/或至少一个交付对象。ROUTE接收器C262530可包括分组接收器(未示出)、信令解析器(LSID)C262532、交付对象处理器(交付对象恢复和FEC)C262535、和/或交付对象缓存(交付对象处理)C262537的至少其中一个。交付对象处理器C262535可包括对象恢复块和/或FEC解码器的至少其中一个。

分组接收器可接收至少一个包括广播服务的分组。例如，分组可包括LCT分组。

信令解析器C262532可提取信令信息，信令信息提供服务的至少一个内容组件的发现和获取。

信令信息可包括描述发射会话的第一信息，发射会话用于发射服务的至少一个内容组件。例如，第一信息可包括SLS、LSID、和/或S-TSID。第一信息可包括描述通过发射会话发射的源数据的第二信息。例如，第二信息可包括SourceFlow元素和/或RepairFlow元素。SourceFlow元素可以限定会话中的源流。RepairFlow元素可以限定会话中的修复流。

利用对象恢复块，交付对象处理器C262535可基于信令信息还原至少一个交付对象。基于广播服务中包括的至少一个分组，对象恢复块可以还原与源协议有关的至少一个交付对象和/或信令信息。

使用FEC解码器，基于包括广播服务的至少一个分组，交付对象处理器C262535可以还原与修复协议有关的至少一个交付对象和/或信令信息。例如，基于至少一个分组，FEC解码器可以还原与修复协议有关的至少一个交付对象和/或信令信息。

对于鲁棒接收，可以应用FEC。在这种情况下，连同源分组流一起发送一个或若干个修复流。修复流在RepairFlow描述中描述。

ROUTE环境中的相关方案是基于呼入LCT分组以及可包括修复分组流的LSID中提供的附加信息，恢复交付对象。有不同的选择。例如，根本不提供FEC，并且从源分组恢复分组。对于每个交付对象个别地提供FEC。对于很多交付对象提供一个FEC。对于交付对象的不同集合提供多个FEC流。

此外，可以由接收器来决定不使用FEC流、使用一个或多个FEC流。因此，每个流通常被分配个别的恢复特性，如果选择一个或另一个，则恢复特性限定诸如延时和要求的存储器这样的方案。根据其操作模式，接收器可以选择一个或若干修复流。其中，接收器可以基于以下考虑决定是选择还是不选择修复流。

第一考虑是期望的启动和端到端延迟。如果修复流要求大量的缓冲时间有效，那么这种修复流只可在时间移位操作中使用，或者在更差的发射条件下使用，但是它牺牲端到端延迟。

第二考虑是FEC能力，即，接收器可以只选择它支持的FEC算法。

第三考虑是所包括的被保护源流，例如，如果修复流保护没有被接收器选择的源流，那么它可以不选择修复流。

其他考虑例如是缓冲器大小、接收条件等等。

如果接收器订阅某个修复流，那么它必须订阅由修复流保护的所有源流并收集相关分组。

为了能够恢复由修复流保护的交付对象，接收器需要获得描述该修复流覆盖的交付对象的对应聚合的所要求的RepairFlow分段。修复流通过LCT会话以及唯一的TSI号以及对应的被保护源流的组合来限定。

如果接收器订阅修复流，那么它应当收集所有被保护的传输会话的所有分组。

在接收每个分组、源或修复分组时，接收器按照所列顺序进行以下步骤。

首先，接收器解析分组报头，并确认它是有效报头。如果它无效，就应当丢弃该分组，不做进一步处理。

第二，接收器解析码TSI，并确认TSI与修复流相关联或者与关联的被保护源流相关联。如果它无效，就应当丢弃该分组，不做进一步处理。

第三，接收器处理分组的剩余部分，包括适当地解释其他报头字段，并利用FEC有效载荷ID(其确定用于源对象的起始字节)和修复FEC有效载荷ID以及有效载荷数据，重构与超级对象相对应的解码块如下：

a)对于源分组，接收器通过会话信息以及有效载荷报头中携带的TOI，确定从哪个交付对象产生所接收的分组。对于修复对象，接收器通过会话信息以及有效载荷报头中携带的TOI，确定为哪个超级对象产生所接收的分组。

b)对于源分组，接收器收集用于每个超级对象的数据，并恢复超级对象。然后将接收的超级对象映射到源块，并产生对应的编码符号。

c)通过接收修复分组，可以恢复超级对象。

d)一旦恢复超级对象，就可以提取个别的交付对象。

交付对象缓存C262537可以存储信令信息和/或至少一个交付对象，并将信令信息和/或至少一个交付对象交付给DASH客户端C262550。交付对象缓存C262537可基于定时信息将信令信息和/或至少一个交付对象交付给DASH客户端C262550。

DASH客户端C262550可将广播服务解码。DASH客户端C262550可使用应用将至少一个交付对象解码。应用可以消耗至少一个交付对象。例如，应用可包括DASH媒体呈现。

图27示出根据本发明实施例的MPD。

交付MPEG-DASH内容实现通过单向传输交付实时媒体。但是，可将MPEG-DASH内容作为规则的对象来处理，可将交付优化，以支持受控延迟，受控加入时间及附加优化。

本节提供对于用于直播服务的适当MPEG-DASH格式化内容、将ROUTE用于交付源内容、适当的分组调度、和/或优化的接收器行为的概述。

用于线性TV服务的适当MPEG-DASH格式化内容

参照基线技术，根据MPEG DASH ISO BMFF直播简档将编码比特流分片和分组。这包括但不限于将片段模板用于片段的URL寻址以及每个片段起始于类型为1或2的流访问点。

除了DASH-IF的设置之外，还推荐应用互操作点(其包括HEVC)，包括非复用表现。上面讨论了进一步的优化。

提供基本设置的概述。

在片段中媒体数据的持续时间(片段持续时间)通常由@duration属性不断地发信号通知。片段持续时间的最大容差通常不超过±50％，并且多个片段的最大累积偏离是发信号通知的片段持续时间的±50％。实际片段持续时间中的这种波动例如是由于ad替换或者特定的IDR帧放置所致。

对于视频，添加宽度、高度和帧率的信令。

对于音频，添加语言的信令。

对于副标题或字幕，要添加副标题或字幕的作用的信令。此外，如果不同于音频的语言，则要添加语言的信令。

为了基于DASH提供基本线性媒体流服务，以下参数设置是合适的。

首先，将MPD@type设置为动态。

第二，将MPD@availabilityStartTime设置为任何合适的值，表示媒体呈现的起始时间，从而能够计算片段可用性。

第三，希望呈现MPD@minimumUpdatePeriod。如果提供MPD@minimumUpdatePeriod，即，媒体呈现的确切结束时间未知。设置最小更新周期的值主要影响两个主服务提供者方案：短的最小更新周期导致能力改变并且在更短的通知上宣告MPD中的新内容。但是，通过向MPD提供小的最小更新周期，客户端更频繁地检查MPD的更新。但是，小值并不意味着MPD不必更新，它只是限定可能的MPD更新的间隔。因此，在通过ROUTE交付DASH时，MPD@minimumUpdatePeriod可能最适合于被设置为小到0，并且在这种情况下，当产生MPD并且在原始服务器公布时，客户端检查指定壁钟时间的MPD@publishTime值。可将具有较早@publishTime的MPD更新为具有较晚@publishTime值的MPD。

第四，片段持续时间(SDURATION)。片段持续时间通常影响端到端延迟，但是也影响切换和随机访问粒度，如在基本简档中，每个片段起始于也可用作切换点的流访问点。在广播DASH交付中，即，不使用动态比特率自适应性，切换不太相关。例如，如果将内容也提供用于单播分配，则服务提供者考虑期望的端到端延迟、期望的压缩效率、启动延迟、和/或期望的切换粒度的至少其中一个来设置该值。片段持续时间的合理值在1秒到10秒之间。

第五，MPD@minBufferTime(MBT)和Representation@bandwidth(BW)。最小缓冲时间的值不向客户端提供任何关于要缓冲多少媒体时间的指令。该值描述在理想的网络条件下客户端会有多少缓冲器。因此，MBT并非描述网络中的突发或抖动；它描述内容编码中的突发或抖动。连同BW值一起，它是内容的特性。利用“漏桶”模型，它是桶的大小，因此@minBufferTime与@bandwidth的乘积表示内容编码最差情况的突发/抖动。最小缓冲时间提供用于每个流访问点的信息(并且在通常情况下，每个媒体片段起始于SAP，对于每个媒体片段的起始，这是成立的)，流的特性：如果通过比特率等于BW属性的值的恒定比特率信道交付表现(起始于任何片段)，那么在具有至多PT+MBT的延迟的时间最近，具有呈现时间PT的每个片段在客户端可用。例如通常可将MBT设置为内容的编码视频序列大小。

第六，MPD@timeShiftBufferDepth(TSB)。如果在直播边缘消耗内容，则将时间移位缓冲深度设置为短。但是，为了客户端在更加困难的网络条件下进行一些预缓冲，推荐TSB不小于4*SDURATION的推荐值以及媒体时间中的6秒。注意，timeShiftBufferDepth越短，客户端与片段器之间的同步就越好。如果对于内容的可访问性没有提供约束，则可将TSB设置为甚至超过媒体呈现持续时间的大值。但是，TSB不能超过客户端的能力。在加入时，在将其转发给应用之前，MBMS客户端可在MPD中改变该值，以避免客户端请求尚未接收的数据。

第七，MPD@suggestedPresentationDelay(SPD)。如果希望与其他装置的同步播出遵守相同的规则，和/或服务提供者需要限定节目的典型直播边缘，就提供该值。服务提供者考虑期望的端到端延迟、典型的在客户端中要求的缓冲，例如基于网络条件，片段持续时间SDURATION、和/或时间移位缓冲深度TSB的至少其中一个来设置该值。通常，合理的值可以是片段持续时间SDURATION的2到4倍，但是作为指导原则，为了客户端能够建立充足的缓冲，推荐该时间不小于4秒。但是，对于MBMS上的DASH，当交付保证将抖动最小化时，该值可以更小。

参照DASH优化(更短的Open-GOP片段)，在上述基本简档中，问题在于，一旦片段需要短小，例如在亚秒范围，每个片段就要求以IDR式SAP类型开始。这个约束不必要地限制了编码效率。

因此，提议采用完全随机访问SAP(类型1或2)不太频繁地定位的简档，但是SAP类型3(开放GOP)也被启用。这样允许在每个片段的起始，在开放GOP快速调整。

ROUTE对于直播服务的用途

为了支持ROUTE上的DASH流，可以交付用于服务的MPD，作为对象或元数据分段。以下映射适用。

首先，ROUTE会话交付被MPD参考的所有对象、MPD的所有更新、以及被MPD的任何更新参考的对象。

第二，如果交付分段作为ROUTE对象，则以下全部成立。a)LCT会话交付分段，使得交付对象的最后分组在接收器可用，不迟于它的分段可用性起始时间，如在MPD中宣告的。b)用于交付对象的、FDT中的Content-Location元素(或通过EFDT导出)与MPD中的片段URL匹配。

第三，如果交付MPD更新，则以下全部成立。a)如果交付更新的MPD作为FLUTE对象，则用于交付对象的、FDT中的Content-Location元素(或通过EFDT导出)与适当的参考MPD的URI匹配。b)MPD更新是对于先前交付的MPD的有效更新。

第四，如果交付MPD中的任何其他资源(例如，x链接资源、度量等等)，则a)用于交付对象的、FDT中的Content-Location元素(或通过EFDT导出)与MPD中对象的URL匹配。b)ROUTE会话交付对象，使得在交付的MPD序列上操作的DASH客户端可能请求资源之前，交付对象的最后分组在接收器可用的最迟时间不会出现。

MPD应当被交付为使得在任意访问点，它在接收器可用。MPD可以在带外交付，也可以在带内交付。如果不是频繁地交付MPD，则EFDT的ApplicationIdentifier子元素(即，LSID.SourceFlow.EFDT.ApplicationIdentifier)携带DASH专用元数据，也就是自适配集合/表现参数，例如语言、评估等等。

初始化片段被交付为使得在任意访问点，它在接收器可用。

参照发送器操作，为了优化DASH交付，应用以下分组产生，假定最小的交付和消耗单元是片段。片段可以短小，以解决低延迟和低调入时间。片段按顺序交付，即，start_offset总是增加。将start_offset设置为零的分组或者包括任何流访问点的分组包括EXT_PRESENTATION_TIME报头，它提供最早呈现时间到壁钟时间的映射，以将播出同步。分组的起始应当对准片段中样本的起始。如果进行了这种对准，就可将此优先级重要性映射到IP分组标签。分组应当被交付为使得对于片段而言有充足的时间处理分组并将它们解码，从而在发信号通知的呈现时间呈现。

参照接收器操作的基于MPD的接收，在规则的接收模式中，随着在传输会话中交付，ROUTE接收器按照以下序列收集对象：MPD、选择的表现的初始化片段、和/或媒体片段。

基于该信息以及MPD中的信息，规则的DASH客户端开始播放媒体。

ROUTE接收器只向接收器交付完整的对象。如果对象丢失，则不交付数据。

参照接收器操作的错误适应性接收，如果接收器经历对象中的分组丢失，则可以丢弃对象。作为替代，ROUTE接收器可以交付部分接收的对象。在这种情况下，应用可以决定处理这种部分对象，或者丢弃它。

参照接收器操作的快速加入，如果LSID包含用于每个传输会话的适配集/表现参数，并且接收流访问点，则客户端可以立即开始接收的媒体内容的播出，呈现根据呈现时间报头来调度。在启动播出之后，可以收集剩余组件，且可将丰富MPD用于提供附加替代物。

分层编码

对于分层编码，MPD发信号通知分层。在利用SVC如从ISO/IEC 23009-1附录G.5复制的示例性MPD中示出示例。注意，这仅仅是示例，但是同样适用于S-HEVC或者任何其他分层编译码器。在这种情况下，所有表现都包含在一个适配集中。依赖性用@dependencyId表示。从交付的角度，优选在单独的LCT传输会话中交付每个层，或者在单独的ROUTE会话中交付每个层。通过在LSID的ApplicationIdentifier中提供适当的信令(优选利用表示表现)，可以适当地表示分层。

此外，可通过将不同的修复流应用于不同的源流来进一步支持分层。通过合适的配置，可以支持不同的使用情况，例如仅在基本层、更鲁棒的基本层上的快速加入。

图28示出根据本发明示例的URI形式。

为了交付整个文件的子集作为交付对象，EFDT中的Content-Location可以使用特定的分段标识符来发信号通知子集。在此背景下，引入两个URL分段标识符。字节范围、分段ISO BMFF格式的分段、和/或DASH表现的子片段。部分细节参照http://www.w3.org/TR/media-frags/和http://www.w3.org/TR/2011/WD-media-frags-recipes-20111201/。

参照用于字节范围的Query参数，通过Query参数可将规则的文件的URL扩展如下：&range＝$first$-$last$"，其中用以下值代替$first$和$last$。

“$first$”是在一个范围中要通过第一字节的字节偏移替换的标识符，并且如果利用部分GET请求来执行该请求，那么它应当等于RFC 2616的14.35.1中“byte-range-spec”的“first-byte-pos”的值。

“$last$”是在一个范围中要通过最后字节的字节偏移替换的标识符；也就是说，所指定的字节位置是涵盖性的。如果利用部分GET请求来执行该请求，那么它应当等于RFC2616的14.35.1中“byte-range-spec”的“last-byte-pos”的值。

如果提供这种Content-Location，那么它指示交付对象是通过URL提供的对象的$first$与$last$之间的字节范围。

图29示出根据本发明实施例的URL形式。

附图示出URL。参照整个对象的URL，它表示为“http://cdn.example.com/movies/134532/audio/en/aac64.mp4”。参照交付对象的字节范围，它表示为“1876-23456”。参照交付对象的URL，它表示为“http://cdn.example.com/movies/134532/audio/en/aac64.mp4？range＝1876-23456”。

图30示出根据本发明实施例用于MP4分段标识符的参数。

用于具有MIME类型video/mp4或audio/mp4的资源的URI可以利用URI分段语法发信号只通知电影文件部分，具体而言只是电影分段。为了表示分段化的ISO BMFF文件的一个分段，本节限定分段标识符。

URI分段起始于“#”字符，终止URI的是字符串。MP4分段应当是key＝value pairs的逗号分离列表，在附图中限定了关键词和值参数的语法和语义。

fragment参数指示ISO BMFF中电影分段的值(电影分段号)。如果为0，则它指向电影报头。

subsegment参数指示ISO BMFF/DASH表现中子片段的值。如果为0，则它指向电影报头和片段索引。

参照示例，ISO BMFF文件中第27个电影分段表示为“http://www.example.com/mymovie.mp4#fragment＝27”。

ISO BMFF文件中第27到第31个电影分段表示为“http://www.example.com/mymovie.mp4#fragment＝27,31”。

ISO BMFF文件中的电影报头表示为“http://www.example.com/mymovie.mp4#fragment＝0”。

ISO BMFF文件中的电影报头和第一电影分段表示为“http://www.example.com/mymovie.mp4#fragment＝0,1”。

ISO BMFF文件中第27个子片段表示为“http://www.example.com/mymovie.mp4#subsegment＝27”。

ISO BMFF文件中第27到第31个子片段表示为“http://www.example.com/mymovie.mp4#subsegment＝27,31”。

ISO BMFF文件中的电影报头和片段索引表示为“http://www.example.com/mymovie.mp4#subsegment＝0”。

ISO BMFF文件中的电影报头、片段索引和第一子片段表示为“http://www.example.com/mymovie.mp4#subsegment＝0,1”。

参照ROUTE中的使用，如果EFDT包括Content-Location，或者隐含，或者导出，通过这种分段或子片段标识符，那么交付对象将确切是表示电影分段、子片段或者电影分段/子片段的序列的字节范围。

图31示出根据本发明实施例的接收器的操作。

广播接收设备可以利用广播网络(例如广播)和/或互联网协议网络(例如宽带互联网)的至少其中一个来接收广播服务，并将广播服务解码。广播接收设备可包括广播接口、宽带接口、和/或控制器的至少其中一个。广播接收设备的控制器可包括ROUTE接收器和/或DASH客户端的至少其中一个。ROUTE接收器可包括分组接收器、信令解析器、交付对象处理器、和/或交付对象缓存的至少其中一个。交付对象处理器可包括对象恢复块和/或FEC解码器的至少其中一个。上面描述了广播接收设备的细节。

广播接收设备可以利用广播接口和/或宽带接口的至少其中一个来接收包括广播服务的广播信号。例如，广播接收设备可通过单向信道接收包括服务的广播信号(CS31100)。

广播接收设备可以利用控制器提取信令信息，信令信息提供服务的至少一个内容组件的发现和获取(CS31200)。

例如，广播接收设备可以利用信令解析器提取信令信息，信令信息提供服务的至少一个内容组件的发现和获取。

信令信息可包括描述发射会话的第一信息，发射会话用于发射服务的至少一个内容组件。例如，第一信息可包括SLS、LSID、和/或S-TSID。或者，第一信息可包括ROUTE会话描述、LCT传输会话描述(或LCT会话描述)、和/或交付对象元数据(或对象元数据)。

第一信息可包括描述通过发射会话发射的源数据的第二信息。例如，第二信息可包括SourceFlow元素和/或RepairFlow元素。SourceFlow元素可以限定会话中的源流。RepairFlow元素可以限定会话中的修复流。

利用控制器，广播接收设备可基于信令信息还原至少一个交付对象(CS15300)。

例如，利用对象恢复块，广播接收设备可基于信令信息还原至少一个交付对象。基于广播服务中包括的至少一个分组，对象恢复块可以还原与源协议有关的至少一个交付对象和/或信令信息。

例如，利用FEC解码器，广播接收设备可基于包括广播服务的至少一个分组还原与修复协议有关的至少一个交付对象和/或信令信息。

利用控制器，广播接收设备可将广播服务和/或至少一个交付对象解码。

模块、处理部、装置、或单元可以是执行存储器(或存储部)中存储的连续处理的处理器。以上实施例中所述的各个步骤可通过硬件/处理器进行。以上实施例中所述的每个模块/块/单元可操作为硬件/处理器。此外，本发明提出的方法可以执行为代码。可将代码写入处理器可读存储介质，并因此通过设备中设置的处理器读取。

根据本发明实施例的每个方法发明可以按照可通过各种计算机器件执行并记录在计算机可读介质中的程序指令的形式实施。

计算机可读介质可以单独或者与程序指令组合地包括数据文件、数据结构等等。介质中记录的程序指令可以为本发明特别设计和配置，或者为本领域技术人员公知或可得。计算机可读介质的示例包括磁媒体，例如硬盘、软盘、以及磁带；光媒体，例如CD和DVD；磁光媒体，例如光盘；以及特别配置为存储和进行程序指令的硬件装置，例如只读存储器(ROM)、随机访问存储器(RAM)、闪存等等。程序指令的示例包括机器代码(例如通过编辑器产生)和文件(包含更高等级的代码，可利用解释器由计算机执行)两者。为了进行本发明上述示例性实施例的操作，所述硬件装置可以被配置为充当一个或多个软件模块，反之亦可。

虽然利用限制性实施例和附图描述了本发明，但是本发明并不限于上述实施例。对于本领域技术人员而言显然，在不脱离本发明精神或范围的情况下，在本发明中可以进行各种修改和变化。因此，希望本发明涵盖本发明的修改和变化，只要它们落入后附权利要求书及其等同物的范围。

在用于实现本发明的最佳实施方式中描述了各种实施例。

工业应用性

本发明可用于一系列广播信号提供领域。

对于本领域技术人员而言显然，在不脱离本发明精神或范围的情况下，在本发明中可以进行各种修改和变化。因此，希望本发明涵盖本发明的修改和变化，只要它们落入后附权利要求书及其等同物的范围。

Claims (12)

1.一种广播接收设备，包括：

分组接收器，所述分组接收器被配置为接收通过专用传输会话携带信令数据的传输分组，以及接收通过不同于专用传输会话的传输会话携带一个或多个交付对象的传输分组，其中每个交付对象是用于广播服务的文件的一部分；

信令解析器，所述信令解析器被配置为提取提供会话描述信息的所述信令数据和包括扩展文件交付元素的资源流元素；以及

交付对象处理器，所述交付对象处理器被配置为基于所述信令数据恢复所述一个或多个交付对象，

其中，所述交付对象处理器被进一步配置为通过用在每个传输分组的头部中传递的传输对象标识符(TOI)替换包括在所述扩展文件交付元素中的文件模板信息的标识符来导出用于一个或多个交付对象的相对位置信息。

2.根据权利要求1所述的广播接收设备，

其中，至少一个传输分组包括开始偏移信息，所述开始偏移信息指示与在所述至少一个传输分组中携带的至少一个交付对象的部分的开始字节位置相对应的直接地址。

3.根据权利要求2所述的广播接收设备，

其中至少一个传输分组的有效载荷携带交付对象的连续部分，该连续部分从由第一字节信息指示的字节的开始到由第一字节信息和第二字节信息的总和指示的字节的开始，

其中，所述第一字节信息是起始偏移信息的值，以及所述第二字节信息是小于以字节为单位的所述交付对象的传输长度的最大传输单元的大小。

4.根据权利要求1所述的广播接收设备，

其中，所述信令数据和所述交付对象通过单独的传输会话传递。

5.根据权利要求1所述的广播接收设备，

其中，所述交付对象处理器进一步被配置为基于最大传输大小信息分配用于存储至少一个交付对象的缓冲空间，以及

其中，所述扩展文件交付元素包括所述最大传输大小信息，所述最大传输大小信息指示所述至少一个交付对象的最大传输大小。

6.根据权利要求5所述的广播接收设备，

其中，所述交付对象处理器进一步被配置为：

获取用于所述至少一个交付对象的所述至少一个传输分组的有效载荷，以及

将所述有效载荷的数据复制到为所述至少一个交付对象保留的所述缓冲空间中。

7.一种广播接收方法，包括：

通过广播接收设备接收通过专用传输会话携带信令数据的传输分组，

通过广播接收设备接收通过不同于专用传输会话的传输会话携带一个或多个交付对象的传输分组，其中所述交付对象是用于广播服务的文件的一部分；

通过所述广播接收设备提取提供会话描述信息的所述信令数据和包括扩展文件交付元素的资源流元素；以及

通过所述广播接收设备基于所述信令数据恢复所述一个或多个交付对象，以及

其中，通过广播接收设备通过用在每个传输分组的头部中传递的传输对象标识符(TOI)替换包括在所述扩展文件交付元素中的文件模板信息的标识符来导出用于一个或多个交付对象的相对位置信息。

8.根据权利要求7所述的广播接收方法，

其中，至少一个传输分组包括开始偏移信息，所述开始偏移信息指示与在所述至少一个传输分组中携带的至少一个交付对象的部分的开始字节位置相对应的直接地址。

9.根据权利要求8所述的广播接收方法，

其中至少一个传输分组的有效载荷携带交付对象的连续部分，该连续部分从由第一字节信息指示的字节的开始到由第一字节信息和第二字节信息的总和指示的字节的开始，

其中，所述第一字节信息是起始偏移信息的值，以及所述第二字节信息是小于以字节为单位的所述交付对象的传输长度的最大传输单元的大小。

10.根据权利要求7所述的广播接收方法，

其中，所述信令数据和所述交付对象通过单独的传输会话交付。

11.根据权利要求7所述的广播接收方法，

其中，恢复所述至少一个交付对象进一步包括基于最大传输大小信息分配用于存储至少一个交付对象的缓冲空间，以及

其中，所述扩展文件交付元素包括所述最大传输大小信息，所述最大传输大小信息指示所述至少一个交付对象的最大传输大小。

12.根据权利要求11所述的广播接收方法，

其中，恢复所述至少一个交付对象进一步包括：

获取用于所述至少一个交付对象的所述至少一个传输分组的有效载荷，以及

将所述有效载荷的数据复制到为所述至少一个交付对象保留的所述缓冲空间中。