CN118044207A

CN118044207A - 用于视频流式传输的方法、装置和介质

Info

Publication number: CN118044207A
Application number: CN202280066502.7A
Authority: CN
Inventors: 于涌溢; 杨乐; 陈鉴平; 王业奎
Original assignee: Douyin Vision Co Ltd; ByteDance Inc
Current assignee: Douyin Vision Co Ltd; ByteDance Inc
Priority date: 2021-09-30
Filing date: 2022-09-30
Publication date: 2024-05-14
Also published as: WO2023051757A1; US20240259450A1

Abstract

本公开的实施方式提供了一种用于视频流式传输的解决方案。一种用于取得媒体数据的方法包括：由第一设备从清单文件中确定媒体表示的目标段的标识信息，该目标段被指定为包括下列各项之一：针对媒体表示的初始化段与包含媒体数据的媒体段的级联，如果清单文件中不存在初始化段的话，或者包含媒体数据的媒体段，如果清单文件中存在初始化段的话；以及基于标识信息来取得目标段。

Description

用于视频流式传输的方法、装置和介质

技术领域

本公开的实施方式总体涉及视频处理技术，并且更具体地，涉及视频流式传输。

背景技术

媒体流式传输应用通常基于互联网协议(IP)、传输控制协议(TCP)以及超文本传输协议(HTTP)传送方法，并且通常依赖于诸如ISO基媒体文件格式(ISO base media fileformat，ISOBMFF)之类的文件格式。一种这样的流式传输系统是基于HTTP的动态自适应流式传输(dynamic adaptive streaming over HTTP，DASH)。在基于HTTP的动态自适应流式传输(DASH)中，可能存在多媒体内容的视频和/或音频数据的多个表示，不同的表示可对应于不同的编解码特性(例如，视频编解码标准的不同档次(profile)或级别(level)、不同比特率、不同空间分辨率等)。随着实时流式传输服务越来越受欢迎，需要对DASH进行增强。

发明内容

本公开的实施方式提供了一种用于视频流式传输的解决方案。

在第一方面，提出了一种用于取得媒体数据的方法。该方法包括：由第一设备从清单文件中确定媒体表示的目标段(segment)的标识信息，该目标段被指定为包括下列各项之一：针对媒体表示的初始化段与包含媒体数据的媒体段的级联，如果清单文件中不存在初始化段的话，或者包含媒体数据的媒体段，如果清单文件中存在初始化段的话；以及基于标识信息来取得目标段。

在第二方面，提出了另一种用于提供媒体数据的方法。该方法包括：由第二设备从第一设备接收对媒体表示的目标段的请求，该请求包括目标段的标识信息，并且目标段包括下列各项之一：针对媒体表示的初始化段与包含媒体数据的媒体段的级联，如果清单文件中不存在初始化段的话，或者包含媒体数据的媒体段，如果清单文件中存在初始化段的话；以及向第一设备传输由标识信息引用的目标段。

在第三方面，提出了一种用于取得媒体数据的装置。该用于取得媒体数据的装置包括处理器和其上具有指令的非暂态存储器。指令在由处理器执行时，使处理器执行根据本公开的第一方面的方法。

在第四方面，提出了一种用于提供媒体数据的装置。用于取得媒体数据的装置包括处理器和其上具有指令的非暂态存储器。指令在由处理器执行时，使处理器执行根据本公开的第二方面的方法。

在第五方面，提出了一种非暂态计算机可读存储介质。该非暂态计算机可读存储介质存储指令，该指令使处理器执行根据本公开的第一方面的方法。

在第六方面，提出了一种非暂态计算机可读存储介质。该非暂态计算机可读存储介质存储指令，该指令使处理器执行根据本公开的第二方面的方法。

提供该发明内容部分是为了以简化的形式介绍以下在具体实施方式中进一步描述的部分概念。该发明内容部分无意标识所要求保护的主题的关键特征或基本特征，也无意用于限制所要求保护主题的范围。

附图说明

通过参考附图的以下详细描述，本公开的示例实施方式的上述和其他目的、特征和优点将变得更加明显。在本公开的示例实施方式中，相同的附图标记通常指代相同的组件。

图1图示了根据本公开的一些实施例图示了示例视频编解码系统的框图；

图2图示了根据本公开的一些实施例图示了第一示例视频编码器的框图；

图3图示了根据本公开的一些实施例图示了示例视频解码器的框图；

图4图示了根据本公开的一些实施例的MIME多部分消息格式的TIMS的示例的示意图；

图5图示了根据本公开的一些实施例的CDN在不高速缓存段的情况下生成TIMS的过程的流程图；

图6图示了根据本公开实施方式的在第一设备处实现的方法的流程图；

图7图示了根据本公开的一些实施例的实现用于基于网络流式传输媒体数据的技术的示例系统的示意图；

图8图示了根据本公开实施方式的流式传输媒体数据的信令传送流；

图9图示了根据本公开实施方式的在第二设备处实现的方法的流程图；以及

图10图示了其中可以实现本公开的各实施方式的计算设备的框图。

在附图中，相同或相似的附图标记通常指代相同或相似的元件。

具体实施方式

现在结合一些实施例来描述本公开的原理。应当理解，描述这些实施例只是为了说明的目的，帮助本领域技术人员理解并实施本公开，而不对本公开的范围构成任何限制。这里描述的公开可以以除了下面描述的方式之外的各种方式来实现。

在以下描述和权利要求书中，除非另有定义，本文中使用的所有技术和科学术语具有与本公开所属领域的普通技术人员通常理解的相同含义。

本公开中对“一个实施例”、“一个实施例”、“一个示例实施例”等的引用指示所描述的实施例可以包括特定特征、结构或特性，但这不是必须的每个实施例都包含特定的特征、结构或特性。此外，这些短语不一定指同一个实施例。此外，当结合示例实施例描述特定特征、结构或特性时，认为影响该特征在本领域技术人员的知识范围内，与其他实施例相关的结构或特征，无论是否明确描述。

应当理解，虽然本文中可以使用术语“第一”和“第二”等来描述各种元素，但是这些元素不应受这些术语限制。这些术语仅用于区分一个元素与另一个元素。例如，第一元素可以被称为第二元素，并且类似地，第二元素可以被称为第一元素，而不脱离示例实施例的范围。如本文所使用的，术语“和/或”包括一个或多个所列出的术语的任何和所有组合。

本文使用的术语仅用于描述特定实施例的目的，并不旨在限制示例实施例。如本文所用，单数形式“一”、“一个”和“该”也旨在包括复数形式，除非上下文清楚地另有说明。还应当理解，术语“包括”、“包含”、“具有”、“具有”、“包括”和/或“包括”，当在本文中使用时，指定所陈述的特征、元素和/或的存在。组件等，但不排除一个或多个其他特征、元素、组件和/或其组合的存在或添加。

示例环境

图1是示出可以利用本公开的技术的示例视频编解码系统100的框图。如所示出的，视频编解码系统100可以包括源设备110和目的设备120。源设备110也可以称为视频编码设备，并且目的设备120也可以称为视频解码设备。在操作中，源设备110可以被配置为生成经编码的视频数据，并且目的设备120可以被配置为对由源设备110生成的经编码的视频数据进行解码。源设备110可以包括视频源112、视频编码器114和输入/输出(I/O)接口116。

视频源112可以包括诸如视频捕获设备之类的源。视频捕获设备的示例包括但不限于从视频内容提供商接收视频数据的接口、用于生成视频数据的计算机图形系统和/或其组合。

视频数据可以包括一个或多个图片。视频编码器114对来自视频源112的视频数据进行编码，以生成比特流。比特流可以包括形成视频数据的编解码表示的位序列。比特流可以包括编解码图片和相关联的数据。编解码图片是图片的编解码表示。相关联的数据可以包括序列参数集、图片参数集和其他语法结构。I/O接口116可以包括调制器/解调器和/或发送器。经编码的视频数据可以通过网络130A经由I/O接口116直接传输至目的设备120。经编码的视频数据也可以存储在存储介质/服务器130B上，以供目的设备120访问。

目的设备120可以包括I/O接口126、视频解码器124和显示设备122。I/O接口126可以包括接收器和/或调制解调器。I/O接口126可以从源设备110或存储介质/服务器130B获取经编码的视频数据。视频解码器124可以对经编码的视频数据进行解码。显示设备122可以向用户显示经解码的视频数据。显示设备122可以与目的设备120集成，或者可以在目的设备120的外部，该目的设备120被配置为与外部显示设备接口连接。

视频编码器114和视频解码器124可以根据视频压缩标准操作，诸如高效视频编解码(HEVC)标准、通用视频编解码(VVC)标准和其他现有和/或将来的标准。

图2是示出根据本公开的一些实施例的视频编码器200的示例的方框图，视频编码器200可以是图1所示的系统100中的视频编码器114的示例。

视频编码器200可以被配置为实现本公开的任何或所有技术。在图2的示例中，视频编码器200包括多个功能分量。本公开中描述的技术可以在视频编码器200的各个分量之间共享。在一些示例中，处理器可以被配置为执行本公开中描述的任何或所有技术。

在一些实施例中，视频编码器200可以包括划分单元201、预测单元202、残差生成单元207、变换单元208、量化单元209、反量化单元210、反变换单元211、重建单元212、缓冲213和熵编码单元214，该预测单元202可以包括模式选择单元203、运动估计单元204、运动补偿单元205和帧内预测单元206。

在其他示例中，视频编码器200可以包括更多、更少或不同的功能分量。在一个示例中，预测单元202可以包括帧内块复制(IBC)单元。IBC单元可以在IBC模式中执行预测，其中至少一个参考图片是当前视频块所位于的图片。

此外，尽管一些分量(诸如运动估计单元204和运动补偿单元205)可以被集成，但是为了解释的目的，这些分量在图2的示例中被分离地示出。

划分单元201可以将图片划分成一个或多个视频块。视频编码器200和视频解码器300可以支持各种视频块大小。

模式选择单元203可以例如基于误差结果来选择多种编解码模式(帧内(INTRA)编解码或帧间(INTER)编解码)中的一种编解码模式，并且将所产生的帧内编解码块或帧间编解码块提供给残差生成单元207以生成残差块数据，并且提供给重建单元212以重建编码块以用作参考图片。在一些示例中，模式选择单元203可以选择帧内和帧间预测(CIIP)模式的组合，其中预测基于帧间预测信号和帧内预测信号。在帧间预测的情况下，模式选择单元203还可以为块选择针对运动矢量的分辨率(例如，亚像素精度或整数像素精度)。

为了对当前视频块执行帧间预测，运动估计单元204可以通过将来自缓冲213的一个或多个参考帧与当前视频块进行比较来生成针对当前视频块的运动信息。运动补偿单元205可以基于运动信息和来自缓冲213的除了与当前视频块相关联的图片之外的图片的经解码样本，来确定针对当前视频块的预测视频块。

运动估计单元204和运动补偿单元205可以对当前视频块执行不同的操作，例如，取决于当前视频块是在I条带、P条带还是B条带中。如本文中使用的，“I条带”可以是指由宏块构成的图片的一部分，所有宏块均基于相同图片内的宏块。此外，如本文中使用的，在一些方面中，“P条带”和“B条带”可以是指由独立于相同图片中的宏块的宏块构成的图片的部分。

在一些示例中，运动估计单元204可以对当前视频块执行单向预测，并且运动估计单元204可以搜索列表0或列表1的参考图片，以寻找针对当前视频块的参考视频块。运动估计单元204然后可以生成参考索引和运动矢量，该参考索引指示列表0或列表1中的包含参考视频块的参考图片，并且该运动矢量指示当前视频块与参考视频块之间的空间位移。运动估计单元204可以输出参考索引、预测方向指示符和运动矢量作为当前视频块的运动信息。运动补偿单元205可以基于由当前视频块的运动信息指示的参考视频块来生成当前视频块的预测视频块。

备选地，在其他示例中，运动估计单元204可以对当前视频块执行双向预测。运动估计单元204可以搜索列表0中的参考图片以寻找针对当前视频块的参考视频块，并且还可以搜索列表1中的参考图片以寻找针对当前视频块的另一参考视频块。运动估计单元204然后可以生成多个参考索引和多个运动矢量，该多个参考索引指示列表0和列表1中的包含多个参考视频块的多个参考图片，并且该多个运动矢量指示在多个参考视频块与当前视频块之间的多个空间位移。运动估计单元204可以输出当前视频块的多个参考索引和多个运动矢量以作为当前视频块的运动信息。运动补偿单元205可以基于由当前视频块的运动信息指示的多个参考视频块来生成针对当前视频块的预测视频块。

在一些示例中，运动估计单元204可以输出完整的运动信息集，以用于解码器的解码处理。备选地，在一些实施例中，运动估计单元204可以参考另一视频块的运动信息来通过信号传输当前视频块的运动信息。例如，运动估计单元204可以确定当前视频块的运动信息与相邻视频块的运动信息足够相似。

在一个示例中，运动估计单元204可以在与当前视频块相关联的语法结构中向视频解码器300指示一值，该值指示当前视频块具有与另一视频块相同的运动信息。

在另一示例中，运动估计单元204可以在与当前视频块相关联的语法结构中标识另一视频块和运动矢量差(MVD)。运动矢量差指示在当前视频块的运动矢量与所指示的视频块的运动矢量之间的差异。视频解码器300可以使用所指示的视频块的运动矢量以及运动矢量差来确定当前视频块的运动矢量。

如上所讨论的，视频编码器200可以以预测性的方式通过信号传输运动矢量。可以由视频编码器200实现的预测信号传送技术的两个示例包括高级运动矢量预测(AMVP)和合并模式信号传送。

帧内预测单元206可以对当前视频块执行帧内预测。当帧内预测单元206对当前视频块执行帧内预测时，帧内预测单元206可以基于相同图片中其他视频块的经解码样本来生成针对当前视频块的预测数据。针对当前视频块的预测数据可以包括预测视频块和各个语法元素。

残差生成单元207可以通过从当前视频块中减去(例如，由减号指示)当前视频块的(多个)预测视频块来生成针对当前视频块的残差数据。当前视频块的残差数据可以包括对应于当前视频块中样本的不同样本部分的残差视频块。

在其他示例中，例如在跳过模式中，针对当前视频块可以不存在针对当前视频块的残差数据，并且残差生成单元207可以不执行减去操作。

变换处理单元208可以通过将一个或多个变换应用于与当前视频块相关联的残差视频块，来生成针对当前视频块的一个或多个变换系数视频块。

在变换处理单元208生成与当前视频块相关联的变换系数视频块之后，量化单元209可以基于与当前视频块相关联的一个或多个量化参数(QP)值来量化与当前视频块相关联的变换系数视频块。

反量化单元210和反变换单元211可以分别对变换系数视频块应用反量化和反变换，以从变换系数视频块重建残差视频块。重建单元212可以将经重建的残差视频块添加到来自由预测单元202生成的一个或多个预测视频块的对应样本，以产生与当前视频块相关联的重建视频块，以供存储在缓冲213中。

在重建单元212重建视频块之后，可以执行环路滤波操作以减少视频块中的视频块效应伪像。

熵编码单元214可以从视频编码器200的其他功能分量接收数据。当熵编码单元214接收数据时，熵编码单元214可以执行一个或多个熵编码操作，以生成熵编码数据并且输出包括该熵编码数据的比特流。

图3是示出根据本公开的一些实施例的视频解码器300的示例的方框图，视频解码器300可以是图1所示的系统100中的视频解码器124的示例。

视频解码器300可以被配置为执行本公开的任何或所有技术。在图3的示例中，视频解码器300包括多个功能分量。本公开中描述的技术可以在视频解码器300的各个分量之间共享。在一些示例中，处理器可以被配置为执行本公开中描述的任何或所有技术。

在图3的示例中，视频解码器300包括熵解码单元301、运动补偿单元302、帧内预测单元303、反量化单元304、反变换单元305、以及重建单元306和缓冲307。在一些示例中，视频解码器300可以执行通常与关于视频编码器200所描述的编码过程相对的解码过程。

熵解码单元301可以取回经编码的比特流。经编码的比特流可以包括经熵编解码的视频数据(例如，经编码的视频数据块)。熵解码单元301可以对经熵编解码的视频数据进行解码，并且运动补偿单元302可以从经熵解码的视频数据确定运动信息，该运动信息包括运动矢量、运动矢量精度、参考图片列表索引和其他运动信息。运动补偿单元302可以例如通过执行AMVP和合并模式来确定该信息。AMVP被使用，包括基于相邻PB的数据和参考图片得出数个最可以的候选项。运动信息通常包括水平和竖直运动矢量位移值、一个或两个参考图片索引，并且在B条带中的预测区域的情况下，还包括哪个参考图片列表与每个索引相关联的标识。如本文所使用的，在一些方面中，“合并模式”可以是指从空间或时域上相邻的块中导出运动信息。

运动补偿单元302可以产生运动补偿块，可以地基于插值滤波来执行内插。针对以亚像素精度被使用的插值滤波的标识符可以被包括在语法元素中。

运动补偿单元302可以使用由视频编码器200在视频块的编码期间使用的插值滤波来计算用于参考块的亚整数像素的内插值。运动补偿单元302可以根据接收到的语法信息来确定由视频编码器200使用的插值滤波，并且运动补偿单元302可以使用插值滤波来产生预测块。

运动补偿单元302可以使用至少部分语法信息来确定用于编码经编码视频序列的(多个)帧和/或(多个)条带的块的大小、描述经编码视频序列的图片的每个宏块如何被划分的划分信息、指示每个划分如何被编码的模式、针对每个帧间编码块的一个或多个参考帧(和参考帧列表)、以及对经编码视频序列进行解码的其他信息。如本文中所使用的，在一些方面，“条带”可以是指在熵编解码、信号预测和残差信号重建方面可以独立于相同图片的其他条带而被解码的数据结构。条带可以是全部图片，或者也可以是图片的区域。

帧内预测单元303可以使用例如在比特流中接收的帧内预测模式，以从空间相邻块形成预测块。反量化单元303反量化(即，去量化)在比特流中提供的、并且由熵解码单元301解码的量化视频块系数。反变换单元303应用反变换。

重建单元306可以例如通过将残差块与由运动补偿单元202或帧内预测单元303生成的相应预测块相加来获得经解码的块。如果需要的话，还可以应用去块效应滤波以对经解码的块进行滤波，以便去除块效应伪像。经解码的视频块随后被存储在缓冲307中，缓冲307为后续运动补偿/帧内预测提供参考块，并且缓冲307还产生经解码的视频以供在显示设备上呈现。

下文将详细描述本公开的一些示例性实施例。应当注意，在本文件中使用章节标题是为了便于理解，而不是将章节中公开的实施例仅限于该章节。此外，尽管参考通用视频编解码或其他特定视频编解码器描述了一些实施例，但是所公开的技术也适用于其他视频编解码技术。此外，尽管一些实施例详细描述了视频编解码步骤，但是应当理解的是取消编解码的相应解码步骤将由解码器实现。此外，术语视频处理包括视频编解码或压缩、视频解码或解压缩以及视频转码，在该视频转码中视频像素被从一种压缩格式表示为另一种压缩格式或以不同的压缩码率表示。

1.概要

本公开的实施方式涉及视频流式传输。具体而言，其涉及新类型的媒体段的定义和相关信令传送，以使实时媒体流式传输中的初始化延迟最小化。实施方式可以单独地或以各种组合适用于媒体流式传输系统，例如，以基于HTTP的动态自适应流式传输(DASH)标准或其扩展。

2.背景

2.1.视频编解码标准

视频编解码标准主要通过公知的ITU-T和ISO/IEC标准的发展而演进。ITU-T产生了H.261和H.263，而ISO/IEC产生了MPEG-1和MPEG-4Visual，并且两个组织联合产生了H.262/MPEG-2视频和H.264/MPEG-4高级视频编解码(AVC)以及H.265/HEVC标准。自从H.262起，视频编解码标准基于混合视频编解码结构，其中利用时间预测加变换编解码。为了探索HEVC之外的未来视频编解码技术，VCEG和MPEG于2015年联合成立了联合视频探索组(JointVideo Exploration Team，JVET)。从此以后，JVET采用了许多新方法，并将其应用于名为联合探索模型(Joint Exploration Model，JEM)的参考软件中。随后，在通用视频编解码(VVC)项目正式启动时，JVET更名为联合视频专家组(Joint Video Experts Team，JVET)。VVC[3]是新的编解码标准，目标是相比于HEVC达50％的比特率降低，该标准已由JVET在其2020年7月1日结束的第19次会议上最终确定。通用视频编解码(VCC)标准(ITU-T H.266|ISO/IEC 23090-3)和关联的通用补充增强信息(Versatile Supplemental EnhancementInformation，VSEI)标准(ITU-T H.274|ISO/IEC 23002-7)被设计用于最广泛的应用，包括传统用途，诸如电视广播、视频会议或从存储介质播放，以及更新和更先进的用例，诸如自适应比特率流式传输、视频区域提取、来自多个经编解码视频比特流的内容的合成及合并、多视点视频、可扩展分层编解码以及视口自适应360°沉浸式媒体。基本视频编解码(Essential Video Coding，EVC)标准(ISO/IEC 23094-1)是最近由MPEG开发的另一视频编解码标准。

2.2.文件格式标准

媒体流式传输应用通常基于IP、TCP和HTTP传送方法，并且通常依赖于诸如ISO基媒体文件格式(ISOBMFF)之类的文件格式。一种这样的流式传输系统是基于HTTP的动态自适应流式传输(DASH)。为了使用具有ISOBMFF和DASH的视频格式，将会需要特定于视频格式(诸如AVC文件格式和HEVC文件格式)的文件格式规范，以便将视频内容封装在ISOBMFF轨道中以及DASH表示和段中。需要将关于视频比特流的重要信息(例如，档次、层和级别以及许多其他信息)暴露为文件格式级别元数据和/或DASH媒体呈现描述(media presentationdescription，MPD)以供内容选择目的，例如，用于选择适当的媒体段以供在流式传输会话开始时的初始化以及流式传输会话期间的流自适应。

类似地，为了使用具有ISOBMFF的图像格式，将会需要特定于图像格式(诸如AVC图像文件格式和HEVC图像文件格式)的文件格式规范。

VVC视频文件格式，即基于ISOBMFF的用于存储VVC视频内容的文件格式，目前正在由MPEG开发。包括VVC视频文件格式的最新规范草案。

基于ISOBMFF的VVC图像文件格式，即用于存储使用VVC编解码的图像内容的文件格式，目前正在由MPEG开发。包括VVC图像文件格式的最新规范草案。

2.3.DASH

在基于HTTP的动态自适应流式传输(DASH)中，可能存在多媒体内容的视频和/或音频数据的多个表示，不同的表示可对应于不同的编解码特性(例如，视频编解码标准的不同档次或级别、不同比特率、不同空间分辨率等)。这样的表示的清单可在媒体呈现描述(MPD)数据结构中定义。媒体呈现可对应于可由DASH流式传输客户端设备访问的结构化数据集合。DASH流式传输设备可请求和下载媒体数据信息以向客户端设备的用户呈现流式传输服务。媒体呈现可在MPD数据结构中描述，其可以包括MPD的更新。

媒体表示可包含一个或多个时段的序列。每个时段可以延续直到下一时段开始，或者在最后时段的情况下直到媒体呈现的结束。每个时段可包含同一媒体内容的一个或多个表示。表示可以是音频、视频、定时文本或其他此类数据的一定数目的备选经编码版本中的一个。表示可因编码类型而不同，例如，对于视频数据，因比特率、分辨率和/或编解码器而不同，以及对于音频数据，因比特率、语言和/或编解码器而不同。术语表示可以用于指与多媒体内容的特定时段相对应并且以特定方式编码的一段经编码音频或视频数据。可以将特定时段的表示分配给由MPD中的属性所指示的组，该属性指示表示所属于的自适应集。同一自适应集中的表示通常被认为是彼此的备选项，原因在于客户端设备可以在这些表示之间动态地和无缝地切换，例如，以执行带宽自适应。例如，可以将特定时段的视频数据的每个表示分配给相同的自适应集，使得可以选择任何表示来进行解码，以呈现对应时段的多媒体内容的媒体数据，诸如视频数据或音频数据。在一些示例中，一个时段内的媒体内容可由来自组0(如果存在)的一个表示来表示，或者来自每个非零组的至多一个表示的组合来表示。可以相对于时段的开始时间来表达时段的每个表示的定时数据。

表示可以包括一个或多个段。每个表示可以包括初始化段，或者表示的每个段可以是自初始化的。当存在时，初始化段可以包含用于访问表示的初始化信息。通常，初始化段不包含媒体数据。段可由标识符唯一地引用，这样的标识符诸如为统一资源定位符(uniform resource locator,URL)、统一资源名称(uniform resource name,URN)或统一资源标识符(uniform resource identifier,URI)。MPD可以提供针对每个段的标识符。在一些示例中，MPD还可以提供范围属性形式的字节范围，该范围属性可以对应于可由URL、URN或URI访问的文件内的段的数据。

可以选择不同的表示用于不同类型媒体数据的基本上同时的取得。例如，客户端设备可以选择音频表示、视频表示和定时文本表示，以从中取得段。在一些示例中，客户端设备可以选择特定自适应集用于执行带宽自适应。也就是说，客户端设备可以选择包括视频表示的自适应集、包括音频表示的自适应集，以及/或者包括定时文本的自适应集。备选地，客户端设备可以针对某些类型的媒体(例如，视频)选择自适应集，并且针对其他类型的媒体(例如，音频和/或定时文本)直接选择表示。

以下步骤示出了典型DASH流式传输过程：

1)客户端获取MPD。

2)客户端估计下行链路带宽，以及根据经估计的下行链路带宽和编解码器、解码能力、显示器大小、音频语言设置等选择视频表示和音频表示。

3)除非到达媒体呈现的末尾，否则客户端请求所选择的表示的媒体段，并向用户呈现流式传输内容。

4)客户端持续估计下行链路带宽。当带宽向某一方向显著改变(例如，变得更低)时，客户端选择不同的视频表示以匹配新估计的带宽，并转到步骤3。

2.4.视频RTP有效载荷格式和SDP

对于在使用实时传输协议(real-time transport protocol,RTP)的视频应用中使用的任何视频编解码器，例如VVC，需要指定RTP有效载荷格式，以及使用会话描述协议(session description protocol,SDP)的媒体类型参数的信令传送。视频编解码器的RTP有效载荷格式主要指定如何将经编解码的视频比特流封装在RTP分组和RTP流中。AVC、SVC和HEVC的RTP有效载荷格式分别在IETF RFC 6184、RFC 6190和RFC 7798中指定。对于VVC，目前IETF正在开发RTP有效载荷。

3.问题

在基于DASH的实时流式传输中，特别是当现场“广播者”是使用各种移动设备的用户时，通常很难确保恒定的段持续时间。该设备的摄像机可以以不同的变化帧速率来捕获视频。由于计算资源问题，视频编码器可能不时跳过一帧。因此，并不总是可以使用基于@duration属性的简单好用的方法，该属性指定恒定的近似段持续时间。因此，许多实时流式传输服务被迫使用SegmentTimeline元素。

然而，使用SegmentTimeline通常需要客户端不论在何时转入到实时流式传输会话时请求最新的MPD，即使客户端预取了早期版本的MPD也是如此。基本上，客户端首先请求最新的MPD以获取最新媒体段的URL信息，然后请求初始化段和最新的媒体段并由此继续。与可以使用段的@duration属性和基于$number$标识符的URL模板的情况相比，多次往返和多次请求的这种需要会导致附加的初始化延迟(在用户按下“开始”/“加入”按钮的时刻与第一张图片被显示的时刻之间的延迟)。

4.细节

为了解决上述问题，公开了总结如下的方法。本公开的实施方式应被视为解释一般概念的示例，而不应以狭义的方式来解释。此外，这些实施方式可以单独应用或以任何方式组合应用。

1)定义了一种新类型的媒体段，名为转入媒体段(Tuning-In Media Segment,TIMS)。

a.TIMS是初始化段(Initialization Segment,IS)与单个简单媒体段的级联，其中该简单媒体段的每个轨道中的第一电影片段的第一访问单元对应于类型1、2或3的SAP的I_sau(例如，在IS不包括在MPD中的情况下)，或者仅是单个简单媒体段(例如，在IS包括在MPD中的情况下)。

i.备选地，TIMS是初始化段与另一类型的单个媒体段的级联，其中该媒体段的每个轨道中的第一电影片段的第一访问单元对应于类型1、2或3的SAP的I_sau。

1.在示例中，另一类型的媒体段可以是递送单元媒体段、索引媒体段或随机接入媒体段。

ii.备选地或附加地，可以使用MIME多部分消息，通过将初始化段和媒体段作为其中的不同部分，而不是将它们级联在一起，来提供TIMS。

1.在一个示例中，当使用CDN时，CDN的边缘服务器使用这种提供TIMS的方式来向客户端发送TIMS，例如，CDN的边缘服务器可以生成具有单独初始化段和媒体段的TIMSMIME多部分消息，而不是向发端服务器索求TIMS，这可以在发端服务器与CDN之间生成大流量。

a.在一个示例中，附加地，发端服务器可以例如通过将媒体段的URL包括在HTTP响应报头中来通知CDN哪个媒体段应该被包括在TIMS中。

2.在一个示例中，发端服务器使用这种提供TIMS的方式将TIMS发送到边缘服务器、高速缓存或直接发送到客户端。

b.TIMS包含最新的媒体数据，供客户端在转入到正在进行的实时流式传输服务时用以开始。

2)在SegmentBase元素中添加可选元素，用于指定转入媒体段的URL。

3)向SegmentTemplate元素添加可选属性，用于指定转入媒体段的URL。

4)定义实时流式传输转入事件，用于使用‘emsg’框的转入媒体段的段编号和最早呈现时间的信令传送。

在这篇稿件中，我们提出了一组更改，如摘要中所总结的，以使用SegmentTimeline元素而不是@duration属性来最小化实时流式传输场景中的初始化延迟。

利用这些添加，对于使用SegmentTimeline元素的实时流式传输，当预取了MPD时，客户端将能够通过仅发送一个HTTP请求来转入并开始消费第一媒体段，并且无需每次在请求下一媒体段之前请求MPD更新。通过使用这样的设计，如从实验结果中观察到的，初始化延迟可以从1110ms减少到848ms，减少了23.6％。

5.实施方式

以下是上文在第4节中总结的根据本公开的实施方式的一些方面的一些示例实施方式。

5.1.实施方式1

本实施方式针对第1、1.a、1.b和2-4项。该实施方式可适用于DASH。相对于MPEG输入文档m52458中的DASH标准规范的第4版文本，已经添加或修改的大多数相关部分以下划线突出显示，并且一些删除的部分以突出显示。可能还有一些其他变更是编辑性质的，并且因此没有突出显示。

5.3.9.2段基信息

5.3.9.2.1概述

当且仅当每个表示提供单个媒体段并且媒体段URL包含在BaseURL元素中时，SegmentBase元素足以描述段信息。

存在多个媒体段的情况下，应使用SegmentList或SegmentTemplate来描述段信息。SegmentList或SegmentTemplate共享如第5.3.9.2.2子条款表16中提供的多个段基信息(Segment base information)。

如果表示包含多于一个媒体段，则应存在属性@duration或元素SegmentTimeline。属性@duration和元素SegmentTimeline不应同时出现。

段基信息所描述的段由符合如表17中定义的URLType类型的HTTP-URL所引用。

SegmentBase元素和段基信息的属性和元素的语义在第5.3.9.2.2子条款表15中提供，多个段基信息在第5.3.9.2.2子条款表16中提供。段基信息的XML语法在第5.3.9.2.3子条款中提供。

5.3.9.2.2语义

表15—SegmentBase元素和段基信息类型的语义

表16—MultipleSegmentBaseInformation类型的语义

表17—URLType类型元素的语义

5.3.9.2.3XML语法

5.3.9.4段模板

5.3.9.4.1概述

段模板由SegmentTemplate元素定义。在这种情况下，通过由指定给段的动态值替代的特定标识符来创建段列表。替代规则在第5.3.9.4.4子条款中提供。

第5.3.9.4.2子条款表19提供了段列表的属性和元素的语义。段信息的XML语法在第5.3.9.4.3子条款中提供。

5.3.9.4.2语义

表19—SegmentTemplate元素的语义

5.3.9.4.3XML语法

5.3.9.4.4基于模板的段URL构建

SegmentTemplate@media属性、SegmentTemplate@index属性、SegmentTemplate@initialization属性、SegmentTemplate@tuningIn属性和SegmentTemplate@bitstreamSwitching属性均包含字符串，该字符串可以包含表20中列出的标识符中的一个或多个。

在每个URL中，表20中的标识符应替换为表16中定义的替代参数。标识符匹配区分大小写。如果URL包含未加转义的$符号，这些符号没有包含有效的标识符，则URL形成的结果是未定义的。在这种情况下，预计DASH客户端会忽略整个包含的Representation元素，并且MPD的处理会继续进行，如同这个Representative元素不存在。标识符的格式也在表20中指定。

每个标识符可以在封闭的‘$’字符内后附有附加的格式标签，该标签与IEEE1003.1-2008中定义的printf格式标签对齐，遵循该原型：

％0[width]dwidth参数是无符号整数，提供要打印的最小字符数。如果要打印的值比这个数字短，则结果应填充零。即使结果较大，也不会截断该值。媒体呈现的编写应确保替代过程的应用产生有效的段URL。

根据IETF RFC 3986，标识符外的字符串应仅包含URL内允许的字符。

表20—URL模板的标识符

5.3.9.4段信息

...

5.3.9.5.6转入媒体段信息

每个表示最多已分配一个转入媒体段。备选地，每个表示都已分配了零个或多个转入媒体段。

转入媒体段的存在由SegmentBase.TuningIn、SegmentList.TuningIn、 SegmentTemplate.TuningIn元素或SegmentTemplate@tuningIn属性(其可包含转入媒体段的URL和字节范围信息或URL构建规则)的存在指示。

当存在针对表示的转入媒体段时，建议使用带有$Number$标识符的 SegmentTemplate@media属性，并使用SegmentTimeline元素。

5.10.4 DASH特定事件

...

5.10.4.7实时流式传输转入事件

实时流式传输转入事件指示当前段是转入媒体段。此事件由URN“urn:mpeg:dash: event:tuin:2021”标识。

对于使用此架构的事件，‘emsg’.message_data[]字段包含下面定义的DASHTuningIn结构：

—segment_number提供转入媒体段的媒体段部分的段编号。—earliest_ presentation_time提供转入媒体段中任何访问单元的较早呈现时间。时间尺度在当前 ‘emsg’框的timescale字段中提供。

备选地，字段earliest_presentation_time不包括在DASHTuningIn结构中。

6.3.4媒体段类型

6.3.4.1总述

媒体段可以是不同的类型：递送单元媒体段、简单媒体段、随机接入媒体段、切换媒体段、索引媒体段、子索引媒体段和转入媒体段。

所有媒体段应符合第6.3.4.2子条款中的一般定义。第6.3.4子条款下文进一步提供了附加的特定于类型的约束。

第7.3子条款提供了与某些MPD属性相结合的媒体段的进一步规则。媒体段可以符合多种类型。一致性可以通过将种类作为兼容种类，如果适用，作为主要种类添加到‘styp’框中来表达。

除非另有明确说明，否则在第6.3.4子条款中提及的框在ISO/IEC 14496-12中指定。

6.3.4.2递送单元媒体段

符合递送单元媒体段格式的媒体段定义如下：

—每个媒体段应包含一个或多个完整的自包含的电影片段。完整的自包含的电影片段是电影片段(‘moof’)框和媒体数据(‘mdat’)框，该媒体数据框包含不使用由电影片段框中运行轨道参考的外部数据引用的所有媒体样本。

—每个‘moof’框应至少包含一个轨道片段。

—‘moof’框不应使用外部数据参考，应设置‘default-base-is-moof’标记，并应使用data-offset，即不应使用‘base-data-offset-present’。这种设置组合被称为媒体数据的电影片段相对寻址。

—绝对字节偏移不得用于该媒体数据。在电影片段中，每个轨道延伸的持续时间应该尽可能接近相等。特别是，随着电影片段积累，轨道持续时间应该保持相互接近，不应该有‘漂移’。

—每个媒体段可以在段类型框(‘styp’)中携带‘dums’作为兼容种类。本子条款中定义了该种类的一致性要求。

6.3.4.3简单媒体段

符合DASH的简单媒体段格式的媒体段定义如下：

—其应符合如第6.3.4.2子条款中指定的递送单元媒体段格式。

—每个‘traf’框应包含‘tfdt’框。

注意也可以存在如3GPP TS26.244中定义的轨道片段调整框‘tfad’。不鼓励DASH客户端应用‘tfdt’建立的对齐和‘tfad’隐含的时移两者，这将导致双重校正。

—每个简单媒体段可以包含一个或多个‘sidx’框。如果存在，第一‘sidx’框应放置在任何‘moof’框之前，且第一段索引框应记录整个段。

—出于确定重叠段和非重叠段的目的，应忽略如ISO/IEC 14496-12中定义的冗余样本。换言之，应在不考虑冗余样本的情况下计算流中任何访问单元的最早呈现时间。

—每个媒体段可以包含‘styp’框，并且如果存在，应携带‘msdh’作为兼容种类。本子条款中定义了该种类的一致性要求。

6.3.4.4索引媒体段

符合索引媒体段格式的媒体段定义如下：

—每个媒体段应符合如第6.3.4.2子条款中定义的递送单元媒体段，此外，在每个自包含的电影片段中，电影片段(‘moof’)框后面紧跟着其相应的媒体数据(‘mdat’)。

—每个媒体段应包含一个或多个‘sidx’框。第一‘sidx’框应放置在任何‘moof’框之前，并应记录跨越整个段的组成时间的子段。

—每个媒体段应携带‘msix’作为兼容种类。本子条款中定义了该种类的一致性要求。

6.3.4.5子索引媒体段

符合子索引媒体段格式的媒体段定义如下：

—其应符合如第6.3.4.3子条款中指定的索引媒体段格式。

—应存在子段索引框(‘ssix’)，且该子段索引框(‘ssix’)应紧跟在记录同一子段的‘sidx’框之后。紧挨在前面的‘sidx’应只索引媒体子段。

—其应在段类型框(‘styp’)中携带‘sims’作为兼容种类。本子条款中定义了该种类的一致性要求。

6.3.4.6随机接入媒体段

符合随机接入媒体段格式的媒体段定义如下：

—其应符合如第6.3.4.3子条款指定的简单媒体段格式。

—随机接入媒体段中的每个电影片段中的第一访问单元应对应于类型1、2或3的SAP的I_sau。

—媒体段应携带足够的信息以接入流中的媒体，例如，与初始化段相结合的所有必要加密(如果可用)。

6.3.4.7转入媒体段

转入媒体段符合初始化段(如第6.3.3子条款指定)与单个简单媒体段(如第 6.3.4.3子条款指定)的级联，其中该简单媒体段的每个轨道中第一电影片段的第一访问单元对应于类型1、2或3的SAP的I_sau。当MPD@type是“动态”的，转入媒体段包含最新的媒体数据，供客户端在转入到正在进行的实时流式传输服务时用以开始。取决于服务器正在生成的当前媒体段的长度，转入媒体段中的媒体段可以是当前媒体段(例如，在至少几秒钟的媒体数据被封装的情况下当当前媒体段可用时)或先前媒体段(例如，当已经生成当前媒体段的仅一小部分时)。

8.11.2媒体呈现描述约束

...

8.11.2.5 SegmentTemplate元素的约束

—@initialization属性和@tuningIn属性可以包括如IETFRFC 2397中定义的数据URL。

5.2.实施方式2

本实施方式针对第1.a.ii项。该实施方式可以适于使用MIME多部分消息来生成TIMS。当使用MIME多部分消息提供TIMS时，服务器应该先放初始化段，然后放媒体段。图4示出了MIME多部分消息格式400中的TIMS的样子。当使用CDN时，TIMS可以由CDN的边缘服务器生成。CDN应首先从其高速缓存加载初始化段，将其放入TIMS消息中，继而从其高速缓存加载媒体段，并同样将其放入TIMS消息中。如果初始化段和媒体段中的一个或两者都不在CDN的高速缓存中，则CDN应使用正常的HTTP请求向发端服务器索求它们。图5示出了CDN如何在不高速缓存段的情况下生成TIMS的过程500。然而，CDN可能无法决定哪个媒体段应被包括在TIMS中，因此，发端服务器需要以某些方式通知CDN哪个媒体段应该在TIMS中使用，包括但不限于在HTTP响应报头中携带媒体段的URL。如果CDN没有关于要包含在TIMS中的媒体段的信息，则其应该使用正常的HTTP请求向发端服务器索求整个TIMS。

图6图示了根据本公开的一些实施例的方法600的流程图。方法600可以在第一设备处实现。例如，方法600可以在客户端或媒体数据接收器处实现。本文所使用的术语“客户端”可以指作为计算机网络的客户端-服务器模型的组成部分的，访问由服务器提供的服务的计算机硬件或软件。仅作为示例，客户端可以是智能电话或平板计算机。在一些实施例中，第一设备可以在图1所示的目的地设备120处实现。

在框602处，第一设备从清单文件中确定媒体表示的目标段的标识信息。这里，目标段是期望由第一设备取得的媒体表示的段。在框604处，第一设备基于标识信息来取得目标段。

清单文件可以包括与不同编解码特性(例如，视频编解码标准的不同档次或级别、不同比特率、不同空间分辨率等)相对应的表示。可以在媒体呈现描述(MPD)数据结构中定义这样的表示的清单。在一些实施例中，清单文件可以是用于内容选择目的的媒体呈现描述(MPD)，例如，用于在流式传输会话开始时进行初始化和在流式传输会话期间进行流自适应两者的适当媒体段的选择。MPD可以基于DASH。

在本公开的实施方式中，针对媒体表示提出了一种新类型的段，并且第一设备可以取得这种类型的段作为目标段。如果适用，可以在清单文件中指定提出的目标段类型。在本公开的实施方式中，提出的段类型有时可以被称为转入媒体段(TIMS)。

具体地，提出的目标段的类型被指定为包括初始化段(IS)与媒体段的级联(如果该初始化段不在清单文件中)或者仅包括媒体段(如果该初始化段不在清单文件中)。初始化段可以包含用于访问表示的初始化信息。通常，初始化段不包含媒体数据。媒体段包含媒体数据。

本公开中提出的目标段由相应的标识信息(或称为标识符)唯一参考。在一些实施例中，标识信息可以包括统一资源定位器(URL)、统一资源名称(URN)、统一的资源标识符(URI)或任何其他合适的标识符。清单文件(例如，MPD)可以提供目标段的标识信息。在一些示例中，清单文件还可以提供范围属性形式的字节范围，其可以对应于URL、URN或URI可访问的文件内的目标段的数据。

利用从清单文件中提取的标识信息，第一设备可以直接取得相应的目标段。

根据本公开的实施方式，通过指定新类型的段，当清单文件完善时，第一设备(例如，客户端)可能能够通过直接取得本文提出的目标段来转入并开始消费媒体数据。每次在请求下一个媒体段之前不需要请求MPD更新。通过这种媒体数据取得的设计，可以减少初始化延迟。这适用于流式传输媒体服务，特别是适用于实时流式传输服务，在该服务中，无论何时转入到实时流式传输会话，客户端都需要请求最新的MPD，即使客户端预取了早期版本的MPD。

在一些实施例中，在提出的目标段类型中，媒体段可以包括这样的媒体段：其中每个轨道中的第一电影片段的第一访问单元对应于随机接入点。在一些实施例中，目标段中的媒体段可以包括这样的媒体段：其中每个轨道中的第一电影片段的第一访问单元对应于类型1、2或3的流接入点(Stream Access Point,SAP)的I_SAU。ISOBMFF规范指定了与DASH一起使用的一些类型的SAP。前两种SAP类型(类型1和2)对应于H.264/AVC和HEVC中的IDR图片。第三SAP类型(类型3)对应于开放-封闭图片组(group of picture,GOP)随机接入点，因此对应于HEVC中的断链访问(broken link access,BLA)或干净随机访问(clean randomaccess,CRA)图片。

在一些实施例中，本公开中提出的目标段可以包括单个媒体段，尽管在其他情况下可以包括多于一个的媒体段。在一些实施例中，包括在提出的目标段类型中的媒体段可以是简单媒体段。在一些实施例中，备选地或附加地，包括在提出的目标段类型中的媒体段可以是另一类型的媒体段，例如，递送单元媒体段、索引媒体段、随机接入媒体段，或者被定义为包含媒体数据的任何其他类型的媒体段。

在一些实施例中，提出的目标段类型包含当流式传输媒体服务被激活时第一设备用以开始的最新媒体数据。在一些实施例中，第一设备可以确定与媒体表示相关联的流式传输媒体服务是否被激活。如果流式传输媒体服务被激活，则第一设备可以确定取得目标段，并且因此可以首先确定目标段的标识信息。在一些实施例中，流式传输媒体服务可以包括实时流式传输服务，例如现场广播服务。以这种方式，当转入流式传输媒体服务时，第一设备可以以最小的初始化延迟来取得和显示最新的媒体数据。

在一些情况下，可能很难确保一些流式传输服务的恒定段持续时间。例如，在实时流式传输服务的情况下，摄像机可以以不同的变化帧速率捕获视频。由于计算资源问题，视频编码器可以不时跳过一帧。因此，并不总是可以使用基于@duration属性的简单好用的方法，该属性指定恒定的近似段持续时间。因此，许多实时流式传输服务使用SegmentTimeline元素，该元素指定任意段持续时间的时间线。

在一些实施例中，如果正在进行的媒体流式传输服务使用SegmentTimeline元素，例如，清单文件包括SegmentTimeliner元素而不是@duration属性，则可以在清单文件中指定提出的目标段的类型，以最小化初始化延迟，如上所述。

在一些实施例中，当MPD@type是“动态”的时，目标段可以包含最新的媒体数据，供客户端在转入到正在进行的流式传输服务时用以开始。在一些实施例中，根据正在生成的当前媒体段的长度，提出的目标段中的媒体段可以是当前媒体段(例如，在至少几秒钟的媒体数据被封装的情况下当当前媒体段可用时)或先前媒体段(例如，当已经生成了当前媒体段的仅一小部分时)。

在一些实施例中，本文提出的目标段可以在清单文件中被指定为具有媒体段类型。因此，本文提出的目标段也可以符合媒体段的一般定义。

在一些实施例中，可以在清单文件中的SegmentBase元素中指定目标段(即，转入媒体段或TIMS)的标识信息。SegmentBase元素用于描述段信息和段的标识信息。

下表1示出了目标段(名称为“TuningIn”)的SegmentBase元素和段基信息类型的语义的示例。应该注意的是，表4仅是示例，而非限制。

表1—SegmentBase元素和段基信息类型的语义

表2—URLType类型元素的语义

在一些实施例中，目标段的标识信息由清单文件中的SegmentTemplate元素中的属性指定。SegmentTemplate元素用于定义段模板，以创建目标段(即，转入媒体段或TIMS)。

下表3示出了目标段(名称为“@tuningIn”)的SegmentTemplate元素和段基信息类型的语义的示例。应该注意的是，表4仅是示例，而非限制。

表3—SegmentTemplate元素的语义

在一些实施例中，媒体数据的表示可以被分配至多一个本文提出的类型的目标段(即，转入媒体段)。备选地，表示可以被分配零个或多个转入媒体段。

在一些实施例中，通过SegmentBase.TuningIn、SegmentList.TuningIn、SegmentTemplate.TuningIn元素或SegmentTemplate@tuningIn(其可包含转入媒体段的URL和字节范围信息或URL构建规则)的存在来指示转入媒体段的存在。

在一些实施例中，当对于表示存在转入媒体段时使用带有$Number$标识符(以指示媒体段的编号)的SegmentTemplate@media属性，并使用SegmentTimeline元素。

在一些实施例中，可以定义实时流式传输转入事件，用于使用‘emsg’框对目标段的段编号和/或最早呈现时间的信令传送。第一设备可以接收针对目标段的事件消息，例如，实时流式传输转入事件消息。该消息可以指示目标段中的媒体段的段编号和/或目标段的最早呈现时间。

在一些实施例中，实时流式传输转入事件可以指示当前段是转入媒体段。此事件可以通过URN“urn:mpeg:dash:event:tuin:2021”来标识。在一些实施例中，对于使用该架构的事件，‘emsg’.message_data[]字段包含下面定义的DASHTuningIn结构：

其中segment_number提供转入媒体段的媒体段部分的段编号；earliest_presentation_time提供转入媒体段中任何访问单元的较早呈现时间。时间尺度在当前‘emsg’框的timescale字段中提供。

在一些实施例中，备选地，字段earliest_presentation_time不包括在DASHTuningIn结构中。

在一些实施例中，如果目标段在清单文件中被指定并且其标识信息被确定，则第一设备可以根据具体应用以各种方式利用标识信息来取得目标段。在一些实施例中，第一设备可以从具有高速缓存的目标段和可能的其他段的存储介质/服务器取得目标段。在一些实施例中，第一设备可以直接从准备流式传输媒体数据的发端设备取得目标段。

在与根据DASH的HTTP流式传输相关的一些实施例中，第一设备可以通过向第二设备传输包括目标段的标识信息的请求来取得目标段，该第二设备可以是内容分发网络(content delivery network,CDN)中的边缘设备或媒体数据的发端设备。响应于该请求，第二设备可以向第一设备传输所请求的目标段(包括初始化段与媒体段的级联或仅媒体段)。第一设备继而可以接收目标段，例如，用于显示。

出于讨论的目的，图7图示了根据本公开的一些实施例的示例系统700的示意图，该示例系统700实现用于基于网络的流式传输媒体数据的技术。在该示例中，系统700包括第一设备710、可以在CDN中的边缘设备720和发端设备730。边缘设备720和发端设备730可以是服务器设备。

在一些示例中，第一设备710和边缘设备720可以通过网络702通信耦合，网络702可以包括互联网。在一些示例中，边缘设备720和发端设备730也可以通过网络702或另一网络耦合，或者可以直接通信耦合。在一些示例中，边缘设备720和发端设备730可以包括相同的设备。发端设备730准备媒体数据的表示及其清单文件。第一设备710可以经由边缘设备720或者直接从发端设备730取得由发端设备730准备的媒体数据。

图8图示了根据本公开实施方式的用于流式传输媒体数据的信令传送流800。信令传送流800涉及第一设备710、边缘设备720和发端设备730。在该示例中，假定第一设备710经由边缘设备720从发端设备730取得媒体数据。在一些情况下，如果边缘设备720和发端设备730是相同的设备，则认为第一设备710从服务器设备取得媒体数据。

在操作中，例如，当第一设备710转进实时流式传输服务时，第一设备710从清单文件中确定目标段的标识信息。第一设备710向边缘设备720传输(805)对目标段的请求。目标段的标识信息(例如，URL)被包括在请求中。在一些示例中，该请求可以是HTTP请求，例如，GET请求。

在接收到(810)来自第一设备710的请求时，边缘设备720将向第一设备710提供所请求的目标段。如上所提及的，目标段(转入媒体段)可以包括初始化段与媒体段的级联，或者仅包括媒体段，边缘设备720确定(815)初始化段和/或媒体段是否存储在高速缓存中。如果任何请求的段被高速缓存，则边缘设备720可以从其高速缓存加载该段。

在图8所图示的示例中，假定目标段请求的初始化段和媒体段都没有被高速缓存，则边缘设备720可以向发端设备730请求这两个段。

在一些实施例中，如果目标段包括初始化段与媒体段的级联，则边缘设备720可以经由单独的请求(例如，HTTP请求)来请求初始化段和媒体段。具体地，边缘设备720向发端设备730传输(820)对初始化段的请求，并且向发端设备730传输(840)对包括在所请求的目标段中的媒体段的请求。在接收到(825、845)这两个请求后，发端设备730例如以HTTP响应向边缘设备720传输(830、850)所请求的初始化段和媒体段。

在一些实施例中(图8中未图示出)，如果初始化段和媒体段中的任一个被高速缓存，则边缘设备720可以从发端设备730请求另一个未高速缓存的段。

在一些实施例中，如果边缘设备720不能确定哪个媒体段将被包括在目标段中，则发端设备730可以以一些方式通知边缘设备720哪个媒体段要被包括在该目标段中，包括但不限于在HTTP响应的报头内携带该媒体段的标识信息(例如，URL)。在一些实施例中，如果边缘设备720没有关于要被包括在目标段中的媒体段的信息，则边缘设备720可以例如通过在正常HTTP请求中提供目标段的标识信息来向发端设备730请求整个目标段。

在从发端设备730接收(835、855)初始化段和媒体段和/或从高速缓存加载它们中的一个或两个时，边缘设备720传输860目标段，该目标段包括初始化段和媒体段。在其他情况下，目标段可以仅包括媒体段(例如，如果初始化段被包括在由第一设备710预取的清单文件中)。第一设备710接收(865)目标段。

在一些实施例中，边缘设备720可以通过将初始化段和媒体段放置在多用途互联网邮件扩展(Multipurpose Internet Mail Extensions,MIME)消息的不同部分中来生成MIME消息，并将MIME消息传输到第一设备710。在一些实施例中，初始化段可以被放置并且后面是媒体段。MIME消息的结构示例如图4所示。

在一些实施例中，如果在一些情况下指定目标段仅包括媒体段，则目标段也可以由MIME消息提供。在其他实施方式中，可以在任何其他合适的消息中提供目标段。

图9图示了根据本公开的一些实施例的用于提供媒体数据的方法900的流程图。方法900可以在第二设备处实现。例如，方法900可以在服务器或媒体数据发送器处实现。本文使用的术语“服务器”可以指能够进行计算的设备，在这种情况下，客户端通过网络访问服务。服务器可以是物理计算设备或虚拟计算设备。在一些实施例中，第二设备可以在图1所示的源设备110或图7所示的边缘设备720或发端设备730处实现。

在框910处，第二设备从第一设备接收对媒体表示的目标段的请求。该请求包括目标段的标识信息，并且目标段包括以下之一：针对媒体表示的初始化段与包含媒体数据的媒体段的级联(如果清单文件中不存在初始化段的话)，或者包含媒体数据的媒体段(如果清单文件中存在初始化段的话)。

在框920处，第二设备向第一设备传输由标识信息引用的目标段。

在一些实施例中，第二设备可以包括媒体表示的发端服务器或内容分发网络(CDN)的边缘服务器。

在一些实施例中，如果目标段包括初始化段和媒体段，则第二设备可以通过将初始化段和媒体段放置在多用途互联网邮件扩展(MIME)消息的不同部分中来生成MIME消息。第二设备可以向第一设备传输MIME消息。

在一些实施例中，为了生成MIME消息，第二设备可以确定初始化段和媒体段中的至少一个是否存储在高速缓存中。如果初始化段和媒体段中的至少一个存储在高速缓存中，则第二设备可以通过从高速缓存加载该至少一个段来生成MIME消息。如果高速缓存中缺失了初始化段和媒体段中的至少一个，则第二设备可以向媒体表示的发端服务器传输对该至少一个段的请求。第二设备可以从发端服务器接收该至少一个段，并基于所接收的该至少一个段生成MIME消息。

在一些实施例中，第二设备(例如，CDN中的边缘设备)可以从媒体表示的发端服务器接收目标段中的媒体段的标识信息。第二设备可以基于接收到的媒体段的标识信息来确定要包括在目标段中的媒体段。

本公开的实施例可以单独地被实现。备选地，本公开的实施例可以以任何恰当组合被实现。本公开的实施例可以鉴于所附条款进行描述，其特征可以以任何合理的方式进行组合。

条款1.一种用于取得媒体数据的方法，所述方法包括：由第一设备从清单文件中确定媒体表示的目标段的标识信息，所述目标段被指定为包括下列各项之一：针对所述媒体表示的初始化段与包含媒体数据的媒体段的级联，如果所述清单文件中不存在所述初始化段的话，或者包含所述媒体数据的所述媒体段，如果所述清单文件中存在所述初始化段的话；以及基于所述标识信息来取得所述目标段。

条款2.根据条款1所述的方法，其中所述媒体段包括在对应于随机接入点的每个轨道中具有第一电影片段的第一访问单元的媒体段。

条款3.根据条款2所述的方法，其中所述目标段中的所述媒体段包括在对应于类型1、2或3的流接入点(SAP)的I_SAU的每个轨道中具有第一电影片段的第一访问单元的媒体段。

条款4.根据条款1-3中任一项所述的方法，其中所述目标段中的所述媒体段包括下列各项之一：简单媒体段、递送单元媒体段、索引媒体段或随机接入媒体段。

条款5.根据条款1所述的方法，其中取得所述目标段包括：根据确定与所述媒体表示相关联的流式传输媒体服务被激活，取得所述目标段。

条款6.根据条款5所述的方法，其中所述目标段包含所述第一设备在所述流式传输媒体服务被激活时用以开始的最新媒体数据。

条款7.根据条款1-6中任一项所述的方法，其中所述目标段中的所述媒体段包括：可用的当前媒体段或先前媒体段。

条款8.根据条款1-7中任一项所述的方法，其中取得所述目标段包括：由所述第一设备向第二设备传输包括所述目标段的所述标识信息的请求；以及从所述第二设备接收所述目标段。

条款9.根据条款8所述的方法，其中接收所述目标段包括：如果所述目标段包括所述初始化段和所述媒体段，则在多用途互联网邮件扩展(MIME)消息中接收所述目标段，所述初始化段和所述媒体段被放置在所述MIME消息的不同部分中。

条款10.根据条款8所述的方法，其中传输所述请求包括：将所述请求传输到内容分发网络(CDN)的边缘设备。

条款11.根据条款1-10中任一项所述的方法，其中所述目标段的所述标识信息包括所述目标段的统一资源定位器(URL)。

条款12.根据条款1-11中任一项所述的方法，其中在所述清单文件中的SegmentBase元素中指定所述目标段的所述标识信息。

条款13.根据条款1-12中任一项所述的方法，其中所述目标段的所述标识信息由所述清单文件中的SegmentTemplate元素中的属性指定。

条款14.根据条款1-13中任一项所述的方法，进一步包括：接收针对所述目标段的事件消息，所述事件消息指示以下至少一项：所述目标段中的所述媒体段的段编号，或者所述目标段的最早呈现时间。

条款15.根据条款1-14中任一项所述的方法，其中所述清单文件包括SegmentTimeline元素。

条款16.根据条款1-15中任一项所述的方法，其中所述目标段被指定为是所述清单文件中的媒体段类型。

条款17.根据条款1-16中任一项所述的方法，其中所述清单文件包括多媒体呈现描述(MPD)文件。

条款18.一种提供媒体数据的方法，所述方法包括：由第二设备从第一设备接收对媒体表示的目标段的请求，所述请求包括所述目标段的标识信息，并且所述目标段包括下列各项之一：针对所述媒体表示的初始化段与包含媒体数据的媒体段的级联，如果所述清单文件中不存在所述初始化段的话，或者包含所述媒体数据的所述媒体段，如果所述清单文件中存在所述初始化段的话；以及向所述第一设备传输由所述标识信息引用的所述目标段。

条款19.根据条款18所述的方法，其中所述第二设备包括所述媒体表示的发端设备或内容分发网络(CDN)的边缘设备。

条款20.根据条款18所述的方法，其中传输所述目标段包括：如果所述目标段包括所述初始化段和所述媒体段，则通过将所述初始化段和所述媒体段放置在多用途互联网邮件扩展(MIME)消息的不同部分中来生成所述MIME消息；以及向所述第一设备传输所述MIME消息。

条款21.根据条款19所述的方法，其中生成所述MIME消息包括：确定所述初始化段和所述媒体段中的至少一个是否存储在高速缓存中；如果所述初始化段和所述媒体段中的至少一个存储在所述高速缓存中，则通过从所述高速缓存加载所述至少一个段来生成所述MIME消息；以及如果所述高速缓存中缺失所述初始化段和所述媒体段中的至少一个，则将对所述至少一个段的请求传输到所述媒体表示的发端设备，从所述发端设备接收所述至少一个段，以及基于接收到的所述至少一个段来生成所述MIME消息。

条款22.根据条款19所述的方法，进一步包括：从所述媒体表示的发端设备接收所述目标段中的所述媒体段的标识信息，并且其中所述目标段中的所述媒体段是基于接收到的所述媒体段的所述标识信息来确定的。

条款23.一种用于接收媒体数据的装置，所述装置包括处理器和其上具有指令的非暂态存储器，其中所述指令在由所述处理器执行时使所述处理器执行根据条款1-17中任一项所述的方法。

条款24.一种用于提供媒体数据的装置，所述装置包括处理器和其上具有指令的非暂态存储器，其中所述指令在由所述处理器执行时使所述处理器执行根据条款18-22中任一项所述的方法。

条款25.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储指令，所述指令使处理器执行根据条款1-17中任一项所述的方法。

条款26.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储指令，所述指令使处理器执行根据条款18-22中任一项所述的方法。

示例设备

图10示出了可以在其中实现本公开的各种实施例的计算设备1000的框图。计算设备1000可以被实现为源设备110(或视频编码器114或200)或目的设备120(或视频解码器124或300)，或者可以被包括在源设备110(或视频编码器114或200)或目的设备120(或视频解码器124或300)中。

应当理解的是，图10中示出的计算设备1000仅为了说明的目的，而不是以任何方式暗示对本公开实施例的功能和范围的任何限制

如图10所示，计算设备1000包括通用计算设备1000。计算设备1000可以至少包括一个或多个处理器或处理单元1010、存储器1020、存储单元1030、一个或多个通信单元1040、一个或多个输入设备1050以及一个或多个输出设备1060。

在一些实施例中，计算设备1000可以被实现为具有计算能力的任何用户终端或服务器终端。服务器终端可以是由服务提供商提供的服务器、大型计算设备等。用户终端例如可以是任何类型的移动终端、固定终端或便携式终端，包括移动电话、站、单元、设备、多媒体计算机、多媒体平板计算机、互联网节点、通信器、台式计算机、膝上型计算机、笔记本计算机、上网本计算机、个人通信系统(PCS)设备、个人导航设备、个人数字助理(PDA)、音频/视频播放器、数码相机/摄像机、定位设备、电视接收器、无线电广播接收器、电子书设备、游戏设备或其任何组合，并且包括这些设备的附件和外围设备或其任何组合。可以设想的是，计算设备1000可以支持到用户的任何类型的接口(诸如“可穿戴”电路装置等)。

处理单元1010可以是物理处理器或虚拟处理器，并且可以基于存储在存储器1020中的程序实现各种处理。在多处理器系统中，多个处理单元并行地执行计算机可执行指令，以便改善计算设备1000的并行处理能力。处理单元1010也可以被称为中央处理单元(CPU)、微处理器、控制器或微控制器。

计算设备1000通常包括各种计算机存储介质。这样的介质可以是由计算设备1000可访问的任何介质，包括但不限于易失性介质和非易失性介质、或可拆卸介质和不可拆卸介质。存储器1020可以是易失性存储器(例如，寄存器、高速缓存、随机存取存储器(RAM))、非易失性存储器(诸如只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)或闪存)或其任何组合。存储单元1030可以是任何可拆卸或不可拆卸的介质，并且可以包括机器可读介质，诸如存储器、闪存驱动器、磁盘或其他可以被用于存储信息和/或数据并且可以在计算设备1000中被访问的介质。

计算设备1000还可以包括附加的可拆卸/不可拆卸存储介质、易失性/非易失性存储介质。尽管在图10中未示出，但是可以提供用于从可拆卸的非易失性磁盘读取和/或写入可拆卸的非易失性磁盘的磁盘驱动器，以及用于从可拆卸的非易失性光盘读取和/或写入可拆卸的非易失性光盘的光盘驱动器。在这种情况下，每个驱动器可以经由一个或多个数据介质接口连接到总线(未示出)。

通信单元1040经由通信介质与另一计算设备通信。另外，计算设备1000中的组件的功能可以由可以经由通信连接进行通信的单个计算集群或多个计算机器来实现。因此，计算设备1000可以使用与一个或多个其他服务器、联网个人计算机(PC)或其他通用网络节点的逻辑连接来在联网环境中运行。

输入设备1050可以是各种输入设备中的一种或多种输入设备，诸如鼠标、键盘、轨迹球、语音输入设备等。输出设备1060可以是各种输出设备中的一种或多种输出设备，诸如显示器、扬声器、打印机等。借助于通信单元1040，计算设备1000还可以与一个或多个外部设备(未示出)通信，外部设备诸如是存储设备和显示设备，计算设备1000还可以与一个或多个使用户能够与计算设备1000交互的设备通信，或任何使计算设备1000能够与一个或多个其他计算设备通信的设备(例如网卡、调制解调器等)通信，如果需要的话。这种通信可以经由输入/输出(I/O)接口(未示出)进行。

在一些实施例中，计算设备1000的一些或所有组件也可以被布置在云计算架构中，而不是被集成在单个设备中。在云计算架构中，组件可以被远程提供并且共同工作，以实现本公开中描述的功能。在一些实施例中，云计算提供计算、软件、数据访问和存储服务，这将不要求最终用户知晓提供这些服务的系统或硬件的物理位置或配置。在各种实施例中，云计算使用合适的协议经由广域网(例如互联网)提供服务。例如，云计算提供商通过广域网提供应用程序，可以通过网络浏览器或任何其他计算组件访问这些应用程序。云计算架构的软件或组件以及对应的数据可以存储在远程服务器上。云计算环境中的计算资源可以被合并或分布在远程数据中心的位置。云计算基础设施可以通过共享数据中心提供服务，尽管它们表现为作为用户的单一接入点。因此，云计算架构可与被用于从远程位置的服务提供商处提供本文所述的组件和功能。备选地，它们可以由常规服务器提供，或者直接或以其他方式安装在客户端设备上。

计算设备1000可以被用于实现本公开的实施例中的视频编码/解码。存储器1020可以包括具有一个或多个程序指令的一个或多个视频流模块1025。这些模块能够由处理单元1010访问和执行，以执行本文描述的各种实施例的功能。

在执行视频编码的示例实施例中，输入设备1050可以接收视频数据作为待编码的输入1070。视频数据可以由例如视频流模块1025处理，以生成经编码的码流。经编码的码流可以经由输出设备1060作为输出1080被提供。

在执行视频解码的示例实施例中，输入设备1050可以接收经编码的码流作为输入1070。经编码的码流可以由例如视频流模块1025处理，以生成经解码的视频数据。经解码的视频数据可以经由输出设备1060作为输出1080被提供。

虽然已经参考本公开的优选实施例具体示出和描述了本公开，但是本领域技术人员将理解，在不脱离由所附权利要求限定的本申请的精神和范围的情况下，可以在形式和细节上进行各种改变。这些变化旨在由本申请的范围所涵盖。因此，本申请的实施例的前述描述不旨在是限制性的。

Claims

1.一种用于取得媒体数据的方法，所述方法包括：

由第一设备从清单文件中确定媒体表示的目标段的标识信息，所述目标段被指定为包括下列各项之一：

针对所述媒体表示的初始化段与包含媒体数据的媒体段的级联，如果所述清单文件中不存在所述初始化段的话，或者

包含所述媒体数据的所述媒体段，如果所述清单文件中存在所述初始化段的话；以及

基于所述标识信息来取得所述目标段。

2.根据权利要求1所述的方法，其中所述媒体段包括在对应于随机接入点的每个轨道中具有第一电影片段的第一访问单元的媒体段。

3.根据权利要求2所述的方法，其中所述目标段中的所述媒体段包括在对应于类型1、2或3的流接入点(SAP)的I_SAU的每个轨道中具有第一电影片段的第一访问单元的媒体段。

4.根据权利要求1-3中任一项所述的方法，其中所述目标段中的所述媒体段包括下列各项之一：简单媒体段、递送单元媒体段、索引媒体段或随机接入媒体段。

5.根据权利要求1所述的方法，其中取得所述目标段包括：

根据确定与所述媒体表示相关联的流式传输媒体服务被激活，取得所述目标段。

6.根据权利要求5所述的方法，其中所述目标段包含所述第一设备在所述流式传输媒体服务被激活时用以开始的最新媒体数据。

7.根据权利要求1-6中任一项所述的方法，其中所述目标段中的所述媒体段包括：可用的当前媒体段或先前媒体段。

8.根据权利要求1-7中任一项所述的方法，其中取得所述目标段包括：

由所述第一设备向第二设备传输包括所述目标段的所述标识信息的请求；以及

从所述第二设备接收所述目标段。

9.根据权利要求8所述的方法，其中接收所述目标段包括：

如果所述目标段包括所述初始化段和所述媒体段，则在多用途互联网邮件扩展(MIME)消息中接收所述目标段，所述初始化段和所述媒体段被放置在所述MIME消息的不同部分中。

10.根据权利要求8所述的方法，其中传输所述请求包括：

将所述请求传输到内容分发网络(CDN)的边缘设备。

11.根据权利要求1-10中任一项所述的方法，其中所述目标段的所述标识信息包括所述目标段的统一资源定位器(URL)。

12.根据权利要求1-11中任一项所述的方法，其中在所述清单文件中的SegmentBase元素中指定所述目标段的所述标识信息。

13.根据权利要求1-12中任一项所述的方法，其中所述目标段的所述标识信息由所述清单文件中的SegmentTemplate元素中的属性指定。

14.根据权利要求1-13中任一项所述的方法，进一步包括：

接收针对所述目标段的事件消息，所述事件消息指示以下至少一项：

所述目标段中的所述媒体段的段编号，或者

所述目标段的最早呈现时间。

15.根据权利要求1-14中任一项所述的方法，其中所述清单文件包括SegmentTimeline元素。

16.根据权利要求1-15中任一项所述的方法，其中所述目标段被指定为是所述清单文件中的媒体段类型。

17.根据权利要求1-16中任一项所述的方法，其中所述清单文件包括多媒体呈现描述(MPD)文件。

18.一种提供媒体数据的方法，所述方法包括：

由第二设备从第一设备接收对媒体表示的目标段的请求，所述请求包括所述目标段的标识信息，并且所述目标段包括下列各项之一：

向所述第一设备传输由所述标识信息引用的所述目标段。

19.根据权利要求18所述的方法，其中所述第二设备包括所述媒体表示的发端设备或内容分发网络(CDN)的边缘设备。

20.根据权利要求18所述的方法，其中传输所述目标段包括：

如果所述目标段包括所述初始化段和所述媒体段，则通过将所述初始化段和所述媒体段放置在多用途互联网邮件扩展(MIME)消息的不同部分中来生成所述MIME消息；以及

向所述第一设备传输所述MIME消息。

21.根据权利要求19所述的方法，其中生成所述MIME消息包括：

确定所述初始化段和所述媒体段中的至少一个是否存储在高速缓存中；

如果所述初始化段和所述媒体段中的至少一个存储在所述高速缓存中，则通过从所述高速缓存加载所述至少一个段来生成所述MIME消息；以及

如果所述高速缓存中缺失所述初始化段和所述媒体段中的至少一个，

则将对所述至少一个段的请求传输到所述媒体表示的发端设备，

从所述发端设备接收所述至少一个段，以及

基于接收到的所述至少一个段来生成所述MIME消息。

22.根据权利要求19所述的方法，进一步包括：

从所述媒体表示的发端设备接收所述目标段中的所述媒体段的标识信息，并且

其中所述目标段中的所述媒体段是基于接收到的所述媒体段的所述标识信息来确定的。

23.一种用于接收媒体数据的装置，所述装置包括处理器和其上具有指令的非暂态存储器，其中所述指令在由所述处理器执行时使所述处理器执行根据权利要求1-17中任一项所述的方法。

24.一种用于提供媒体数据的装置，所述装置包括处理器和其上具有指令的非暂态存储器，其中所述指令在由所述处理器执行时使所述处理器执行根据权利要求18-22中任一项所述的方法。

25.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储指令，所述指令使处理器执行根据权利要求1-17中任一项所述的方法。

26.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储指令，所述指令使处理器执行根据权利要求18-22中任一项所述的方法。