基于拉动式媒体系统

摘要

在一个实施例中，一种方法包括在发布者处生成针对媒体的请求以及将该请求发送给媒体管线，该媒体被从该媒体管线发送到分发管线。媒体管线包括流媒体处理组件链，该链由该发布者动态配置。本文还公开了一种装置和逻辑。

说明书

技术领域

本公开一般涉及通信网络，更具体地涉及媒体系统。

背景技术

媒体分发系统的典型头端包括多个处理元件。在传统系统中，诸如编 码器、转码器、封装器以及发布和存储设备之类的元件驻存在不同的系统 中，在传输是单向并且是基于广播的情况下，由于广播电视的遗留问题而 导致这些系统彼此耦合松散。

附图说明

图1示出了本文所描述的实施例可在其中被实现的网络示例。

图2示出了可被用于实现本文所描述的实施例的网络设备的示例。

图3是示出图1所示的网络的媒体管线示例的框图。

图4是根据一个实施例，示出用于基于拉动式媒体的过程概述的流程 图。

在附图的多个视图中，相应的参考标号指代相应的部分。

具体实施方式

概述

在一个实施例中，一种方法一般包括：在发布者处生成针对媒体的请 求以及将该请求发送给媒体管线，该媒体被从媒体管线发送到分发管线。 媒体管线包括流媒体处理组件链，该链由发布者动态配置。

在另一实施例中，一种装置一般包括：处理器，用于在发布者处生成 针对媒体的请求，并且将该请求发送给媒体管线，该媒体被从媒体管线发 送到分发管线。该装置还包括存储器，用于存储针对媒体管线的标识符。 媒体管线包括流媒体处理组件链，该链由发布者动态配置。

示例实施例

给出以下描述以使本领域普通技术人员能够实施并使用实施例。具体 实施例和应用的描述仅作为示例提供，并且各种修改对本领域技术人员而 言将是明显的。在不脱离实施例的范围的情况下，本文描述的一般原理可 被应用于其他应用。因此，实施例不限于所示的这些实施例，而是根据与 本文所描述的原理和特征一致的最宽范围。为了简洁起见，未对涉及与实 施例有关的技术领域中所熟知的技术材料的细节进行详细描述。

媒体系统的头端可以包括，例如，初级采集器(如果在起始站点 处)、初级编码器(如果在初级分发站点处)、次级编码器、统计复用 器、以及解复用器(如果在诸如经由SPTS(单节目传输流)或MPTS(多 节目传输流)广播/多播从卫星或陆地分发接收媒体的电缆头端之类的次分 发站点处)、转码器(针对基于IP的内容分发，其包括直播VoD(视频 点播)并且涉及针对ABR(可调节比特率)系统的多速率转码)、容纳多 种流格式的封装器、以及用于处理转到分发系统的内容的发布和存储设 备。

在传统系统中，这些元件驻存于不同的系统中，这些系统彼此耦合松 散。为了使它们一起工作，管理系统被用于分别供给每个元件，使得整组 处理元件协调一致地一起工作。这会产生复杂的管理系统，该管理系统需 要提供负载均衡、健康监控、故障切换、恢复力以及稳健性。由于整个系 统是基于该管理系统的，因此管理系统自身必须做得高度可靠。此外，如 果头端的组件在地理上是分布的，则管理系统的实例必须位于每个位置， 以便提供防止站点故障的稳健性。

本文所描述的实施例提供了一种面向web的基于拉动式管线，用于在 能够接收各种类型的初级输入的流媒体头端系统中处理媒体。如下文所详 细描述的，该管线在位于多阶段处理的结束处的发布者的控制之下。这允 许按需建立灵活的媒体管线，该管线贯穿处理、虚拟机、物理机和网络站 点。实施例允许即时建立媒体管线，而无需管理系统协调所有单独的元 件，同时允许很好地映射到当前的数据中心和云服务技术上的命名、负载 分配和故障恢复技术。

现在参考附图，首先参考图1，示出了本文所描述的实施例可在其中 被实现的网络示例。为了简单起见，只示出了少数节点。该网络包括经由 发布者20互连的媒体管线和分发管线。在图1所示的示例中，媒体管线 包括内容提供者10和头端12。如下文针对图3所描述的，头端12可以包 括任意数量或类型的处理组件。媒体管线包括流媒体处理组件链，该流媒 体处理组件链能够从内容提供者10接收不同类型的输入(例如，卫星复 用广播、文件摄取、陆地IP多播等)。内容提供者10可以是例如，广播 视频的内容提供者(例如，有线电视公司、数字卫星公司)、内容分发节 点、服务器等。

分发管线包括内容服务器14、内容分发系统16和客户端18。内容服 务器14例如可以是在本地存储数据或经由网络、卫星、电缆或任意其他 通信设备从另一服务器或媒体源获取数据的服务器(例如，原始服务 器)。内容服务器14获取从发布者20(或直接从媒体管线)接收到的经 打包的内容、存储该内容、并基于终端用户请求来提供片段。即将到来的 经打包内容可被存档以供后续使用，并且服务器可将经打包的内容重新发 布给分布在网络中的其他服务器。

内容分发系统16可以包括，例如，用于向数字电视和机顶盒分发内 容的TV流应用、以及用于向IP设备(例如，个人计算机、移动电话和手 持设备)分发内容的互联网流应用。内容分发系统16可以包括与任意数 量的客户端(终端用户)18通信的任意数量和类型的网络设备或网络。客 户端18例如可以是个人计算机、媒体中心设备、移动设备(例如，电 话、个人数字助理、数字媒体播放器、平板电脑、多媒体设备)、机顶 盒、台式计算机、膝上型计算机、主机、服务器或能够在网络内进行媒体 (例如，音频、视频或数据)交换的任意其他设备。

媒体管线和分发管线经由发布者20连接。发布者20例如可以是位于 网络设备处的应用。发布者20还可以位于分发管线(例如，原始服务 器)或媒体管线内的组件(例如，头端)处。任意数量或类型的网络设备 (例如，路由器、交换机、网关、服务器)可以被插入媒体或分发管线 中，并且这些管线可以穿过任意数量的网络(例如，局域网、城域网、广 域网、企业网络、数据中心、互联网、内联网、无线电接入网、公共交换 网或任意其他类型的网络或其组合)。

如下文详细描述的，媒体管线在控制平面中是基于拉动式的而不是基 于推送式的。发布者20动态配置构成媒体管线的处理组件链。媒体管线 的每个实例是独立的，并且链中的元件共享命运(简化故障恢复)。在一 个实施例中，冗余和故障恢复是通过复制在发布者20处明确实例化的管 线来实现的。媒体管线从尾部(发布者20)发起。这保证只有分发系统实 际想要的媒体流被主动处理。该发布操作独立于内容观看者做出的内容获 取事务。

在一个实施例中，媒体管线由从下流元件接受HTTP(超文本传输协 议)连接并且向上游元件发布HTTP连接的元件建立。本文所使用的术语 “下游”指的是在传统系统中内容提供者10将向客户端18发送媒体的方 向。因此，头端12从发布者20接受HTTP连接。

该网络还包括一个或多个DNS(域名系统)服务器22，该一个或多 个DNS服务器22与发布者20和头端12的组件进行通信。在一个示例 中，DNS22可以通过预提供的元数据24的数据库来扩增，该元数据描述 媒体内容。元数据描述通过媒体管线承载，从而允许管线中的每个元件使 用与其各自的处理角色相关的元数据元素，而不是将其限制在管理系统 中。这允许插入新的管线元件，而不干扰其他管线元件或中央管理系统。 如下文所述，DNS22可以操作为在媒体管线内执行负载均衡。

应该理解，图1所示及本文所描述的网络只是示例，并且在不脱离实 施例的范围的情况下，实施例可以在具有不同的网络拓扑或网络设备的网 络中实现。

图2示出了可被用于实现本文所描述的实施例的网络设备30(例如， 包含发布者20的节点)的示例。在一个实施例中，网络设备30是可编程 机器，该可编程机器可以在硬件、软件或其任意组合中实现。网络设备30 包括一个或多个处理器32、存储器34和网络接口36。存储器34可以是 易失性存储器或非易失性存储器，其存储供处理器32执行和使用的各种 应用、操作系统、模块和数据。例如，发布者20可以包括存储在存储器 34中的代码。

逻辑可被编码于一个或多个有形介质中以供处理器32执行。例如， 处理器32可以执行存储于计算机可读介质(例如，存储器34)中的代 码。计算机可读介质例如可以是电子的(例如，RAM(随机存取存储 器)、ROM(只读存储器)、EPROM(可擦除可编程只读存储器))、 磁的、光的(例如，CD、DVD)、电磁的、半导体技术或任意其他适当 的介质。

网络接口36可以包括任意数量的接口(连卡、端口)，用于接收数 据或向其他设备发送数据。接口36例如可以包括用于连接到计算机或网 络的以太网接口。

应该理解的是图2所示及上述网络设备30只是示例，并且可以使用 网络设备的不同配置。例如，网络设备30还可以包括可操作为协助本文 所描述的功能的硬件、软件、算法、处理器、设备、组件或元件的任意适 当的组合。

图3根据一个实施例，示出了图1的媒体管线的示例。在图3所示的 示例中，媒体管线包括编码器40、转码器42、广告拼接器44和打包器 46。编码器40从内容提供者10接收媒体馈送，并对内容进行编码。转码 器42接收经编码的比特流并将其转码为各种内容配置文件。广告拼接器 44可以向内容插入一个或多个广告。打包器46接收经转码的流并将其转 换为供应商专用文件格式(例如，Apple的HLS)或标准文件格式(例 如，ISOBMFF)。打包器46还可以执行封装或可以提供单独的封装器。

这些组件被用于向分发管线提供线性数据。元件可被打包在一起或位 于不同的模块中，这些模块例如运行在通过IP(互联网协议)连接在一起 的不同的处理、虚拟机或物理机中。应该理解的是图3所示的组件只是示 例，并且媒体管线可以包括更少的组件、更多的组件或不同的处理组件。 例如，媒体管线可以包括封装器、存储设备、解复用器等。元件例如可以 以线性序列(如图3所示)、多叉树、或非循环有向图序列的形式。

只有媒体管线的“头”元件需要处理即将到来的实时媒体馈送的特有 损耗和时序特性。对于实时馈送，缓冲和损耗缓解只需要在一个位置进 行。如果管线正在进行线下获取(例如，接收针对VoD的电影或导入其他 存储的内容)，则无需从实时到可靠弹性缓冲器链(由HTTP/TCP提供) 的转换。

基于拉动式系统使用单播消息(例如，HTTP/TCP)48来从内容提供 者10取回媒体。媒体50可以以HTTP响应的形式在带内被发送或以文件 的形式被发送，或者例如可指定媒体被存储的位置。最后的管线阶段(发 布者20)对媒体管线的控制保证数据到达不快于发布者能够使数据可用或 缓冲到临时存储设备。如上所述，所有损耗基本上都被向上游推到管线的 头部，从而避免在中间的管线阶段中引入损耗和抖动来缓解复杂性的需要 (如传统系统中使用多播适应性传输流等的情况)。

在一个实施例中，媒体50不流过发布者20，而是直接从媒体管线的 尾部(打包器46)进行发送，如图3中的虚线所示。在一个示例中，来自 发布者20的请求48指定媒体管线的尾部应该将媒体存储于何处。这例如 可以是以URL的形式，该URL指定与内容服务器14相关联的存储元件 49。这允许数据流直接从媒体管线到达存储元件49。

DNS服务器22与媒体管线的每个组件进行通信，并参与每个管线阶 段。在一个实施例中，DNS服务器22被用于针对每个媒体管线阶段的独 立负载均衡或分发。为了简单起见，只示出了一个DNS服务器22，然 而，在网络中可以存在任意数量的DNS服务器。

图4是根据一个实施例，示出用于基于拉动式媒体的过程的概述的流 程图。在步骤60，发布者20生成针对流媒体(例如，视频流)的请求。 发布者20将单播请求(例如，HTTPGET请求)向上游发送到媒体管线 (步骤62)。如先前所述，发布者20动态配置媒体管线中的处理组件 链。发布者20接收所请求的媒体(步骤64)并将该媒体发送给分发管线 (步骤66)。

应该理解的是图4所示及上述过程只是示例，并且在不脱离实施例的 范围的情况下，步骤可被添加、移除、组合或修改。

在一个实施例中，媒体管线使用URI(统一资源标识符)来标识管线 阶段以及该阶段将处理的特定媒体流。通过DNS，URI可被限制为针对内 容源一致的名称。例如，特定流可被命名为“ESPN-2-east-coast-feed (ESPN-2东海岸馈送)”。管线中的处理元件全部使用该名称并使用 DNS来形成处理链。在该示例中，处理链起始于卫星下行链路盒，该卫星 下行链路盒知道如何在下行链路上“调谐”到该内容并且从MPTS解复用 特定信道。如上所述，媒体管线可被动态构建。例如，对于DASH(动态 自适应HTTP流)ABR(自适应比特率)发布者，该发布者可以针对 dash-encaps(dash封装)/ESPN-2-east-coast-feed/abr-for-cable-subscribers (针对电缆订户的abr)发出HTTPGet请求。

当接收到该请求时，DNS使用本地搜索域来将名称“dash-encaps”投 射到特定部署的dash封装服务(例如，“dash-encaps.ny- metro.cablevision.com”)。这进而通过对已由头端操作者注册到DNS中 的DASH封装的任意实例的DNSSRV(服务)记录获得解决。DASH封 装知道其需要从多速率转码器(或并行转发器组)获得输入，并且告知编 码器(或多个编码器)经由从下游组件传递给它的URI来处理abr-encoder (abr-编码器)/ESPN-2-east-coast-feed/abr-for-cable-subscribers。

在一个示例中，“abr-for-cable”是用于转码的服务描述，其可在数据 库中进行查找，或作为XML(可扩展标记语言)(或其他格式)描述从 另一web服务取回。编码器40产生期望输出，该输出例如可以是针对各 种速率和音频加辅助流或具有复用在一起的速率的MPEG传输流(图3) 的多个示例性流。编码器40然后将输出发送回转码器42与封装器(打包 器)46之间的现有HTTP连接上。封装器获得数据并产生发布者20所请 求的经封装的输出(例如，ISO/BMFF(基础媒体文件格式)、HLS (HTTP直播流)、HSS(HTTP流畅流))。

在一个实施例中，媒体管线是控制管线，该控制管线具有作为Get请 求的结果被返回或在独立的Post事务中被发送的媒体。在一个示例中， HTTPGet事务被用于请求数据，并且该数据响应于Get返回。在另一示例 中，HTTP事务可以是Put或Post，其中数据是上游管线元件向其发布 Post以移动该数据的URL(统一资源定位符)。这允许第三方数据移动， 例如，当发布给不同管理域中的服务器时。

用URI命名的动态可重配置管线提供故障切换、负载均衡、利用 HTTP重试、以及通过服务报告和重定向器的基于DNS的主机选择。这简 化了配设，因为每种类型的管线元件的新实例仅需通过DNS将其自身注 册到相应的服务名称下。此外，针对各管线阶段的故障模型可以是停止运 行故障。冗余和恢复通过正常基于web的恢复机制来提供，该恢复机制例 如使用cookie或其他状态变量来保证来自热备用或暖备用元件的输出一 致。

基于拉动式媒体系统可以包括中央管理系统，然而，该管理系统在媒 体的具体配置和处理中不是活动元件，并且无需被配置为高可靠性，因为 其他元件(例如，DNS服务器、IP路由器和虚拟机管理器)提供可靠性。 相反，管理系统处理注册DNS中的管线元件实例，保持元数据数据库知 晓内容以及存储管线前面的元件的授权配设信息(例如，针对各种内容馈 送的IP多播地址)。

从上文可以观察到，本文所描述的实施例提供了很多优势。例如，通 过从用于在流媒体头端中配置和管理媒体管线的传统北向管理系统方法切 换到面向拉动式、基于web的控制系统，头端可做得不那么复杂，更鲁棒 和可扩展。实施例也不那么易受错误配置的影响，因为动态管线构建避免 管线的各个元件的冗余配置。在一个或多个实施例中，统一命名、负载分 配和故障恢复技术提供了更好地映射到数据中心和云部署的更加可扩展的 系统。

虽然该方法和装置已经根据所示实施例进行了描述，但是本领域普通 技术人员将容易认识到，在不脱离实施例的范围的情况下可做出变化。因 此，期望以上描述中所包含的以及附图中所示出的所有事项应被解释为示 意性而非限制性的。