在实况视频编码和流传输中进行帧复制和帧扩展的系统和方法与流程

本发明一般而言涉及来自实况输入流的自适应位速率流的实况编码领域。具体而言，本发明涉及用于优化和改进来自实况输入流的自适应位速率流的实况编码的若干技术。

背景技术：

流传输技术已经进步到支持实况顶层流传输的点。实况活动现在可以从由实况编码服务器生成的自适应位速率流来查看。实况编码服务器常常利用mpeg-dash格式(即，经http的动态自适应流传输)。mpeg-dash(iso/iec23009-1)是用于经互联网流传输多媒体内容的标准。mpeg-dash由运动图像专家组(mpeg)开发。mpeg已经负责开发以前的多媒体标准，包括mpeg-2、mpeg-4、mpeg-7、mpeg-21等。mpeg-dash是一种自适应的位速率流传输技术，其启用经互联网从常规httpweb服务器输送媒体内容的高质量流传输。通常，mpeg-dash使用各自包含经由超文本传输协议(http)检索的视频片段的小文件序列，每个片段包含呈现的重放时间的短间隔。呈现可以是实况活动和/或具有指定的持续时间。可以以各种不同的位速率(诸如300kb/s、500kb/s和3mb/s)使自适应位速率流可用。将源流实况编码和/或转码成多个自适应位速率流可以要求大量的计算资源，并且实况编码硬件相当昂贵。

附图说明

图1是图示根据本发明的实施例的实况编码系统的网络图。

图2是图示根据本发明的实施例的、由实况编码系统执行的高级处理的流程图。

图3概念性地图示了根据本发明的实施例的、扩展帧以补偿丢失的输入帧的实况编码系统的示例。

图4概念性地图示了根据本发明的实施例的、扩展帧以补偿丢失的输入帧的实况编码系统的备选示例。

图5概念性地图示了根据本发明的实施例的、扩展帧以补偿延迟的输入帧的实况编码系统的示例。

图6概念性地图示了根据本发明的实施例的、扩展帧以补偿延迟的输入帧的实况编码系统的备选示例。

图7概念性地图示了根据本发明的实施例的、复制帧以补偿系统负载的实况编码系统的示例。

图8是用于根据本发明的实施例的实况编码系统和流传输的数据流图。

图9是可以由本发明的实施例利用的用于mpeg-dash的媒体呈现描述(mpd)数据模型的示例。

图10概念性地图示了根据本发明的实施例的实况编码服务器的体系架构。

具体实施方式

现在转向附图，图示了根据本发明的实施例的实况编码系统。在若干实施例中，实况编码系统接收实况媒体馈送，诸如(但不限于)体育赛事、实况新闻报道、网络直播流和/或单个或多路复用的媒体流。媒体流包含在由提供商输送的同时不断地由客户端接收并呈现给客户端的多媒体。流传输(streaming)是指经由流输送媒体的过程。实况编码系统可以向客户端提供从实况输入流编码的媒体流。而且，实况编码系统可以将接收到的实况媒体馈送编码成具有不同最大位速率的若干不同的自适应位速率流。实况编码系统还可以经由包括(但不限于)http请求的协议将实况媒体呈现中的编码的自适应位速率流发送到流传输客户端，和/或将编码的自适应位速率流提供给服务器用以分发到客户端设备。实况媒体呈现的编码和传输对执行这些操作所使用的硬件来说可能是繁重的。本发明的实施例提供了几种减少执行实况编码和传输操作的硬件上的负载的技术。例如，根据本发明的许多实施例的实况编码系统可以根据若干测量来评估网络和/或服务器负载水平。负载常常作为实况编码系统正在执行的工作(例如，计算、编码操作、存储器操作等)的量来测量。基于评估，实况编码系统可以调整来自实况媒体馈送的视频帧如何被编码。例如，实况编码系统的一些实施例复制当前编码帧，而不是对所述当前帧进行重新编码，然后根据需要针对若干不同的自适应位速率流将复制的帧调整到不同的位速率、分辨率和/或上下文。此外，实况编码系统的各种实施例可以扩展正被重新包装和/或重新编码的当前帧的持续时间。利用这些和其它技术，根据本发明的实施例的实况编码系统可以更高效地处理接收数据中的间隙、数据的较慢馈送和/或服务器硬件上的重负载。

网络传输水平可以影响实况编码过程。例如，当实况媒体馈送在从实况输入流到实况编码系统的各网络传输层中遭受中断时，实况编码系统会在传入的数据中遇到间隙。传入的数据中的间隙会在输出数据中产生间隙和/或导致实况编码系统不能在被请求时输送输出帧。根据本发明的一些实施例的实况编码系统可以评估传入的媒体馈送，以确定间隙是何时发生的。这些评估可以基于若干测量，包括(但不限于)传入的帧速率、传入的位速率、到达帧之间的时间和/或网络带宽测量。根据本发明的许多实施例的实况编码系统可以通过在将传入的媒体流重新包装成若干自适应位速率流期间复制帧和/或扩展帧来补偿数据中检测到的间隙。通过复制帧和/或扩展帧，实况编码系统可以允许网络条件有稳定的机会，而不会危及在被请求时客户端所依赖的帧的可用性。具体而言，实况编码系统可以落后于实况流传输媒体的实况边缘。客户端通常从位于呈现的实况边缘的实况流中请求帧。当在本文中被使用时，术语“实况边缘”是指在没有请求还不可用的片段的风险的情况下客户端可以请求的实况流的最近编码的片段。请求还不可用的片段导致许多流传输错误，诸如(但不限于)延迟、http未找到错误，并且会导致带宽阻塞重复请求。

服务器负载水平也会影响实况编码过程。在实况编码系统被实现为实况编码服务器的时候，服务器硬件会被编码过程压倒。在实况编码服务器落后于实况边缘的时候，若干自适应位速率流会由于客户端依赖在实况边缘进行的请求而失败。具体而言，实况流传输客户端可以基于实况编码系统不比实时更慢地生成片段的假设来请求视频的片段。根据本发明的许多实施例的实况编码系统可以通过扩展当前帧并调整输出帧的时间戳来补偿服务器负载。扩展的帧可以产生微小的和/或难以察觉的视觉错误，但将保留请求并接收客户端为了实况流传输而依赖的http循环。而且，根据本发明的实施例的实况编码系统还可以通过复制当前帧并调整输出流所需的其帧上下文来补偿服务器负载。

已经讨论了根据本发明的许多实施例的实况编码系统的操作和功能的简要概述，下面给出根据本发明的实施例的、用于实况编码系统的系统、服务器和方法的更详细讨论。

用于实况编码系统的网络体系架构

图1中图示了根据本发明的实施例的、用于实况编码系统的网络体系架构。系统100包括实况编码服务器和支持硬件102，其包括支持实况编码所需的应用服务器、数据库服务器和/或数据库。实况编码服务器和支持硬件102可以从内容源114接收实况媒体内容和/或非实况内容。内容源114可以包括用来向实况编码服务器和支持硬件102提供媒体的硬件。从内容源114接收的媒体可以包括(但不限于)web流、实况媒体广播、电视广播、实况活动覆盖、来自实况相机的视频馈送、先前存储的媒体、原始媒体馈送、编码的媒体馈送和/或从本地和/或远程存储装置接收的静态文件。

实况编码服务器和支持硬件102可以经网络104与若干组设备进行通信，以便提供内容的流。设备组包括(但不限于)web、文件和/或媒体服务器106、计算设备108和/或移动设备112。来自这些设备组的设备的用户可以利用本地流传输客户端查看所提供的流传输内容。此外，来自web、文件和/或媒体服务器106的web服务器还可以对于所提供的流传输内容的附加下游查看者和/或客户端充当主机。

如图1中所示，实况编码服务器和支持硬件102包括应用服务器、数据库服务器和数据库。在各种实施例中，实况编码服务器和支持硬件102可以包括不同数量和类型的设备。例如，实况编码服务器和支持硬件102可以被实现为单个计算设备，其中这单个计算设备具有足够的存储、联网和/或计算能力。但是，实况编码服务器和支持硬件102还可以使用各种类型和多个位置的多个计算设备来实现。例如，实况编码服务器和支持硬件102可以被实现为用于编码实况媒体的实况编码服务器和用于响应针对由实况编码服务器编码的片段的http请求的http服务器。虽然实况编码服务器和支持硬件102被示为包括应用服务器、数据库服务器和数据库，但是本领域技术人员将认识到的是，本发明不限于图1中所示的设备并且可以包括附加类型的计算设备(例如，web服务器和/或云存储系统)。

在图1所示的实施例中，网络104是互联网。实况编码服务器和支持硬件102可以通过网络104并经无线连接110来从移动设备112接收请求并向移动设备112发送媒体片段。无线连接110可以是(但不限于)4g连接、蜂窝网络、wi-fi网络和/或适于具体应用的要求的任何其它无线数据通信链路。实况编码服务器和支持硬件102可以通过网络104直接与计算设备108和web、文件和/或媒体服务器106通信。其它实施例可以使用其它网络(诸如以太网或虚拟网络)在设备之间进行通信。本领域技术人员将认识到的是，本发明不限于图1所示的网络类型并且可以包括附加类型的网络(例如，内联网、虚拟网络、移动网络和/或适于具体应用的要求的其它网络)。

虽然在图1中示出了具体的体系结构，但是可以使用涉及电子设备和网络通信的不同体系架构来实现实况编码系统以执行操作并提供根据本发明的实施例的功能。

用于实况编码服务器的系统和过程

在实况编码系统中，客户端常常依赖能够请求和接收位于实况编码边缘的帧。编码和/或传输的任何中断都会导致客户端无法接收所需的帧、失败的http请求、图像断断续续以及观众所感受的普遍沮丧。根据本发明的许多实施例的实况编码系统可以使用传入媒体和/或编码系统负载的实时分析来通过下面讨论的技术减轻实况编码中的损失和中断。

图2概念性地图示了根据本发明的实施例的、可以由实况编码系统在接收媒体、生成流以及将生成的流提供给实况流传输客户端时执行的过程200。在多个实施例中，过程200由根据上面结合图1描述的实施例的实况编码服务器执行。特别地，过程200可以由mpeg-dash实况编码服务器在媒体的连续实况编码和实况流传输期间执行。

媒体可以被接收(210)。如上面所提到的，媒体可以涵盖许多不同类型、格式、标准和/或呈现。所接收的媒体常常是已编码媒体的实况馈送。所接收的媒体可以包括(但不限于)从本地和/或远程存储装置接收的输入流、实况媒体馈送、电视馈送、卫星馈送、web流和/或静态文件。

流可以从接收到的媒体生成(220)。所生成的流可以是许多可能的格式，诸如(但不限于)mpeg-dash、h.264/avc、http实况流传输、平滑流传输和/或任何其它自适应位速率格式。然后所生成的流可以经网络连接被提供给流传输客户端。通常，所生成的流将具有不同的最大位速率并且根据变化的编码参数进行编码。在一些实施例中，流是利用实况编码服务器的重新包装应用来生成的。重新包装应用将接收到的媒体重新包装成输出流。由此，重新包装应用可以根据需要利用各种编码器和解码器来根据需要生成流。

流的生成可以是在接收实况媒体时执行的持续过程。在流响应于接收实况媒体而持续生成期间，可以评估实况编码系统上的负载水平、通信网络中的负载水平、媒体接收中的间隙和/或流生成中的间隙(230)。而且，不同的实施例可以评估实况编码服务器操作的其它方面。执行所述评估可以包括若干子操作。例如，实况编码系统可以检查接收到的媒体的传入数据速率和/或帧速率。可以将接收到的媒体的传入数据速率和/或帧速率与根据实况编码系统的内部逻辑确定的帧时间进行比较。内部逻辑可以包括确定可靠时间的若干来源，诸如(但不限于)所接收的媒体的时间戳、实况编码系统上的时钟实现和/或接收到的媒体的所声明的帧速率。在一些实施例中，实况编码系统可以测量传入的帧之间的时间差，以便计算总体传入数据速率。然后，实况编码系统可以监视计算出的总体传入数据速率，以识别传入的数据中的间隙或可能压倒实况编码系统的处理能力的潜在浪涌。这些评估中的一个或多个可以指示实况编码系统没有在适当的时间接收到帧和/或将无法及时编码帧以满足对于实况编码系统的实况边缘要求。

为了减轻不能及时为实况边缘生成帧的风险，接收到的媒体的帧可以可选地被重复和/或复制(240)。在一些实施例中，可以修改重复的帧，以考虑与各种生成的流相关联的新的帧上下文。不同的帧上下文可以包括(但不限于)不同的分辨率、不同的帧类型(诸如i帧、b帧和/或p帧)、不同的最大位速率。从接收到的媒体生成流常常涉及将接收到的媒体重新编码为不同的格式，其中接收到的媒体包括编码的帧。接收到的媒体的重新编码可以在由实况编码系统执行的更多资源密集型操作当中。然后重复的帧可以在生成的流中使用，而不需要相对昂贵的重新编码操作。而且，除了来自接收到的媒体的编码帧之外，重复的帧还可以从来自接收到的媒体的原始帧复制。

但是，复制编码帧而不是重新编码帧(其作为实况编码过程的一部分)会导致输出流违反h.264/avc中的假定参考解码器(hrd)的某些要求。根据定义，当其输入是兼容流时，hrd不应当上溢或下溢。复制大的编码帧并在低最大位速率流中利用复制的流存在造成缓冲区上溢的风险，这将导致hrd要求失败。但是，由于其更灵活的缓冲区，软件解码器客户端可以补偿这一点，而不会出现问题。软件解码器客户端可能需要附加的cpu周期来处理复制的帧。当复制的帧用于较低最大位速率流中时，硬件解码器客户端将由于可能的缓冲区上溢而遇到错误。本发明的一些实施例提供了减少复制帧用于较低最大位速率输出流的位值，以便减轻硬件解码器中缓冲区上溢的风险。在还有其它实施例中，重复的帧仅用于其自己具体的最大位速率输出流；由此防止高位值帧被用于低最大位速率流。这可以通过为每个输出流包括单独的编码过程来实现。

而且，在一些实施例中，帧可以从输入流复制和/或重复，其中输入流和输出流共享相同的格式、最大位速率和/或分辨率。这会发生在期望的输出流与输入流相同的地方。在这种情况下，可以跳过重新编码，并且若干实施例可以简单地复制来自输入流的瞬时解码刷新(idr)帧。如上面所讨论的，在所述若干实施例中，结果所得的输出流可以是非hrd兼容的。

在用于减轻不能及时为实况边缘生成帧的风险的另一种技术中，接收到的媒体的帧可以可选地被扩展(250)。扩展帧可以包括在与给定帧的指派时间戳不同的时间将该给定帧包装到输出流中。依赖于以前的评估，会发生不同的帧扩展。在媒体的馈送和/或接收中检测到间隙的情况下，可以在生成输出流时扩展当前帧。在利用作为实况编码服务器的一部分的重新包装应用的实施例中，重新包装应用可以在将帧重新包装到输出流期间执行扩展。为了减少视频中的视觉伪影和/或感知停顿，重新包装应用可以在多个帧上散布若干较小的帧扩展，以便在多个步骤中补偿间隙。较小的扩展可以用来隐藏扩展不让流传输客户端观众看到。

所生成的输出流可以被提供(260)给流传输客户端。所生成的输出流可以处于不同的最大位速率，但每个位速率表示单个媒体呈现。因此，可以在具有不同最大位速率的若干流中向流传输客户端提供给定的媒体呈现。所生成的输出流的提供可以经由对来自所生成的输出流的片段的http请求来实现。

虽然以线性次序给出了过程200中给出的操作，但是各种实施例可以以不同的次序执行所述操作。例如，当接收到实况媒体时，可以持续地执行流的生成及其向客户端的提供。因此，在过程200中给出的操作的次序仅仅是示范性的并且可以作为用于从接收到的媒体的帧实况生成流的循环过程的一部分而被持续地执行。在讨论了由一些实施例的实况编码系统执行的过程的概述之后，下面的讨论将提供可以作为所述过程的一部分被执行的帧扩展和帧复制的若干示例。

帧扩展和帧复制的示例

如上面所讨论的，根据本发明的实施例的实况编码系统可以响应于被评估的网络和/或服务器条件来扩展帧和/或复制帧。帧扩展和/或帧复制可以补偿丢弃的输入帧、延迟的输入帧和/或编码系统负载。图3、图4、图5、图6和图7概念性地图示了根据本发明的实施例的帧扩展和帧复制的若干示例。上面提到的图中给出的示例是实况编码过程的抽象，实况编码过程被图示以示出帧复制和/或帧扩展的效果。根据本发明的实施例的实况编码系统将包括未在图3、图4、图5、图6和图7的示例中示出的附加细节、部件和/或功能。用于时间戳、帧号和/或帧持续时间的具体数字是为了示范目的给出的。本发明的实施例不限于图3、图4、图5、图6和图7中给出的具体值，并且可以根据实况编码操作的需要结合宽范围的可能时间戳、帧号和/或帧持续时间。而且，虽然在下面的附图中仅示出了单个输出流，但是本发明的实施例通常利用变化的编码参数生成处于变化的最大位速率的多个输出流。

图3概念性地图示了根据本发明的实施例的、扩展帧以补偿丢失的输入帧的实况编码系统的示例。如图所示，实况编码系统300在接收输入流310并生成输出流360。在图3所示的示例中，实况编码系统300的实况编码处理在输入流310的持续接收和输出流360的生成期间执行。输入流310可以是上面讨论的输入流和/或媒体中的任何一个。实况编码系统360可以经由上面讨论的任何技术将生成的输出流360提供给流传输客户端(未示出)。技术诸如接收http请求并发送来自输出流的片段。

如图所示，输入流310包括具有识别出的时间戳和持续时间的若干帧。帧可以包括媒体的部分，诸如帧视频。时间戳由缩写“ts”指示。持续时间由缩写“d”指示。如前面所提到的，图3中所示的值是示范性的。本发明的实施例可以根据需要接收并处理各种不同的时间戳和持续时间值，以支持实况编码。帧5320具有等于5的时间戳值和等于1的持续时间值。

实况编码系统300期望在指定的时间从输入流310接收帧。当在指定的时间没有接收到帧时，实况编码系统300可能无法及时地生成实况流传输客户端预期的用于实况边缘的输出流360。实况编码系统300可以使用如上面所讨论的各种测量来评估帧是否从输入流310丢失。诸如将由实况编码系统300维护的内部时钟与实况输入流310的接收到的帧的时间戳进行比较。实况编码系统310还可以包括在扩展帧之前必须满足的、用于丢失帧的阈值。实况编码系统310包括在选择扩展帧以补偿至少两个帧的间隙之前两个丢失帧的阈值。不同的实施例可以包括不同阈值，不同阈值可以基于不同的帧数和/或不同的阈值测量，诸如在一段时间上丢失的帧而不是依次丢失的帧。视频的实况编码固有地是资源密集型过程，因此各种实施例可以结合评估编码条件(诸如编码系统负载、客户端断断续续、网络带宽稳定性、视频质量以及会影响视频的实况编码的其它度量和/或条件)利用各种阈值。如上面所讨论的，在本发明的不同实施例中，可以计算帧的具体计数及其输送并将其与帧计数和时间的不同阈值进行比较。此外，不同的实施例可以使用不同的度量来评估这种流传输条件、处理周期计数、用于对帧集合进行编码的时间基准、网络传输速率、输送和显示的帧速率以及视觉质量/保真度的各种测量。虽然本文没有提供具体的值，但是在不背离本发明的精神的情况下，可以根据需要利用不同的具体值(诸如低于24帧/秒的dip、超过某些伽马值的造成显示失败的视觉错误、每秒编码的帧等)，以实现本发明。

在各种不同情况下输入帧可能丢失，诸如(但不限于)当在输入流提供者与实况编码系统之间的网络连接出现故障时、当在输入流中存在错误时，和/或实况编码系统的内部错误。如图所示，输入流310丢失了帧330和帧340。实况编码系统300可以通过将帧8350的时间戳与帧5320的时间戳以及由实况编码系统300维持的内部时钟相比较来检测这个间隙。一旦满足丢失帧阈值，实况编码系统300就可以扩展帧，以补偿帧中的间隙。各种实施例可以使用不同的阈值方案，包括上面讨论的那些中的任一个。

如图所示，实况编码系统300在生成输出流360时扩展来自输入流310的帧5320。扩展帧370被扩展为具有等于3的持续时间值，以便覆盖丢失的帧330和340。扩展帧370将在实况流传输客户端请求时可用，并保留支持不间断实况流传输所需的实况边缘。但是，如果过度使用，那么扩展帧持续时间会导致视觉伪影。

图4概念性地图示了有助于隐藏帧扩展效果的扩展帧持续时间的备选方法。如图所示，实况编码系统400从输入流410生成输出流460。输入流410丢失了帧430和440。为了补偿这个间隙，实况编码系统400可以扩展帧5420和帧8450的持续时间，并且还调整帧8450的时间戳值。如输出流460所示，扩展帧5470已经被扩展为具有持续时间值2，并且扩展帧8480已经被扩展为具有持续时间值2。但是，用于扩展帧8470的时间戳已经被调整为7，使得扩展帧8480将在扩展帧5470之后立即可用。通过在丢失帧周围分布扩展，实况编码系统400可以隐藏由帧持续时间扩展所造成的视觉伪影中的一些。

图5概念性地图示了根据本发明的实施例的、扩展帧以补偿延迟的输入帧的实况编码系统的示例。如图所示，实况编码系统500从输入流510生成输出流560。但是，帧延迟530和540导致帧6550迟到。实况编码系统500可以检测帧延迟并使用帧持续时间扩展进行补偿。与以前的示例不同，将不会有丢失的帧。实况编码系统500生成输出流560，输出流560包括具有扩展到3的持续时间的扩展帧5和具有调整为8的时间戳值的帧6580。扩展帧570将在由实况流传输客户端请求时可用并保留支持不间断的实况流传输所需的实况边缘。与上面讨论的示例类似，如果过度使用，那么扩展帧持续时间会导致视觉伪影。

图6概念性地图示了扩展帧持续时间以补偿帧延迟的备选方法，这有助于隐藏帧扩展的效果。如图所示，实况编码系统600从输入流610生成输出流660。如上所述，在630和640处发生帧延迟。为了补偿这个延迟，实况编码系统600可以扩展帧5620和帧6650的持续时间，并且还调整帧6650的时间戳值。如输出流660中所示，扩展帧8670已经被扩展为具有持续时间值2，并且扩展帧8已经被扩展为具有持续时间值2。但是，用于扩展帧8670的时间戳已被调整为7，使得扩展帧8670将在扩展帧5670之后立即可用。通过在延迟的帧周围分布扩展，实况编码系统400可以隐藏由帧持续时间扩展造成的视觉伪影中的一些。

本发明的实施例不限于上面关于图3、图4、图5和图6讨论的帧扩展技术。各种实施例可以在不同的情况下利用如图3和图5中所示的帧持续时间的顺序扩展和/或如图4和图5中所示的帧持续时间的分散扩展。此外，扩展帧持续时间不限于由于丢失和/或延迟的帧而被执行。

实况编码服务器通常是非常强大和昂贵的机器，其需要显著的计算能力来编码满足实况边缘要求的实况流。但是，即使是强大的服务器也会变得过载，而不太强大的服务器更是如此。特别地，重新编码编码帧可能是对服务器资源的严重消耗。图7概念性地图示了根据本发明的实施例的、扩展帧以补偿服务器负载的实况编码系统的示例。如图所示，实况编码系统700接收输入流710并生成输出流760。在图7所示的示例中，实况编码系统700的实况编码过程在输入流710的持续接收和输出流760的生成期间被执行。实况编码系统700被示为处于负载740之下。为了补偿这个负载，实况编码系统700可以在编码域中从编码的输入流复制帧。

如图所示，实况编码系统700接收编码帧4720和编码帧5730。实况编码系统700在生成编码的输出流750时复制这些帧。用于复制帧4760和复制帧5770的帧字段可能必须被调整以便考虑新的帧上下文。但是，与重新编码操作相比，这些调整可以要求显著更少的处理资源。复制帧4760和复制帧5770具有与编码帧4720和编码帧5730相同的持续时间值和时间戳值。

本发明的实施例不限于上面在图7中概念性示出的示例中讨论的具体帧复制技术。各种实施例可以利用具有各种格式的输入流(诸如原始、未编码的输入流)进行的帧复制和/或重复。而且，本发明的实施例不限于仅在服务器负载时间期间执行帧复制和/或帧重复。例如，作为持续编码过程的一部分，本发明的一些实施例可以执行编码的帧复制，以维持高效的实况编码，而不必等到服务器负载达到临界水平。所述一些实施例可以在不太强大的实况编码服务器上使用。

mpeg-dash实况编码

mpeg-dash(iso/iec23009-1)是用于经互联网流传输多媒体内容的标准。mpeg-dash由运动图像专家组(mpeg)开发。mpeg已经负责开发以前的多媒体标准，包括mpeg-2、mpeg-4、mpeg-7、mpeg-21等。mpeg-dash提供使用http的自适应分段媒体输送。mpeg-dash规范仅定义mpd和片段格式。值得注意的是，在mpeg-dash标准中未定义mpd的输送和包含片段的媒体编码格式，以及用于获取、自适应启发和播放内容的客户端行为。

图8概念性地图示了根据本发明实施例的、用于利用mpeg-dash的实况编码系统的示例性数据流图。图8包括媒体馈送数据810、实况编码系统820、http请求830、所请求的流片段840、流传输客户端850以及媒体呈现描述860。虽然未示出，但是媒体馈送数据810、http请求830、所请求的流片段840和媒体呈现描述860可以经通信网络发送。通信网络可以包括(但不限于)互联网。

如图所示，实况编码系统820正在接收媒体馈送数据810。媒体馈送数据810可以包括至少上面讨论的接收到的媒体的类型。实况编码系统820可以从接收到的媒体馈送数据810生成输出流。在从接收到的媒体馈送数据810生成输出流期间，基于对媒体馈送数据810的接收速率的评估、实况编码系统820上的负载水平、支持媒体馈送数据810的传输的通信网络中的负载水平、媒体馈送数据810中的间隙，和/或由实况编码系统820生成流时的间隙，实况编码系统820可以复制来自媒体馈送数据810的帧和/或扩展来自媒体馈送数据810的帧。

实况编码系统820还接收http请求830。响应于http请求，实况编码系统820提供所请求的流片段840。http请求830可以包括来自所生成的输出流之一的具体分段的字节范围请求。实况编码系统820可以包括多个部件，包括单独的实况编码服务器和http服务器。http服务器可以支持与客户端的媒体片段和请求的http通信。而且，http服务器可以利用基于http的内容分发网络(cdn)来辅助媒体片段向流传输客户端850的输送。

mpeg-dash使用媒体呈现描述(mpd)来向客户端提供结构良好的xml清单，该清单描述可以经由对流片段的http请求来访问的若干自适应位速率流。每个mpd与可经由若干所描述自适应位速率流来查看的单个媒体呈现对应。mpd描述可访问的媒体片段和用于可访问的媒体片段的对应定时。mpd是分层数据模型，其包括(从层次结构的顶部向下)媒体呈现、时段、适配集、表示和片段。媒体呈现可以包括实况广播、实况流、实况活动和/或预先录制的媒体呈现。媒体呈现可以被拼接和/或可以包括若干时段。默认情况下，时段是不连接的并且可以在它们之间拼接广告时段，而不损失功能。时段可以包括若干适配集。适配集可以包括关于同一呈现的不同视角，诸如来自实况体育赛事的不同相机。此外，不同的适配集可以包括不同的格式，诸如音频适配集和视频适配集。在每个适配集内，可以包括若干表示。表示支持从相同的呈现中选择不同的带宽和/或最大位速率水平。因此，mpeg-dash的客户端可以通过在带宽和/或客户端负载允许的情况下切换到不同的表示来使用自适应位速率流传输。每个表示包括可以经由http请求的媒体的片段。http请求在与每个片段相关联的预格式化的url上被接收。

图9概念性地图示了来自mpeg-dash的示例媒体呈现描述mpd数据模型。如图所示，媒体呈现910包括若干时段915-925。时段915-925各自包括不同的时段开始时间。开始时间为100秒的时段920被扩张，以示出若干包括的适配集925-930。适配集1925包括来自媒体呈现910的相机1的视频。适配集2930包括用于媒体呈现910的音频。适配集3935包括来自媒体呈现910的相机2的视频。适配集1925已被扩张，以示出表示1940和表示2945。表示1940是用于适配集1925的500kb/s表示，而表示2945是用于适配集1925的250kb/s表示。在表示1940当中的是初始化片段100和媒体片段955-965。这些片段由流传输客户端经由http请求，以接收其中包含的媒体。

值得注意的是，图9中所示的椭圆的实例指示可能有附加的时段、适配集、呈现以及片段。图9中给出的示例mpd仅仅是来自由本发明的各种实施例支持的任何种类的配置的一个可能示例。例如，本发明的不同实施例可以支持与图9所示的实施例中为了示范性目的而提供的那些位速率不同的许多其它最大位速率。

实况编码服务器体系架构

根据本发明的实施例的实况编码服务器1000的体系架构在图10中示出。实况编码服务器1000包括与非易失性存储器1030、易失性存储器1020和网络接口1040通信的处理器10。在所示实施例中，非易失性存储器包括输入数据处理应用1050、解复用器应用1055、重新包装器应用1060、mpd组合应用1065、mpd生成应用1070、http请求应用1075、音频解码器应用1080、音频编码器应用1085、视频解码器应用1090以及视频编码器应用1095。值得注意的是，实况编码服务器1000是mpeg-dash格式的实况编码服务器，其准备用于流的mpd文件并通过http请求向流传输客户端提供输出流的片段。其它实施例可以利用不同的格式并且根据需要包括不同的应用，以支持所述不同格式。

输入数据处理应用1050从网络接口1040接收输入流。输入流可以包括(但不限于)视频内容、媒体呈现、仅视频的文件、仅音频的文件、体育赛事、web流和/或mpeg-dash标准流的实况流。输入数据处理应用1050可以执行附加功能，包括输入流的识别。可以使用输入流中包含的元数据和/或输入流的特点和参数的评估来执行识别。

解复用器应用1055从输入流中解复用各个基本流。例如，解复用器应用1055可以打断输入流内的音频、视频和/或字幕流。解复用的流可以在由其它应用执行的后续操作中被分析、解码和重新编码。

重新包装器应用1060可以作为整体实况编码服务器操作的一部分执行重新编码、重复和帧扩展操作。重新包装器应用1060可以根据需要从输入数据处理应用1050、解复用器应用1055、网络接口1040和/或实况编码服务器1000的任何其它部件接收输入流，以重新包装流。重新包装器应用1060可以根据需要利用视频解码器应用1090和视频编码器应用1095将接收到的媒体的传入实况帧重新编码为若干输出流。在重新编码操作期间，重新包装器应用1060可以根据若干测量来评估实况编码服务器1000的网络和/或服务器负载水平。基于这些评估，重新包装器应用1060可以重复传入的帧，以降低服务器负载水平和/或扩展某些帧，以补偿传入的网络带宽中的预期下降。重新包装器应用1060可以通过操纵帧的时间代码和/或时间戳来扩展帧，以增加其在输出流中的持续时间。重新包装器应用1060可以向mpd组合应用1065和/或mpd生成应用1070提供输出流的重新包装的、重新编码的、重复的和/或扩展的帧，以便准备好随后利用http请求应用1075向客户端流传输。

mpd组合应用1065将由重新包装器应用1060生成的多个输出流组合成单个呈现。mpd组合应用1070可以生成用于组合呈现的mpd文件。如上面所讨论的，mpd文件可以描述媒体呈现的时段、适配集、表示和片段。mpd组合应用1070根据所生成的输出流的特点生成mpd文件。这些特点将根据由重新包装器应用1060执行的操作而变化。mpd文件通常最初被请求并且提供给流传输客户端，以便发起mpeg-dash流传输会话。

http请求应用1075根据所述http请求处理http请求和服务器媒体片段。http请求应用1075可以通过网络接口1040与流传输客户端进行通信。在一些实施例中，http请求应用1075被托管在与实况编码服务器分开的http服务器中。

非易失性存储器包括音频解码器应用1080、音频编码器应用1085、视频解码器应用1090和视频编码器应用1095。虽然非易失性存储器1030仅包括单个视频解码器应用1090和单个视频编码器应用1095，但是其它实施例可以包括多个视频编码器和视频解码器应用。而且，一些实施例可以对每个输出流使用应用的集合，以便让分开的重新包装器、解码器和编码器应用生成每个不同的输出流。

在若干实施例中，网络接口1040可以与处理器1010、易失性存储器1020和/或非易失性存储器1030通信。存储在实况编码服务器1000的非易失性存储器1030中的应用的上述讨论讨论了支持实况编码服务器1000的一个示例性应用集合。本发明的其它实施例可以利用具有下面讨论的功能的多个服务器，这些功能根据需要分布在多个服务器和/或位置上以实现本发明。此外，下面讨论的应用可以组合成一个或多个应用，并且根据需要实现为软件模块，以实现本发明。例如，下面讨论的应用可以备选地被实现为驻留在实况编码服务器1000上的单个应用的模块。而且，在示出单个应用的情况下，其它实施例可以利用专用于类似功能的多个应用。

上面讨论的各种过程可以在单个离散的服务器上实现。备选地，它们可以各自被实现为任何数量的物理、虚拟或云计算设备上的共享和/或离散的服务器。具体而言，根据本发明的一些实施例的实况编码系统可以包括单独的(一个或多个)编码服务器和(一个或多个)http服务器。本领域普通技术人员将认识到的是，各种实现方法可以被用来实现本发明的实施例的过程服务器。

虽然上面的描述包含本发明的许多具体实施例，但是这些不应当被解释为对本发明的范围的限制，而是作为其一个实施例的示例。因而，本发明的范围不应当由所示实施例而是由所附权利要求及其等同物来确定。