CN110785978B - 用于直播上行链路自适应流传输的设备及方法 - Google Patents

Abstract

提供了由客户端执行的用于向服务器上行流传输直播媒体馈送的方法。该方法包括：客户端与服务器建立传输层连接；向服务器传送具有头部和主体的HTTP请求消息；以及，在生成与所述直播媒体馈送相对应的媒体数据时，在传送缓冲区中存储媒体数据。头部不指示主体的尺寸。将质量设置用于生成媒体数据。传送主体包括：1)向服务器传送媒体数据的至少一部分；2)从传送缓冲区去除媒体数据的所述至少一部分；3)确定客户端是否应该修改被用于生成媒体数据的质量设置；以及4)重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

Description

用于直播上行链路自适应流传输的设备及方法

技术领域

所公开的是与使用超文本传输协议(HTTP)的直播上行链路自适应流传输有关的实施例。

背景技术

最常见的用于上行链路流传输(即，从客户端到服务器的流传输)的流传输协议是实时消息收发协议(RTMP)，其属于Adobe(参见www.adobe.com/devnet/rtmp.html)。RTMP最初是为从服务器到客户端的Flash视频开发的。但是如今RTMP大多用于上行链路流传输。RTMP将传输控制协议(TCP)用于可靠的上行链路流传输。RTMP是相对于HTTP的完整备选实现。RTMP流可以通过RTMP协议处理机方案(rtmp://)识别，从而使rtmp：//ex.com/live.swf形式的URL可以被应用解释。

RTMP具有若干缺点。例如，因为该规范不是由开放的标准化主体或团体控制，所以不存在用于添加视频、音频或隐藏字幕(closed-captioning)方案的规则或方式。

发明内容

RTMP的另一缺点是其使用不如HTTP广泛。因此，使用HTTP执行直播上行链路流传输将是有益的。HTTP的另外的优点是：可以重用所有的HTTP专用的安全功能，如HTTPS或源认证。

C.Lottermann等人的“Network-Aware Video Level Encoding for UplinkAdaptive HTTP Streaming”，2015IEEE International Conference on Communications(ICC)(“Lottermann”)，描述了使用HTTP的上行链路流传输。然而，在Lottermann所公开的系统中，视频打包器(packager)与HTTP服务器共处一处，该HTTP服务器用于接收来自远程HTTP客户端的请求并响应于请求向远程HTTP客户端流传输视频。这种实现将HTTP客户端置于基础架构之中而将HTTP服务器放在客户端装置侧(即，相机侧)。

Lottermann所公开的系统具有的问题是：想要产生上行链路视频流的许多用户被防火墙或其他安全功能(例如，使用网络地址转换器(NAT)结合动态IP地址分配，如动态主机配置协议(DHCP))屏蔽和保护。例如，家庭网络中的装置通常被防火墙屏蔽，防火墙不允许家庭网络外部的客户端建立到该装置的TCP连接(即，(例如，使用TCP连接或HTTP连接)从外部装置到达家庭网络内部的装置是被禁止的)。这保护了装置不受家庭网络外部的黑客攻击。这种缺点在移动环境中也存在。通常，运营商屏蔽和保护移动装置(例如，智能电话)使其与面向互联网的业务隔开，以保护移动装置免受黑客攻击、拒绝服务、以及垃圾邮件攻击(spamming attack)的影响。仅用户(即，移动装置)可以发起或建立与服务器的会话(而非其他方式)。

本公开描述了克服该缺点的实施例。实施例提供了新的直播上行链路视频方案，其中HTTP客户端位于客户端装置侧(即，相机侧)，这与已经提出的HTTP服务器位于相机侧相反。这克服了上述防火墙问题，同时仍然能够使用现有的且可广泛获得的HTTP库和基础架构。基于TCP的HTTP提供可靠且弹性的传输机制。所述弹性保证了会话吞吐量尽可能快地被调整至可获得的链路比特率。直播源持续地产生媒体帧，这些媒体帧应该尽可能快地被上传。

在本文描述的实施例中，在客户端装置上运行的(或位置相对靠近客户端装置的)HTTP客户端使用HTTP请求建立到HTTP获取(ingest)服务器的连接(例如，HTTPS连接)。于是，直播上行链路媒体(音频和/或视频)在HTTP请求的HTTP主体内提供。HTTP客户端可以使用HTTP 1.0原则来将媒体内容直接传递(pipe)到HTTP主体，或其可以使用HTTP 1.1分块传输编码。HTTP分块传输编码允许客户端将已建立的TCP连接重用于后续的HTTP事务(持久TCP连接)。因此，本文所公开的是涉及将HTTP请求主体用于从HTTP客户端到HTTP服务器的直播上行链路流的实施例。这能够利用(leveraging)HTTP会话的可靠性和弹性以将传送比特率调整至可获得的链路比特率，等等。

实施例提供新的速率自适应方案，该速率自适应方案监测弹性速率自适应方案的进度，且保证客户端发送缓冲区正在时延约束之内上传直播视频馈送和/或没有增加太多抖动。

实施例提供能够接受新的直播视频方案的新的HTTP服务器功能。在实施例中，客户端可以在HTTP请求内启动直播上行链路视频。于是，HTTP服务器可以(例如，在接收数据块时且在接收所有块之前)将接收到的数据块传递给后处理功能。

下文描述的实施例说明如何结合分段MP4(fMP4)和HTTP分块传输编码来使用HTTP以执行直播上行链路流传输。实施例提供比特率自适应直播上行链路方案，其能够利用TCP层重传(即，无需单独的UDP重传服务器)、速率控制、拥塞避免原则，但仍然可以执行媒体比特率自适应。

实施例可以用作诸如MPEG传输流(MPEG2-TS)、MPEG媒体传输(MMT)或专门的RTMP之类的方法的备选。

还公开了涉及将现有的HTTP服务器扩展至启动将来自请求的任何接收数据块传递给类似去抖动缓冲区和ABR转码器/打包器等任何后处理功能(即，接收到来自请求的所有数据块之前启动)的实施例。

因此，在一个方面，提供了由客户端设备(“客户端”)执行的用于向服务器上行流传输由媒体源产生的直播媒体(音频和/或视频)馈送(例如，相机)的方法。在一个实施例中，该方法包括：客户端与服务器建立传输层连接(例如，TCP连接)。该方法还包括：客户端通过传输层连接向服务器传送包括头部和主体的超文本传输协议(HTTP)请求消息，其中，HTTP请求消息的头部不指示HTTP请求消息的主体的尺寸。该方法还包括：在生成与直播媒体馈送相对应的媒体数据时，客户端在传送缓冲区中存储该媒体数据，其中，质量设置被用于生成媒体数据。通过传输层连接向服务器传送HTTP请求消息的主体包括：1)客户端通过传输层连接向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分；2)客户端从传送缓冲区去除该媒体数据的所述至少一部分；3)客户端确定该客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置；以及4)客户端重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

在一些实施例中，媒体源是相机。在一些实施例中，相机是客户端的集成部件；在其他实施例中，相机远离客户端(例如，通过诸如蓝牙连接之类的链路连接至客户端的无人机上的相机)。在实施例中，触发基于指定持续时间的调度，以及，由于检测到已经经过所述持续时间，客户端检测到触发。

在一些实施例中，该方法还包括：客户端使用第一质量设置来编码由媒体源生成的第一组媒体帧，以产生第一组经编码的媒体帧。在传送缓冲区中存储的媒体数据包括第一组经编码的媒体帧；以及，传送HTTP请求消息的主体的步骤还包括：客户端传送第一编解码器配置信息，其中第一编解码器配置信息包括指示第一质量设置的信息。该方法还包括：客户端监测在传送缓冲区中存储的数据量；客户端确定在传送缓冲区中存储的数据量超过门限；以及，由于确定在传送缓冲区中存储的数据量超过所述门限，客户端使用第二质量设置来编码由媒体源生成的第二组媒体帧，以产生第二组经编码的媒体帧。该方法还包括：客户端在传送缓冲区中存储与直播媒体馈送相对应的另外的媒体数据，其中，另外的媒体数据包括所述第二组经编码的媒体帧。传送HTTP请求消息的主体的步骤还包括：客户端传送第二编解码器配置信息，其中，第二编解码器配置信息包括指示第二质量设置的信息。

在一些实施例中，该方法还包括：客户端编码由媒体源生成的第一组媒体帧，以产生第一组经编码的媒体帧，其中，在传送缓冲区中存储的媒体数据包括第一组经编码的媒体帧；客户端监测在传送缓冲区中存储的数据量；客户端确定在传送缓冲区中存储的数据量超过门限；以及，由于确定在传送缓冲区中存储的数据量超过所述门限，客户端从传送缓冲区丢弃第一组媒体帧的至少一个子集，使得被丢弃的帧不被传送给服务器。在一些实施例中，所述传送缓冲区存储媒体段，所述媒体段包括媒体帧的所述子集且还包括关于媒体帧的所述子集的元数据，并且，从所述传送缓冲区丢弃媒体帧的所述子集的步骤包括：从所述传送缓冲区丢弃所述媒体段，使得所述媒体段不被传送给服务器。

在一些实施例中，该方法还包括：客户端获得由媒体源生成的未压缩的视频帧；客户端编码未压缩的视频帧，以产生经编码的视频帧；客户端生成包括以下项的视频段：i)经编码的视频帧，以及ii)关于经编码的视频帧的元数据；以及，客户端在传送缓冲区中存储所述段。在实施例中，所述视频段是以下之一：i)ISO-BMFF视频段，以及ii)公共媒体应用格式(CMAF)视频段。

在一些实施例中，直播馈送可以由用于直播分配的接收实体(服务器)进一步处理。在实施例中，客户端通过传输层向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分包括：传送包括当前在传送缓冲区中存储的媒体数据的至少一部分的数据块。在实施例中，确定客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置基于：传送缓冲区级别和/或传送缓冲区级别随时间的改变(例如，缓冲区级别梯度)。

在另一方面，提供了由服务器执行的用于从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送的方法。所述方法包括：通过与客户端的传输层连接(例如，TCP连接)，接收超文本传输协议(HTTP)请求消息的HTTP头部，所述HTTP请求消息包括主体。HTTP头部不指示HTTP请求消息的主体的尺寸。所述方法还包括：在接收HTTP头部之后，接收HTTP请求消息的主体。接收HTTP请求消息的主体包括：从HTTP客户端接收第一数据块；从HTTP客户端接收第二数据块；以及，在接收第一数据块之后且在接收第二数据块之前，将第一数据块转发给用于分配流视频的分配系统。

在另一方面，提供了用于将由媒体源产生的直播媒体(音频和/或视频)馈送上行流传输给服务器的(例如，在移动装置或用户设备(UE)上的)HTTP客户端。HTTP客户端适于：与服务器建立传输层连接(例如，TCP连接)；通过传输层连接向服务器传送包括头部和主体的超文本传输协议(HTTP)请求消息，其中，HTTP请求消息的头部不指示HTTP请求消息的主体的尺寸；以及，在生成与直播媒体馈送相对应的媒体数据时，在传送缓冲区中存储媒体数据。将质量设置用于生成媒体数据。通过传输层连接向服务器传送HTTP请求消息的主体包括：1)客户端通过传输层连接向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分；2)客户端从传送缓冲区去除媒体数据的至少一部分；3)客户端确定所述客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置；以及4)客户端重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

在另一方面，提供了用于将由媒体源产生的直播媒体(音频和/或视频)馈送上行流传输给服务器的(例如，在移动装置或用户设备(UE)上的)HTTP客户端。HTTP客户端包括：传输模块，所述传输模块被配置为：与服务器建立传输层连接(例如，TCP连接)；传送模块，所述传送模块被配置为：通过传输层连接向服务器传送包括头部和主体的超文本传输协议(HTTP)请求消息，其中，HTTP请求消息的头部不指示HTTP请求消息的主体的尺寸；以及，数据存储模块，所述数据存储模块被配置为：在生成与直播媒体馈送相对应的媒体数据时，在传送缓冲区中存储媒体数据。将质量设置用于生成媒体数据。通过传输层连接向服务器传送HTTP请求消息的主体包括：1)客户端通过传输层连接向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分；2)客户端从传送缓冲区去除媒体数据的至少一部分；3)客户端基于传送缓冲区级别和/或传送缓冲区级别随时间的改变(例如，缓冲区级别梯度)，确定客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置；以及4)客户端重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

在另一方面，提供了用于将由媒体源产生的直播媒体(音频和/或视频)馈送上行流传输给服务器的(例如，在移动装置或用户设备(UE)上的)HTTP客户端。HTTP客户端包括：接收器；传送器；数据存储系统；以及，包括处理器的数据处理设备。所述数据处理设备被耦接至数据存储系统、传送器、以及接收器，并且，所述数据处理设备被配置为：与服务器建立传输层连接(例如，TCP连接)；通过传输层连接向服务器传送包括头部和主体的超文本传输协议(HTTP)请求消息，其中，HTTP请求消息的头部不指示HTTP请求消息的主体的尺寸；以及，在生成与直播媒体馈送相对应的媒体数据时，在传送缓冲区中存储媒体数据。将质量设置用于生成媒体数据。通过传输层连接向服务器传送HTTP请求消息的主体包括：1)客户端通过传输层连接向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分；2)客户端从传送缓冲区去除媒体数据的至少一部分；3)客户端确定所述客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置；以及4)客户端重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

在另一方面，提供了用于从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送的HTTP服务器。所述HTTP服务器适于：通过与客户端的传输层连接(例如，TCP连接)，接收超文本传输协议(HTTP)请求消息的HTTP头部，所述HTTP请求消息包括主体。HTTP头部不指示HTTP请求消息的主体的尺寸。所述HTTP服务器还适于：在接收HTTP头部之后，接收HTTP请求消息的主体。接收HTTP请求消息的主体包括：从HTTP客户端接收第一数据块；从HTTP客户端接收第二数据块；以及，在接收第一数据块之后且在接收第二数据块之前，将第一数据块转发给用于分配流视频的分配系统。

在另一方面，提供了用于从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送的HTTP服务器。所述HTTP服务器包括：第一接收模块，所述第一接收模块被配置为：通过与客户端的传输层连接(例如，TCP连接)接收超文本传输协议(HTTP)请求消息的HTTP头部，所述HTTP请求消息包括主体，其中，HTTP头部不指示HTTP请求消息的主体的尺寸；第二接收模块，所述第二接收模块被配置为，在通过第一接收模块接收HTTP头部之后，接收HTTP请求消息的主体。接收HTTP请求消息的主体包括：从HTTP客户端接收第一数据块；从HTTP客户端接收第二数据块；以及，在接收第一数据块之后且在接收第二数据块之前，通过转发模块将第一数据块转发给用于分配流视频的分配系统。

在另一方面，提供了用于从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送的HTTP服务器。所述HTTP服务器包括：接收器；传送器；数据存储系统；以及，包括处理器的数据处理设备，其中，所述数据处理设备被耦接至数据存储系统。并且，所述数据处理设备被配置为：通过与客户端(102)的传输层连接(例如，TCP连接)接收超文本传输协议(HTTP)请求消息的HTTP头部，所述HTTP请求消息包括主体，其中，HTTP头部不指示HTTP请求消息的主体的尺寸；以及，在接收HTTP头部之后，接收HTTP请求消息的主体。接收HTTP请求消息的主体包括：从HTTP客户端接收第一数据块；从HTTP客户端接收第二数据块；以及，在接收第一数据块之后且在接收第二数据块之前，将第一数据块转发给用于分配流视频的分配系统。

在下文描述上述和其他实施例。

附图说明

被并入本文且形成说明书的一部分的附图示出各种实施例。

图1示出根据一些实施例的网络架构。

图2示出根据一些实施例的被分成段的媒体流。

图3示出根据一些实施例的网络架构。

图4是根据一些实施例示出缓冲区尺寸和编码质量之间的关系的图。

图5是示出根据一些实施例的过程的流程图。

图6是示出根据一些实施例的过程的流程图。

图7是示出根据一些实施例的过程的流程图。

图8是示出根据一些实施例的HTTP客户端的功能模块的图。

图9示出根据一些实施例的HTTP服务器的功能模块的图。

图10是根据一些实施例的HTTP客户端的框图。

图11是根据一些实施例的HTTP服务器的框图。

具体实施方式

图1示出示例性实施例的端到端架构。如图所示，客户端设备102(或简称为“客户端102”)与包括HTTP服务器106(也被称作获取服务器)的媒体处理单元104通信。这形成供应链路(也被称为“获取链路”)，即，从客户端102(即，媒体源)到媒体处理单元104(即，媒体池(media sink))的链路。媒体处理单元104还可以包括转码器-打包器108(例如，自适应比特率(ABR)转码器)。如由线107所指示的，HTTP服务器106(入口)可以与转码器-打包器108(出口)解耦；即，在一些实施例中媒体处理单元104可以是单个物理单元，而在一些实施例中单元104可以包括位于分离的物理装置上的服务器功能和转码器-打包器功能。转码器-打包器108可以与内容分配网络(CDN)110通信，内容分配网络(CDN)110进一步向最终用户接收器112转发经打包的媒体。转码器-打包器108、CDN 110、以及接收器112构成分配系统。

虽然在全文中使用术语相机，但应了解，也可以使用任意的媒体源(例如，麦克风)。

实施例提供对从相机(例如，移动相机)到获取服务器的供应链路的改进。供应链路是到内容准备管道的上行链路。在概念上，这可以包括用于(例如，通过CDN使用DASH的)分配准备的筛选、ABR转码和打包功能；备选地，这些功能中的一些或全部可以与供应链路解耦并且可以被考虑为分配系统的一部分。

对于获取，提出了HTTP获取服务器方案。HTTP获取服务器106(与其他web服务器类似)监听输入。通常，TCP端口80或443被用于HTTP业务，尽管其他端口也是可能的。HTTP获取服务器106可以支持用于在建立安全的HTTPS连接之前对客户端进行授权和认证的安全功能。术语HTTP在此处与HTTPS作为同义语使用，因为所有HTTP事务都可以是安全的。

HTTP获取服务器106可以按照以下方式实现：在服务器接收完整的HTTP请求之前，(随着数据被接收)立即将数据转发给后续的处理功能(例如，ABR转码和打包)。这种行为与现有技术方案形成对比，现有技术方案可能需要HTTP服务器先接收HTTP请求的所有数据，然后触发对该请求的处理。在当前描述的实施例中，HTTP获取服务器106将接收到的任何HTTP块传递给后续的功能，如ABR转码器-打包器108。其他处理功能也可被用在该流水线结构中。例如，在ABR转码器之前还可以设置去抖动缓冲区(例如，图3中的去抖动缓冲区314)，以保证到ABR转码器的持续的输入。后处理功能可以与HTTP获取服务器106共处一处，或者可以是分布式的。如果是分布式的，则HTTP获取服务器106可以通过网络向后处理功能传递数据(例如，使用HTTP协议或其他协议来传递)。

在获取之后，ABR转码器和打包器功能于是准备用于分配的内容。转码参数可以受客户端102影响，且可以取决于从客户端到获取点的上行链路质量。

HTTP获取服务器106可以通过处理接收到的HTTP请求(例如，其使用分块分发或无约束的主体尺寸)的主体部分来获取视频。如果使用无约束的主体尺寸，则客户端102可以终止TCP连接以终止上传。如果使用分块分发，则客户端102可以停止上传并且将TCP连接重用于后续的事务(例如，用于改变视频的分辨率)。

图2示出可以如何划分视频以有利于HTTP获取服务器106执行获取。在所示出的示例中，客户端102正在产生经编码的视频帧的持续流。一个或多个这样的帧被集合到单个段(例如，公共媒体应用格式(CMAF)块)(例如，段210、212、214、216)。不需要CMAF块包含内帧(intra-frame)。如图所示，CMAF块至少包含moof框(box)和mdat框。对于编解码器配置，在开始处添加初始化区段(segment)202(其包含moov框)。

如图2中所示，使用具有未限定长度的HTTP主体的HTTP 1.0类型的实现。另一种实现将是使用HTTP分块传输编码。要注意，(例如，如HTTP 1.1规范所定义的)HTTP块可以包含一个或多个段(或CMAF块)。而且，一个段可以被划分成一个或多个HTTP块。HTTP块和段之间没有相关性，尽管在一些实施例中单个段被包含在单个HTTP块中。

图3示出根据一些实施例的客户端102和HTTP获取服务器106。

客户端102包括相机302，相机302以给定的帧速率提供持续的未压缩的帧序列。编码器304则采用未压缩的帧序列作为输入，并且产生经压缩的帧序列作为输出。经压缩的帧被构造在图片组(GOP)结构中。打包器306则收集一个或多个帧(具有GOP结构)并且将它们打包成段。段可以是CMAF块(例如，至少一个电影段框(moof)和一个媒体数据框(mdat)部分(以及可选的其他ISO-BMFF框))、ISO-BMFF段、或其他合适的结构。因此，每个段(其包含特定秒数的经压缩的媒体数据)具有特定的尺寸。打包器306则根据段内的经压缩的媒体数据量，以固定间隔输出段。

打包器306将段(例如，CMAF块)写进缓冲区308，由缓冲区监控器309监测缓冲区308。已经利用HTTP请求开启了HTTP连接的HTTP客户端310从缓冲区308接收段(例如，CMAF块)的字节，以创建该HTTP请求的主体。缓冲区监控器309监测上传过程，包括监视缓冲区308的耗尽(draining)。当缓冲区级别(或尺寸)增加(即，当缓冲区中的数据量到达门限)时，监控器309触发用于修改编码处理或采取其他措施的控制命令。如图所示，这可以采用编码器304、打包器306与监控器309之间的反馈回路的形式。HTTP客户端310向HTTP获取服务器106发送数据(例如，字节或HTTP块)。

客户端102也可以包括触发源311。在一些实施例中，触发源可以是调度器(例如，触发媒体馈送的启动和停止、或在指定的时间和/或按指定的间隔触发媒体馈送的开始)。在一些实施例中，触发源311可以来自缓冲区监控器309(例如，分辨率已经改变或期望分辨率改变的指示)。虽然触发源311被描绘为客户端102的一部分，但在一些实施例中触发源311也可以在客户端102的外部。

客户端102的模块302-311可以都被容纳在同一外壳之中，或者它们可以被容纳在分离的外壳中。例如，模块302-311可以都是移动通信装置(MCD)(例如，智能电话、平板计算机、膝上型计算机)的组件并且被容纳在MCD的外壳之中。作为另一示例，相机302可以是第一装置(例如，无人机)的一部分，而其他组件304-311可以是分离的装置(例如，智能电话、膝上型计算机、平板计算机)的部分。在这样的实施例中，可以通过无线链路可通信地连接相机302与编码器304。在一些实施例中，客户端102不包括打包器306。

在所示出的实施例中，HTTP获取服务器106包括HTTP服务器312和去抖动缓冲区314。

图4示出在一些实施例中缓冲区监控器309可以如何起作用的示例性说明。沿着纵轴，编码质量从“帧丢弃”到“低质量”(LQ)、“中等质量”(MQ)、以及“高质量”(HQ)。沿着横轴，缓冲区尺寸(以毫秒表示的在缓冲区308中存储的媒体时间)范围从0ms到800ms。如图所示，如果缓冲区308尺寸低于第一门限(此处是200ms)，则编码质量是HQ。随着缓冲区308填充至高于第一门限，但低于第二门限(此处是400ms)，则编码质量可能降低至MQ。随着缓冲区308进一步填充至高于第二门限，但小于第三门限(此处是600ms)，则编码质量可能进一步降低至LQ。随着缓冲区308填充至高于第三门限，则通过运用帧丢弃可能进一步降低编码质量。缓冲区监控器309监测缓冲区308的尺寸，以运用具体的编码策略来保持满意的直播流传输QoS参数。除了随着缓冲区308充满而降低编码的质量，也可以运用相反的处理(即，随着缓冲区尺寸减小而提高编码的质量)。在确定适当的编码参数时，缓冲区监控器309可以仅考虑缓冲区308的当前尺寸，或者可以考虑作为时间的函数的缓冲区尺寸并且将过去的缓冲区尺寸(或预测的将来的尺寸)纳入考虑。

如刚才描述的，高质量(HQ)、中等质量(MQ)、以及低质量(LQ)编码可以指会导致不同的可视质量的不同的编解码器配置。在一些实施例中，缓冲区监控器309可以修改编码器的量化参数，以改变经编码的视频的最终的比特率。

在一些实施例中，缓冲区监控器309持续地检查缓冲区308的缓冲区级别。当在向缓冲区308添加新的CMAF块的时刻缓冲区为空的情况下，监控器不采取任何动作。当缓冲区级别增加(按照经压缩的媒体时间指示地)时，监控器采取控制动作。第一动作可以是降低视频质量(例如，比特率)。当缓冲区级别仍然不降低时，监控器可以开始从缓冲区308丢弃帧或CMAF块或段。当丢弃各个帧时，仅仅应该丢弃来自GOP的末尾的帧。GOP是图片组，在GOP中从属图片(dependent pictures)的集合与可独立解码的帧组合在一起。

当每个段仅包含GOP的一部分(例如，几个帧(或ISO-BMFF术语中的样本)，少至单个视频帧)时，则缓冲区监控器309可以丢弃整个段。在如此操作时，缓冲区监控器309也可以考虑帧与帧之间的编码依赖性(使得丢弃帧不是随机的，而是有选择地和智能地执行的，以最小化质量损失)。(例如，如果段包含整个GOP)缓冲区监控器309还可以通过编辑(或重写)段来去除数据。例如，缓冲区监控器309可以从媒体数据框(mdat)中去除特定的视频帧的数据，并相应地缩减该框。轨道段运行框(Track Fragment Run box，简称trun)包含针对媒体数据框(mdat)中的每个样本(或视频帧)的条目，以及样本定时和样本尺寸。当从段中去除样本时，那么trun框需要被调整(例如，通过从trun框去除对应的样本条目并且使trun框的尺寸缩减对应的量)。在一些实施例中，段被构造成为使得其仅承载GOP的部分(而不是整个GOP)，从而使缓冲区监控器309可以容易地丢弃全部帧。当每个段仅包含一个帧时，那么缓冲区监控器309可以丢弃各个帧而无需重写任合段框。

假设我们具有以下GOP结构(GOP尺寸＝8帧)：I1，B1，P1，B2，P2，B3，P3，B4。在这种表示中，I1是可独立解码的图片，通常被称为I帧或内帧或关键帧或流中的随机访问点或流中的服务接入点；P图片是预测图片，其依赖于I帧或其他P帧；而B帧是双向预测帧，其依赖于至少两个另外的帧(可以是I、P或B)。其他的帧和从属帧的帧构造也是可能的。

当段包括单个帧(或图片)时，每个帧被打包进一个段。在该示例中，如果缓冲区监控器309应该丢弃帧，则应该首先丢弃帧B4，接着分别是帧B3、B2、B1、P3、P2、P1。

假设我们具有以下GOP结构(GOP尺寸＝8帧)：I1，P1，P2，P3，P4，P5，P6，P7。

在该示例中，缓冲区监控器309应该丢弃帧P7，然后是P6、P5、P4、P3、P2、P1。

在一些实施例中，帧丢弃考虑帧的相关性从左开始，从左向右进行。

当控制功能改变分辨率或其他编码结构参数(例如，如果序列参数集(SPS)或图片参数集(PPS)被修改)时)，那么HTTP客户端310需要停止一个上传且利用新的初始化部分来开始。

图5示出用于使用HTTP分块传输编码的持续上传的示例性调用流程。

HTTP客户端310利用请求和请求头部来开启HTTP会话。对于请求主体，HTTP客户端310从缓冲区308中读取，以上传HTTP块。每个HTTP块以块尺寸作为开始，其后跟随着该块。在一些实施例中，每个HTTP块与一个CMAF块相对应，但是技术上没有对齐要求。

因为HTTP请求仍在进行中，没有来自HTTP服务器312的HTTP响应。仅当HTTP客户端310利用零尺寸的HTTP块终止HTTP主体时，服务器才会利用类似“200OK”或“201Created(已创建)”这样的HTTP响应代码来响应。

在不使用分块转换编码的实施例(例如，不可使用分块转换编码的HTTP 1.0事务)中，HTTP客户端310则需要终止TCP连接。

(如所描绘的)在使用分块转换编码的实施例中，可以将现有的TCP连接重用于后续的HTTP事务。HTTP分块转换编码的优点是：在HTTP事务的开始，HTTP主体可以具有未知的尺寸，并且有可能重用已建立的TCP连接(持久TCP连接)。

在这个实施例中，因为HTTP客户端310从直播源(其正“无限地”产生数据)接收输入数据，需要外部事件来触发HTTP事务的终止。外部事件可以是直播馈送的结束或(例如，当缓冲区尺寸太大时由缓冲区监控器309触发的)直播馈送的分辨率改变。在分辨率改变的情况下，HTTP客户端310需要发送新的编解码器配置和初始化参数(例如，新的moov框)。在这种情况下，缓冲区监控器309(充当外部触发)将检测到对改变编解码器配置(例如，视频分辨率)、停止编码处理、以及触发HTTP客户端310停止HTTP块的上行链路业务(但是仍然保持已建立的TCP连接)的需求。随后，编码器处理应该再次启动(即，编码器304应该恢复产生视频帧)，但是利用不同的分辨率(或不同的编解码器配置或别的不同的编码参数)。首先，编码器304吐出初始化部分(例如，ISO BMFF moov框)，其包含编解码器配置。随后，编码器304经由打包器306将经压缩的视频帧提供到缓冲区监控器309的上传缓冲区。

在一个实施例中，在利用新的编解码器配置重新启动编码器304之前，HTTP客户端310或缓冲区监控器309从缓冲区308中丢弃所有数据。在另一实施例中，缓冲区308的旧数据被保留，以避免视频时线中的间隔。例如，缓冲区308中还未被上传的任何数据与视频序列中的帧相对应。

一些编码器可能不允许(例如，通过量化参数(QP)的改变)改变类似目标比特率这样的编码配置。在这种情况下，客户端利用已改变的编解码器配置参数重新启动编码器304，但是不产生新的初始化部分(例如，moov框)。

取决于使用实例，实施例支持外部触发的更多的实现。在类似自主飞行无人机或主体相机(body-cam)或监视相机的一些使用实例中，远程操作者可以触发分辨率改变(例如，用于提高质量或用于减少缓冲时延)。另一外部触发可以是经编程的调度，其中相机被编程为仅在特定的时间期间进行记录(即，启动时间触发和停止时间触发)或仅针对特定的持续时间进行记录(即，只有停止时间触发)。

存在来自服务器的(例如，用于拥塞控制和重传的)TCP层事务。

使用HTTP分块分发的针对上行链路直播流的示例HTTP请求如下：

在该示例中，HTTP POST在此处被用作用于指示上行链路流的HTTP方法。另一种方案可以是使用HTTP PUT。HTTP请求中的HTTP URL(此处是/upload/xyz/live-session1.mp4)指示上行链路流传输会话的目标信道。URL是账户专用的且被保护的，使得只有经授权的发送器可以上传。账户所有者授权允许哪些发送器发送数据。

在该示例中没有内容-长度(conent-length)HTTP头部存在，指示未知的HTTP主体尺寸。HTTP分块传输编码在头部中指示(即，“Transfer-Encoding：chunked(传输编码：分块)”)，指示该HTTP主体是HTTP块的序列。

图6示出过程600。过程600可以由例如客户端(例如，客户端设备102)执行。客户端与服务器建立传输层连接(例如，TCP连接)(步骤602)。客户端通过传输层连接向服务器传送包括头部和主体的超文本传输协议(HTTP)请求消息(步骤604)。HTTP请求消息的头部不指示HTTP请求消息的主体的尺寸。在生成与直播媒体馈送相对应的媒体数据时，客户端在传送缓冲区中存储媒体数据(步骤606)。将质量设置用于生成媒体数据。通过传输层连接向服务器传送HTTP请求消息的主体包括：1)客户端通过传输层连接向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分(步骤608)；2)客户端从传送缓冲区去除该媒体数据的至少一部分(步骤610)；3)客户端基于传送缓冲区级别和/或传送缓冲区级别随时间的改变(例如，缓冲区级别梯度)确定客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置(步骤612)；以及4)客户端重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止(步骤614)。

在一些实施例中，媒体源是相机，并且，在实施例中，相机可以是客户端的集成部分，或其可以远离客户端(例如，通过诸如蓝牙连接之类的链路被连接至客户端的无人机上的相机)。在一些实施例中，触发基于指定持续时间的调度，以及，由于检测到已经经过所述持续时间，客户端检测触发。

在一些实施例中，该过程还包括：客户端使用第一质量设置来编码由媒体源生成的第一组媒体帧，以产生第一组经编码的媒体帧。在传送缓冲区中存储的媒体数据包括第一组经编码的媒体帧。传送HTTP请求消息的主体的步骤还包括：客户端传送第一编解码器配置信息。第一编解码器配置信息包括指示第一质量设置的信息。该过程还包括：客户端监测在传送缓冲区中存储的数据量；以及，客户端确定在传送缓冲区中存储的数据量超过门限。该过程还包括：由于确定在传送缓冲区中存储的数据量超过门限，客户端使用第二质量设置来编码由媒体源生成的第二组媒体帧，以产生第二组经编码的媒体帧。该过程还包括：客户端在传送缓冲区中存储与直播媒体馈送相对应的另外的媒体数据。所述另外的媒体数据包括第二组经编码的媒体帧。传送HTTP请求消息的主体的步骤还包括：客户端传送第二编解码器配置信息。第二编解码器配置信息包括指示第二质量设置的信息。

在一些实施例中，该过程还包括：客户端编码由媒体源生成的第一组媒体帧，以产生第一组经编码的媒体帧。在传送缓冲区中存储的媒体数据包括第一组经编码的媒体帧。该过程还包括：客户端监测在传送缓冲区中存储的数据量；以及，客户端确定在传送缓冲区中存储的数据量超过门限。该过程还包括：由于确定在传送缓冲区中存储的数据量超过门限，客户端从传送缓冲区丢弃第一组媒体帧的至少一个子集，使得被丢弃的帧不被传送给服务器。

在一些实施例中，传送缓冲区存储包括媒体帧的子集且还包括关于媒体帧的子集的元数据的媒体段，并且，从传送缓冲区丢弃媒体帧的子集的步骤包括：从传送缓冲区丢弃媒体段，使得该媒体段不被传送给服务器。在一些实施例中，该过程还包括：客户端获得由媒体源生成的未压缩的视频帧；客户端编码未压缩的视频帧以产生经编码的视频帧；客户端生成包括以下的视频段：i)经编码的视频帧，以及ii)关于经编码的视频帧的元数据；以及，客户端在传送缓冲区中存储该段。

在一些实施例中，该视频段是以下之一：i)ISO-BMFF视频段，以及ii)公共媒体应用格式(CMAF)视频段。在一些实施例中，直播馈送可以由用于直播分配的接收实体(服务器)进一步处理。

根据一些实施例，(例如，在移动装置或用户设备(UE)上的)HTTP客户端适于执行过程600，用于将由媒体源产生的直播媒体(音频和/或视频)馈送上行流传输给服务器。根据一些实施例，HTTP客户端包括：接收器；传送器；数据存储系统；以及，包括处理器的数据处理设备，其中，该数据处理设备被耦接至数据存储系统、传送器、以及接收器，并且该数据处理设备被配置为执行过程600。

图7示出过程700。过程700可以由HTTP服务器(例如，HTTP获取服务器106)执行，用于从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送。HTTP服务器106通过与客户端的传输层连接(例如，TCP连接)接收超文本传输协议(HTTP)请求消息的HTTP头部，该HTTP请求消息包括主体(步骤702)。HTTP头部不指示HTTP请求消息的主体的尺寸。HTTP服务器106在接收HTTP头部之后，接收HTTP请求消息的主体(步骤704)。接收HTTP请求消息的主体包括：从HTTP客户端接收第一数据块(步骤706)；从HTTP客户端接收第二数据块(步骤708)；以及，在接收第一数据块之后且在接收第二数据块之前，将第一数据块转发给用于分配流视频的分配系统(步骤710)。

根据一些实施例，HTTP服务器适于执行过程700，用于从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送。根据一些实施例，HTTP服务器包括：接收器；传送器；数据存储系统；以及，包括处理器的数据处理设备，其中，所述数据处理设备被耦接至数据存储系统、传送器、以及接收器，并且该数据处理设备被配置为执行过程700。

图8是示出根据一些实施例的HTTP客户端800的功能模块的图。如图8中所示，HTTP客户端800包括传输模块802、传送模块804、以及数据存储模块806。HTTP客户端800可以被用于：将由媒体源产生的直播媒体(音频和/或视频)馈送上行流传输给服务器。传输模块802被配置为：与服务器建立传输层连接(例如，TCP连接)。传送模块804被配置为：通过传输层连接向服务器传送包括头部和主体的超文本传输协议(HTTP)请求消息。HTTP请求消息的头部不指示HTTP请求消息的主体的尺寸。数据存储模块806被配置为：在生成与直播媒体馈送相对应的媒体数据时，在传送缓冲区中存储媒体数据。将质量设置用于生成媒体数据。通过传输层连接向服务器传送HTTP请求消息的主体包括：1)客户端通过传输层连接向服务器传送当前在传送缓冲区中存储的媒体数据的至少一部分；2)客户端从传送缓冲区去除媒体数据的所述至少一部分；3)客户端基于传送缓冲区级别和/或传送缓冲区级别随时间的改变(例如，缓冲区级别梯度)确定客户端是否应该修改被用于生成与直播媒体馈送相对应的媒体数据的质量设置；以及4)客户端重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

图9是示出根据一些实施例的HTTP服务器900的功能模块的图。如图9中所示，HTTP服务器900包括第一接收模块902、第二接收模块904、以及转发模块906。HTTP服务器900可以被用于：从客户端接收由媒体源产生的直播媒体(音频和/或视频)馈送。第一接收模块902被配置为：通过与客户端的传输层连接(例如，TCP连接)接收超文本传输协议(HTTP)请求消息的HTTP头部，该HTTP请求消息包括主体。HTTP头部不指示HTTP请求消息的主体的尺寸。第二接收模块904被配置为：在由第一接收模块接收HTTP头部之后，接收HTTP请求消息的主体。接收HTTP请求消息的主体包括：从HTTP客户端接收第一数据块；从HTTP客户端接收第二数据块；以及，在接收第一数据块之后且在接收第二数据块之前，通过转发模块906向用于分配流视频的分配系统转发第一数据块。

图10是根据一些实施例的HTTP客户端102的框图。如图10中所示，HTTP客户端102可以包括：数据处理设备(DPA)1002，其可以包括一个或多个处理器(P)1055(例如，通用微处理器和/或一个或多个其他处理器，如专用集成电路(ASIC)、现场可编程门阵列(FPGA)等)；传送器1005和接收器1004，它们被耦接至天线1022，使得HTTP客户端102能够向AN节点(例如，基站)传送数据以及从其接收数据；以及，本地存储单元(也被称为“数据存储系统”)1008，其可以包括一个或多个非易失性的存储装置和/或一个或多个易失性的存储装置(例如，随机存取存储器(RAM))。在HTTP客户端102包括通用微处理器的实施例中，可以提供计算机程序产品(CPP)1041。CPP 1041包括计算机可读介质(CRM)1042，计算机可读介质(CRM)1042存储计算机程序(CP)1043，计算机程序(CP)1043包括计算机可读指令(CRI)1044。CRM1042可以是非暂态计算机可读介质(例如但不限于磁介质(例如，硬盘)、光介质、内存装置(例如，随机存取存储器)等)。在一些实施例中，计算机程序1043的CRI 1044被配置为：当由数据处理设备1002执行时，CRI致使HTTP客户端102执行上面描述的步骤(例如，在上文参考流程图描述的步骤)。在其他实施例中，HTTP客户端102可以被配置为：执行本文描述的步骤而无需代码。即，例如，数据处理设备1002可以仅包括一个或多个ASIC。因此，本文描述的实施例的特征可以在硬件和/或软件中实现。

图11是根据一些实施例的HTTP服务器106的框图。如图11中所示，HTTP服务器106可以包括：数据处理设备(DPA)1102，其可以包括一个或多个处理器(P)1155(例如，通用微处理器和/或一个或多个其他处理器，如专用集成电路(ASIC)、现场可编程门阵列(FPGA)等)；网络接口1148，其包括传送器(Tx)1145和接收器(Rx)1147，用于使得HTTP服务器106能够向连接至网络接口1148所连接至的网络110(例如，互联网协议(IP)网络)的其他节点传送数据以及从其接收数据；电路(例如，无线电收发器电路)，其被耦接至用于与UE无线通信的天线系统；以及，本地存储单元(也被称为“数据存储系统”)1108，其可以包括一个或多个非易失性的存储装置和/或一个或多个易失性的存储装置(例如，随机存取存储器(RAM))。在HTTP服务器106包括通用微处理器的实施例中，可以提供计算机程序产品(CPP)1141。CPP1141包括计算机可读介质(CRM)1142，计算机可读介质(CRM)1142存储计算机程序(CP)1143，计算机程序(CP)1143包括计算机可读指令(CRI)1144。CRM1142可以是非暂态计算机可读介质(例如但不限于磁介质(例如，硬盘)、光介质、内存装置(例如，随机存取存储器)等)。在一些实施例中，计算机程序1143的CRI 1144被配置为：当由数据处理设备1102执行时，CRI致使HTTP服务器106来执行上面描述的步骤(例如，在上文参考流程图描述的步骤)。在其他实施例中，HTTP服务器106可以被配置为：执行本文描述的步骤而无需代码。即，例如，数据处理设备1102可以仅包括一个或多个ASIC。因此，本文描述的实施例的特征可以在硬件和/或软件中实现。

使用实例

智能电话和类似无人机这样的其他装置的发展已经注重上行链路方向，其中，这些装置配备有高端相机，能够产生广播质量的视频流。上述实施例特别适于利用这些趋势。在下文描述示例使用实例。

一个示例使用实例是使用无人机来捕捉直播事件，例如，从空中视角来捕捉，其中无人机可以在事件上方飞行，并且通过网络(例如，宽带网络)将内容直接发送给广播方(或其他第三方)。在该使用实例中，无人机可以仅配备高质量相机302，并且以视距手动操作、或以跟随模式操作，以跟随特定目标。无人机可以具有调制解调器(例如，5G调制解调器)，并且可以运行任何操作系统，所述操作系统运行HTTP客户端310。即，无人机可以是客户端102的实例。或者，在其他实施例中，无人机的相机302可以通过链路(例如，蓝牙链路)连接至包含模块304-310的装置，所述装置位于无人机的附近。如上文所述，这种装置操作用于：向远程服务器106流传输直播视频，以供立即处理。该使用实例可以被用在体育事件中，以捕捉类似滑雪竞赛和拉力赛这样的事件，并且可以被用在例如奥林匹克运动会之类的体育事件中(例如，在2018奥林匹克运动会中，5G网络可以在广播和捕捉不同的奥林匹克运动会事件上有帮助)。

另一示例使用实例是从具有相机302的智能电话来广播新闻。即，智能电话可以是客户端102的实例。智能电话技术正在改进，并且高端智能电话的视频质量早已好到足以在专业的TV制作(例如，突发新闻)中使用。在智能电话能够拥有相机的情况下，实施例可以允许报告者利用宽带接入从任何位置立即报导新闻。

在另一使用实例中，相机302是头盔相机(例如，被运动员穿戴的相机)或身体相机(body camera)(例如，被警察穿戴的身体相机)。相机可以向包含模块304-310的装置流传输直播图像，如上文所述，所述装置操作用于：向远程服务器106流传输直播视频，以供立即处理。相机可以远程操作，例如，用于减小捕捉延迟或用于提高视频质量或用于启动/停止记录。实施例支持对这些相机馈送的直播上行链路流传输。

实施例也可以被大量使用，以支持用户生成内容(UGC)的趋势，其中，社交媒体平台允许用户利用移动电话或身体相机将直播流注入其网站。

对使用ISO基本媒体文件格式(BMFF)的分段MP4文件的使用

使用ISO基本媒体文件格式(BMFF)的分段MP4文件(fMP4)可适用于本文公开的实施例。ISO BMFF是在ISO/EC 14996-12中定义的。其是基于框(box)结构来构造的。每个框以框尺寸信息(4字节)开始，后面跟随框类型信息(也是4字节)，该框类型信息通常被表示为4个字母(例如，用于文件类型的ftyp)。框可以是复合框，意味着该框包含其他子框。分段MP4文件(或ISO-BMFF文件)是与常规MP4文件不相似的结构。该文件以文件类型(ftyp)开始，后面跟随正好一个电影框和其他框。媒体数据通过段来描述，段是电影段框(moof)和相关联的媒体数据框(mdat)的组合。

ftyp框包含文件的兼容信息和所使用的编解码器。

电影框(moov)包含编解码器配置信息。对于受DRM保护的内容，包括附加的DRM信息。与常规MP4文件不同，所有的时间与样本(time-to-samples)对应表被留空。时间与样本对应表描述样本持续时间、样本组成和解码时间、以及媒体数据框中的样本的准确的字节偏移和长度。

分段MP4文件包含许多媒体数据框(mdat)。mdat框包含各个样本的实际的媒体数据，各个样本在该框中背靠背链接在一起。对于该分段MP4文件中的每个媒体数据框，存在专用的电影段框，所述电影段框包含针对每个单独的媒体数据框的定时和字节偏移信息。

示例分段MP4文件可以包括给定的框分级结构，现在将对齐进行描述。文件包含顶层、单个ftyp和单个moov框。于是，存在许多电影段框(moof)和媒体数据框(mdat)。存在与mdat框一样多的moof框。也可以包含(例如，用于DRM描述的)其他框。

电影段与相关联的媒体数据框的组合可以被考虑为一个段。在一些实施例中，该段可以是HTTP客户端和服务器所使用(work with)的粒度对象。在ISO/IEC 23000-19(公共媒体应用格式或CMAF)中，电影段框和媒体数据框的组合被称作CMAF块。

因为分段MP4文件的moov框包含编解码器配置，其也被称作初始化部分或初始化部。在正在描述的示例中，分段MP4文件可以包含单个视频轨道(trak框)，其使用H.264编解码器(通过avc1框和关联的属性-值条目来表示)。

在段(moof框和mdat框的组合)中可以包含附加的框。moof框是复合框，其包含若干个其他子框。此处最重要的子框是轨道段头部框(tfhd)和轨道段运行框(trun)。当一个段包含来自多个轨道的媒体(类似音频和视频)时，那么在该段中存在多个轨道段(traf)框。

示例轨道段运行框(trun)可以指示该段的mdat部分仅包含单个样本(或视频帧)。(trun框的)data_offset(数据偏移)字段是到mdat部分的指示符，该指示符指示该样本的起始字节偏移。

因为(在当前描述的示例中)该段中仅有单个样本，所以在轨道段运行框中没有样本长度信息。在该示例中，样本尺寸是作为default_sample_size(默认样本尺寸)被包含在轨道段头部框(tfhd)中。

轨道段头部框可以包括default_sample_duration(默认样本持续时间)(例如，100)、default_sample_size(默认样板尺寸)(如4318)、以及default_sample_flags(默认样本标志)(例如，0x100c0)。default_sample_flag在此处描述这是一个同步样本，即，该样本可以被用于启动解码。

(Tfhd框的)default_sample_duration指示(按照时标单位的)样本持续时间。利用来自(媒体头部框或mdhd中的)初始化部分的轨道时标，人们可以计算以秒为单位的样本持续时间(例如，100/3000秒)。该视频是以每秒30帧的帧速率记录的。

当在一个段中存在多个样本时，至少每个样本的段尺寸被包含在trun框中，因为每个样本具有其自身的尺寸。

现在描述trun框的另一示例。段可以包含30帧，且标志可以描绘帧的编码相关性。要注意，该示例可以来自分区段的媒体文件，其意味着可以将段信息与类似styp(区段类型)和可选的sidx框这样的附加信息一起组合到单独的文件。

本申请要求优先权的美国临时申请包括附录，该附录包含用于修改标准的提案。在下文重复该提案(也被称为“投稿”)的相关部分。

2一般使用实例描述和一般考虑

2.1一般使用实例和架构考虑

工作项目针对标准化用于直播上行链路视频流传输的帧框架。一种考虑是使用各种3GPP接入系统的方式和能力，但是尤其是新的NR接入技术的新的能力和特征。各种3GPP接入系统(例如，LTE或NR)具有不同的能力，其取决于装置实现(和装置类别)和系统部署。

直播上行链路视频通常作为针对直播视频分配服务的供应或获取来使用。术语“供应(contribution)”在专业的TV制作中经常被用于媒体的直播获取。这种视频系统的主要特点是：视频流是单向的，从视频源经由一些媒体之间的节点到达接收器，通常是多个接收器。在图1中描绘了获取链路和可能的分配系统之间的关系。获取链路可以与分配系统解耦。或者，获取服务器可以仅存储视频数据用于以后使用，或获取服务器可以将视频流转发给监测屏幕。例如，源的直播视频可以被存储在文件系统中用于以后使用，或者，来自直播视频源的视频资料可以首先被筛选并且仅在节目导演决定使用专用的直播源时使用。

在分配侧上，如今通常使用自适应比特率流传输(如DASH)。对于自适应比特率，需要以多种质量表示(被称为视频简档)来提供内容，例如，范围从几百kbps到高达几百Mbps。取决于用途，为分配增加DRM保护。用于基于IP的系统的分配系统通常是内容分发网络(CDN)。其他分配系统(IP和传统的广播系统)当然也是可以的。

在直播获取侧上(其是工作项目的范围)，直播媒体源捕捉帧，并且随后将这些帧传送给获取服务器(即，媒体池)。在该文档中，我们关注视频内容，因为视频内容一般需要比音频或其他媒体更高的数据速率。然而，音频或其他媒体也适用于本公开。

已捕捉的视频帧可以被压缩，以在通过获取链路进行传送之前减小比特率。在一些实施例中，供应链路是在上行链路方向上使用的3GPP接入系统。

由于装置侧上和3GPP系统上的获取链路通路中的NAT和防火墙(例如，私人防火墙)的存在(虽然这些功能未被标准化，其仍然存在)，通信的媒体源(例如，相机)，应该激活到获取服务器(例如，媒体池)的通信会话。其原因是，由于安全原因或(公司)安全规定，防火墙中的“开放端口”经常被禁止。而且，当在通路中存在网络地址转换器(NAT)时，必须存在到目标装置的专用的NAT转发规则。

客户端装置经常利用动态IP地址来配置。防火墙和NAT转发规则通常取决于装置IP地址，因此，需要随着每个IP地址改变被调整。

与客户端装置相对的获取服务器被适当配置(例如，要是可达的)并且受保护地接收到来的连接。当获取服务器在NAT后部时，那么要配置对应的NAT转发规则。

因此，虽然技术上可以在3GPP UE侧运行服务器，但该提案关注与UE侧分离的服务器。

2.2视频压缩考虑

在专业广播工作中，串行数字接口(SDI)通常被用于直播视频处理和被用于将来自外部事件的直播视频发送到广播室。SMPTE在2012年已经定义了用于通过RTP(要注意，RTP会话可以通过各种方式被建立)承载SDI信号的RTP净荷格式(IETF RFC 4175)。因为SDI承载未压缩的视频帧或轻量经压缩的视频帧(例如，使用JPEG2000)，用于高分辨率视频的典型的SDI比特率在G比特的范围。SDI的关键优点是切换至每一个帧(不存在GoP类型的相关性结构)和低延迟(每一个帧被立即发送)的能力。

即使对VoLTE的低延迟会话视频——视频(ViLTE)，3GPP也使用经压缩的视频(使用H.264或HEVC)，以减少视频比特率。对于低延迟视频压缩，延迟优先于所产生的视频比特率，且避免类似B帧(B-Frames)的若干个压缩工具。建议在启动任何具体的标准化工作之前，讨论和商定用于3GPP直播上行链路视频方案的目标比特率/比特率范围和延迟限制。

2.3自适应比特率和QoS

3GPP系统支持类似LTE或NR的接入系统的不同的集合。接入系统具有不同的能力(例如，所支持的链路比特率或QoS)。所述能力取决于例如所分配的载波带宽(例如，LTE载波可以支持类似20MHz、10Mhz的不同的带宽)的关于部署实现的特定水平。接入系统可以支持载波聚合，其意味着将多个无线电载波的上行链路容量组合成单个上行链路。

3GPP UE可以具有不同的能力，其取决于装置实现和装置销售商。

系统特性可以取决于装置移动方式。例如，信道特性可以取决于装置是静止还是移动。当装置正在移动时，装置可以执行从一个基站到其他基站甚或是从一个接入网络到另一个接入网络的切换。这可能暂时中断流，这可以通过例如在获取服务器之前引入附加的缓冲区(和延迟)来消除。

服务质量(QoS)和其他技术可以被用于增加的某个最小比特率的链路获取的可用性的概率。

建议目标方案可以从网络的服务质量(QoS)机制中获得好处。然而，由于3GPP接入系统、移动性和部署中的差异，建议上行链路流传输方案可以使用不同的比特率且其甚至支持自适应比特率改变。

2.4安全考虑

直播获取方案需要针对滥用被适当保护。至少存在以下滥用考虑。

直播获取方案应该可以连续地或同时地结合多个独立的媒体源使用。方案应该考虑或支持针对每个媒体源使用单独的账户。账户在此处是获取和后处理功能(类似ABR转码器)并且同样也是分配系统(即，直播馈送如何被提供给接收器)的链条。必须保证只有经授权的客户端可以接入和控制这一账户，并且每个账户具有唯一的获取点描述。

而且，当获取服务器正在监听到来的数据的特定的获取点(例如，端口或URL)时，其应该保证只有经授权的源可以将媒体数据获取到后处理和分配链条。否则，直播服务可以被黑客攻击或通过插入可替换的视频或只是垃圾数据被散发式攻击。因此，用户平面应该被保护，使得获取服务器可以区分经授权的内容数据和未经授权的数据。

2.5能力交换

如图1中所示，获取服务器(媒体池)正在向后续的功能链路ABR转码器转发数据。对于任何转码或任何视频渲染，系统需要首先解码到来的流。可以获得范围广泛的不同的编解码器和编解码器简档。

为了保证获取服务器能够后处理已接收的流，需要能力交换和可能的编解码器协商。最简单的形式将是，获取服务器宣告或暴露其能力(类似字幕支持或所支持的编解码器)，使得客户端(媒体源)可以选择用于直播获取的适当的子集。存在用于展示或协商设置的不同方式。

典型的获取服务器能力是所支持的编解码器和编解码器简档。存在类似支持字幕流或广告机会标记添加的放置的附加能力。

能力暴露/协商帧框架应该是可扩展的且允许销售商专用的能力。

3实现备选方式

存在可以获得的技术方案的集合，可以考虑将它们用于实现。在下文中，我们简单地介绍可以获得的实现备选方式中的至少一些实现备选方式。应注意，其他实现备选方式是可以获得的。

3.1基于RTP的方案

3.1.1概述

RTP是一种协议，其通常在用于视频传送的各种环境中使用。存在可以获得的各种RTP净荷格式，例如，H.264(RFC 6184)或HEVC(RFC 7798)视频。也存在可以用于在RTP(RFC2250)的内部承载MPEG2传输流复用数据或甚至是未压缩的串行数字接口的视频(SDI，SMPTE 2022-6)(RFC 4175)的格式。要注意，SDI在专业TV制作系统中被广泛使用。

RTP使用UDP传输，并且需要专用协议来建立和配置UDP传输。利用SRTP，安全帧框架可用于RTP。备选地或作为补充，可以使用DTLS。

3.1.2基于IMS基础的直播获取会话建立

3GPP会话服务使用IMS构造，并且IMS很适合建立所需要的用于提供上行链路直播视频的RTP用户平面(3GPP TS 26.114)。在直播上行链路情况中，通信信道仅用于单向视频，应该考虑针对这种使用实例的IMS系统的可能的改进。

3GPP已经支持各种RTP视频净荷格式，特别是支持H.264和HEVC视频。当需要时也可以增加其他净荷格式。

IMS将SIP/SDP用于建立单播传输会话，且也将其用于编解码器协商和选择。IMS提供用于授权和认证的帧框架。SRTP和/或DTLS可以被用于保护用户平面获取，防止滥用。

会话建立可以利用IMS。媒体源是IMS客户端。媒体池(在此处)是MRF。另一个示例可以是，将自动应答IMS客户端用作媒体池。

3GPP TS 26.114定义视频率控制。存在类似SCReAM的其他RTP视频率控制方案。一种备选方式是在IET中进行标准化的SCReAM(用于多媒体的自计时率适应)。SCReAM处理网络拥塞控制并且还为媒体源提供所建议的比特率。SCReAM的实现是可以获得的。

3.1.3基于RTSP的直播获取会话建立

3GPP分组交换流传输服务(PSS)(3GPP TS 26.234)将RTSP用于下行链路流传输会话建立。似乎很自然的是，在RTSP上构造直播上行链路视频流传输方案，其中的RTSP服务器(媒体池)位于基础架构中。

将RTSP服务器设置在UE侧是不实际的，但是技术上是可能的。特别是，消费者装置被使用防火墙屏蔽。一些MNO甚至使用网络地址转换并且动态分配IP地址。

RTSP客户端应该充当媒体源而RTSP服务器充当媒体池。RTSP客户端应该建立到RTSP服务器的RTP上行链路流传输会话。现有的RTSP建立过程可以被用于建立用于获取链路的UDP传输。随后，使用“RTSP记录”方法并且可能使用经修改的RTSP设置参数(SetParameter)，启动上行链路直播流传输会话。

RTSP描述方法被用于宣告所选择的编解码器和编解码器配置。单独的过程应该被用于查询由RTSP获取服务器所支持的编解码器。

用于授权和认证RTSP客户端及UDP用户平面数据的安全过程需要被进一步研究和讨论。SRTP或DTLS可以被用于保护用户平面获取，防止滥用。

存在用于RTP流的各种视频率控制方案，并且应该被实现为满足针对(例如由于覆盖变差所引起的)吞吐量变低的情况的时延要求。如第3.1.2节中所介绍的SCReAM是一种实现备选方式。

3.1.4基于WebRTC的直播获取会话建立

如今在用于通信类服务的浏览器中广泛支持WebRTC。WebRTC是为双向通信服务设计的，但是已经针对单向流传输服务成功测试和使用。WebRTC网关可以被用作获取服务器。

WebRTC将SRTP/UDP用作通信传输。内置了使用SRTP和DTLS的组合的安全性。

3.2 TCP上的RTMP

用于上行链路流传输的最普通的流传输协议是Adobe的实时消息收发协议(RTMP)。RTMP将TCP用于定义好的端口(即，端口1935)上的可靠的上行链路流传输。利用基础架构侧上的服务器组件的基于TCP和HTTP的上行链路流传输格式的优点是防止防火墙和NAT问题。TCP的使用需要保证低延迟的TCP配置，这涉及TCP发送缓冲区的适当设置以及保证低延迟的拥塞控制算法的使用，具体细节需要被定义。

RTMP流可以被RTMP协议处理方案(rtmp：//)识别，从而使rtmp：//ex.com/live.swf形式的URL可以被应用解释。为RTMP方案定义独立的周知的端口(端口1935)，因此不需要提供端口。当然，RTMPURL允许其他端口。

RTMP定义其自己的消息格式和复用机制。为了支持RTMP，发送器和接收器二者必须支持所需要的范围的RTMP消息类型和消息处理过程。

RTMP是基于消息的协议。每个消息包含长度，经常有时间戳和一些类型信息。消息可以被细分成更小的RTMP块，以复用和交织所述消息。RTMP定义“块流”，其可以被复用。要注意，RTMP块和HTTP块之间存在明显差异。

RTMP不支持所有的视频编解码器、音频编解码器和添加相关标题方案。例如，当前似乎不支持HEVC。

根据维基百科，可以(使用RTMPT)通过HTTP隧穿RTMP。然而，在RTMP规范中没有该功能的描述。传统上，RTMP主要被用于从服务器到客户端的下行链路流传输。

3.3带有MPEG2-TS或带有分段MP4的HTTP

HTTP也可以被用于直播上行链路视频流传输。HTTP的优点是，类似HTTPS或源认证的所有的HTTP专用安全功能可以被重用。此处，MPEG2-TS[ISO/IEC 13818-1]或分段MP4[ISO/IEC 14996-12]是用于上行链路流传输的合适的格式。而且，基础架构被配置为：允许端口80或443上的HTTP或HTTPS业务穿越任何中间防火墙。

在两种情况中，移动3GPP装置上的HTTP客户端使用HTTP请求来开启到HTTP获取服务器的HTTPS连接。直播上行链路视频随后利用该请求的HTTP主体被提供。HTTP客户端可以使用HTTP 1.0原则来将视频内容直接传递到HTTP主体或其可以使用HTTP 1.1分块传输编码。HTTP分块传输编码允许客户端将已建立的TCP连接重用于后续的HTTP事务(持久TCP连接)。作为利用通过TCP的RTMP的情况，保证TCP被正确地配置很重要。

图5示出使用具有HTTP上的直播获取格式的分段MP4的调用流程。媒体源在此处是HTTP客户端。媒体池在此处是HTTP服务器，其将接收流块立即转发给后处理链条(在此处被示出为去抖动缓冲区)。

在启动直播上行链路流之前，客户端首先查询和检查HTTP获取服务器的能力。HTTP可以被用于查询能力。

随后，HTTP客户端在该HTTP请求的主体之内使用HTTP分块分发来上传直播流。作为HTTP块被承载的段根据ISO/IEF 14996-12被格式化。电影框(“moov”)包含编解码器、编解码器配置和可能的其他信息。当客户端终止直播获取时，那么服务器提供HTTP响应(在这种情况下是201Created)。

当MPEG2_TS[ISO/IEC 13818-1]被用作获取格式时，那么段根据MPEG2-TS被格式化。

率控制应该在这种方案中实现，这可以优选地监测TX缓冲区并且相应地调整媒体源。

4方案要求

为直播上行链路流传输帧框架上的标准化工作提出了以下方案特征(不是排斥性的列表)：

应该考虑NAT和防火墙的存在。获取服务器应该被置于基础架构侧上，从而使媒体源总是位于3GPP UE侧上的通信发起方。

方案应该仅关注直播获取。媒体分配或媒体存储实现应该与获取不相关。

方案应该支持授权和认证。应该可以将直播获取业务分离到用户账户或信道。

只有经授权的业务源才应该能够将视频业务获取到获取服务器。

方案应该能够影响3GPP QoS帧框架。

方案应该支持不同的比特率，比特率取决于可以获得的接入网络(类似NR或LTE)。

方案应该至少支持H.264和HEVC视频编解码器。

方案应该能够根据变化的链路条件(例如，移动性)来调整比特率。

方案应该能够(在需要低延迟直播获取时)使延迟优先于质量/所产生的比特率，或者(在存在用于更好的压缩效率或重传的时间时)使质量/所产生的比特率优先于延迟。

方案应该支持能力检索或能力协商。

5提案

建议考虑上文给出的信息。建议创建用于收集(例如，如第2节、第3节和第4节所给出的)方案设计要求和考虑的永久文档或技术报告。

还建议在用于直播上行链路视频流传输帧框架的技术规范中包括(如在第3.3节中所描述的)基于HTTP的方案。

虽然本文描述了本公开的各种实施例，但应该理解，它们已经仅通过示例方式提出而非限制。本公开的宽度和范围不应该由上述示例性实施例中的任何实施例所限制。而且，按照上述要素的所有可能的变化的其任意组合被本公开包括，除非在本文另外指示或在上下文中另外明显矛盾。

另外，虽然上文所述和在附图中示出的过程被示出为一系列步骤，但这样做仅为了说明。因此，要考虑的是，可以增加一些步骤、可以省略一些步骤、可以重新安排步骤的顺序、并且可以并行地执行一些步骤。

Claims (14)

1.一种由客户端设备(“客户端”)(102)执行的用于向服务器(106)上行流传输由媒体源产生的直播媒体馈送的方法，所述方法包括：

所述客户端(102)与所述服务器(106)建立传输层连接；

所述客户端(102)通过所述传输层连接向所述服务器(106)传送包括头部和主体的超文本传输协议HTTP请求消息，其中，所述HTTP请求消息的头部不指示所述HTTP请求消息的主体的尺寸；

在生成与所述直播媒体馈送相对应的媒体数据时，所述客户端(102)在传送缓冲区(308)中存储媒体数据，其中，将质量设置用于生成媒体数据，其中，通过所述传输层连接向所述服务器(106)传送所述HTTP请求消息的主体包括：

(1)所述客户端(102)通过所述传输层连接向所述服务器(106)传送当前在所述传送缓冲区(308)中存储的媒体数据的至少一部分，其中，所述媒体数据的传送的部分具有公共媒体应用格式CMAF块的格式；

(2)所述客户端(102)从所述传送缓冲区(308)去除媒体数据的所述至少一部分；

(3)所述客户端(102)通过监测所述传送缓冲区的上传进度来确定所述客户端(102)是否应该修改被用于生成与所述直播媒体馈送相对应的媒体数据的所述质量设置；以及

(4)所述客户端(102)重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

2.根据权利要求1所述的方法，其中，所述媒体源是相机(302)。

3.根据权利要求2所述的方法，其中，所述相机(302)是所述客户端(102)的集成部件。

4.根据权利要求2所述的方法，其中，所述相机(302)远离所述客户端(102)。

5.根据权利要求1-4中任意一项所述的方法，其中：

所述触发基于指定持续时间的调度，以及

由于检测到已经经过所述持续时间，所述客户端(102)检测到所述触发。

6.根据权利要求1-4中任意一项所述的方法，还包括：

所述客户端(102)使用第一质量设置来编码由所述媒体源生成的第一组媒体帧，以产生第一组经编码的媒体帧，其中，在所述传送缓冲区(308)中存储的媒体数据包括所述第一组经编码的媒体帧；

传送所述HTTP请求消息的主体的步骤还包括：所述客户端(102)传送第一编解码器配置信息，其中，所述第一编解码器配置信息包括指示所述第一质量设置的信息；

所述客户端(102)监测在所述传送缓冲区(308)中存储的数据量；

所述客户端(102)确定在所述传送缓冲区(308)中存储的数据量超过门限；

由于确定在所述传送缓冲区(308)中存储的数据量超过门限，所述客户端(102)使用第二质量没置来编码由所述媒体源生成的第二组媒体帧，以产生第二组经编码的媒体帧；

所述客户端(102)在所述传送缓冲区(308)中存储与所述直播媒体馈送相对应的另外的媒体数据，其中，所述另外的媒体数据包括所述第二组经编码的媒体帧；以及

传送所述HTTP请求消息的主体的步骤还包括：所述客户端(102)传送第二编解码器配置信息，其中，所述第二编解码器配置信息包括指示所述第二质量设置的信息。

7.根据权利要求1-4中任意一项所述的方法，还包括：

所述客户端(102)编码由所述媒体源生成的第一组媒体帧，以产生第一组经编码的媒体帧，其中，在所述传送缓冲区(308)中存储的媒体数据包括所述第一组经编码的媒体帧；

所述客户端(102)监测在所述传送缓冲区(308)中存储的数据量；

所述客户端(102)确定在所述传送缓冲区(308)中存储的数据量超过门限；

由于确定在所述传送缓冲区(308)中存储的数据量超过门限，所述客户端(102)从所述传送缓冲区(308)丢弃所述第一组媒体帧的至少一个子集，使得被丢弃的帧不被传送给所述服务器(106)。

8.根据权利要求7所述的方法，其中，

所述传送缓冲区(308)存储媒体段，所述媒体段包括媒体帧的所述子集且还包括关于媒体帧的所述子集的元数据，以及

从所述传送缓冲区(308)丢弃媒体帧的所述子集的步骤包括：从所述传送缓冲区(308)丢弃所述媒体段，使得所述媒体段不被传送给所述服务器(106)。

9.根据权利要求1-4中任意一项所述的方法，还包括：

所述客户端(102)获得由所述媒体源生成的未压缩的视频帧；

所述客户端(102)编码所述未压缩的视频帧，以产生经编码的视频帧；

所述客户端(102)生成包括以下的视频段：i)所述经编码的视频帧，以及ii)关于所述经编码的视频帧的元数据；以及

所述客户端(102)在所述传送缓冲区(308)中存储所述视频段。

10.根据权利要求9所述的方法，其中，所述视频段是以下之一：i)ISO-BMFF视频段，以及ii)公共媒体应用格式(CMAF)视频段。

11.根据权利要求1-4中任意一项所述的方法，其中所述直播馈送还可以由接收实体处理用于直播分配。

12.根据权利要求1-4中任意一项所述的方法，其中，所述客户端(102)通过传输层向所述服务器(106)传送当前在所述传送缓冲区(308)中存储的媒体数据的至少一部分包括：传送包括当前在所述传送缓冲区(308)中存储的媒体数据的至少一部分的数据块。

13.根据权利要求1-4中任意一项所述的方法，其中，所述确定所述客户端(102)是否应该修改被用于生成与所述直播媒体馈送相对应的媒体数据的所述质量设置基于：传送缓冲区级别和/或所述传送缓冲区级别随时间的改变。

14.一种HTTP客户端(102)，所述HTTP客户端(102)用于向服务器(106)上行流传输由媒体源产生的直播媒体馈送，所述HTTP客户端(102)包括：

接收器；

传送器；

数据存储系统；以及

包括处理器的数据处理设备，其中，所述数据处理设备被耦接至所述数据存储系统、所述传送器、以及所述接收器，并且所述数据处理设备被配置为：

与所述服务器(106)建立传输层连接；

通过所述传输层连接向所述服务器(106)传送包括头部和主体的超文本传输协议HTTP请求消息，其中，所述HTTP请求消息的头部不指示所述HTTP请求消息的主体的尺寸；

在生成与所述直播媒体馈送相对应的媒体数据时，在传送缓冲区(308)中存储媒体数据，其中，将质量设置用于生成媒体数据，其中，通过所述传输层连接向所述服务器(106)传送所述HTTP请求消息的主体包括：

(1)所述HTTP客户端(102)通过所述传输层连接向所述服务器(106)传送当前在所述传送缓冲区(308)中存储的媒体数据的至少一部分，其中，所述媒体数据的传送的部分具有公共媒体应用格式CMAF块的格式；

(2)所述HTTP客户端(102)从所述传送缓冲区(308)去除媒体数据的所述至少一部分；

(3)所述HTTP客户端(102)通过监测所述传送缓冲区的上传进度来确定所述HTTP客户端(102)是否应该修改被用于生成与所述直播媒体馈送相对应的媒体数据的所述质量设置；以及

(4)所述HTTP客户端(102)重复步骤(1)、(2)和(3)，直到检测到“停止传送”触发为止。

Images