[go: up one dir, main page]

CN114930862B - 用于流式媒体数据的多解码器接口 - Google Patents

用于流式媒体数据的多解码器接口 Download PDF

Info

Publication number
CN114930862B
CN114930862B CN202180008168.5A CN202180008168A CN114930862B CN 114930862 B CN114930862 B CN 114930862B CN 202180008168 A CN202180008168 A CN 202180008168A CN 114930862 B CN114930862 B CN 114930862B
Authority
CN
China
Prior art keywords
decoder
indication
instances
video
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202180008168.5A
Other languages
English (en)
Other versions
CN114930862A (zh
Inventor
I.布阿齐兹
T.斯托克哈默
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN114930862A publication Critical patent/CN114930862A/zh
Application granted granted Critical
Publication of CN114930862B publication Critical patent/CN114930862B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6005—Decoder aspects
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6017—Methods or arrangements to increase the throughput
    • H03M7/6023—Parallelization

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Software Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本公开涉及一种用于解码媒体数据的示例设备，包括被配置为存储媒体数据的存储器以及在电路中实现并通信地耦合到存储器的一个或多个处理器。一个或多个处理器被配置为确定两个或更多个解码器实例是否意图被同步。所述一个或多个处理器被配置为基于两个或更多个解码器实例意图被同步来控制所述两个或更多个解码器实例，以便能够在相同的呈现时间显现来自所述两个或更多个解码器实例中的每个解码器实例的解码的数据。

Description

用于流式媒体数据的多解码器接口
本申请要求2021年1月7日提交的美国申请号17/143,633的优先权，该申请要求2020年1月9日提交的美国临时申请号62/959,064的权益，每个申请的全部内容通过引用结合于此。
技术领域
本公开涉及媒体数据的解码。
背景技术
数字视频能力可以被结合到多种设备中，包括数字电视、数字直播系统、无线广播系统、个人数字助理(personal digital assistant，PDA)、膝上型或台式计算机、数码相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电电话、视频电话会议设备等。数字视频设备实现视频压缩技术，诸如在由MPEG-2、MPEG-4、ITU-T H.263或ITU-TH.264/MPEG-4、第10部分、高级视频编码(Advanced Video Coding，AVC)、ITU-T H.265(也被称为高效视频编码(High Efficiency Video Coding，HEVC))以及这些标准的扩展所定义的标准中描述的技术，以更有效地发送和接收数字视频信息。
在诸如音频和视频数据的媒体数据被编码之后，媒体数据可以被封包化用于传输或存储。媒体数据可以被组装成符合多种标准中的任何一种的媒体文件，诸如国际标准化组织(International Organization for Standardization，ISO)基本媒体文件格式及其扩展，诸如AVC。
发明内容
一般而言，本公开描述了用于在客户端设备处由不同的相应解码器对不同类型的媒体数据进行解码的技术。最近，在处理沉浸式数据时，各种应用编程接口(applicationprogramming interface，API)标识了一系列问题。本公开的技术可以解决所标识的问题。
在一个示例中，解码媒体数据的方法包括由客户端设备确定两个或更多个解码器实例是否意图被同步，和基于两个或更多个解码器实例意图被同步，控制两个或更多个解码器实例，以便能够在相同的呈现时间显现来自两个或更多个解码器实例中的每个解码器实例的解码的数据。
在另一示例中，一种用于解码媒体数据的设备包括被配置为存储媒体数据的存储器，以及在电路中实现并通信地耦合到存储器的一个或多个处理器，所述一个或多个处理器被配置为：确定两个或更多个解码器实例是否意图被同步；和基于两个或更多个解码器实例意图被同步，控制两个或更多个解码器实例，以便能够在相同的呈现时间显现来自两个或更多个解码器实例中的每个解码器实例的解码的数据。
在另一示例中，非暂时性计算机可读存储介质存储指令，当指令由一个或多个处理器执行时，使得所述一个或多个处理器：确定两个或更多个解码器实例是否意图被同步；和基于两个或更多个解码器实例意图被同步，控制两个或更多个解码器实例，以便能够在相同的呈现时间显现来自两个或更多个解码器实例中的每个解码器实例的解码的数据。
在另一示例中，一种用于解码媒体数据的设备包括用于确定两个或更多个解码器实例是否要被同步的装置，和用于基于两个或更多个解码器实例意图被同步，控制两个或更多个解码器实例，以便能够在相同的呈现时间显现来自两个或更多个解码器实例中的每个解码器实例的解码的数据的装置。
一个或多个示例的细节在附图和以下描述中阐述。根据说明书和附图以及权利要求书，其他特征、目的和优点将变得显而易见。
附图说明
图1是示出实现通过网络流式媒体数据的技术的示例系统的框图。
图2是示出检索单元的示例组件的集合的框图。
图3是示出示例多媒体内容的元素的概念图。
图4是示出示例视频文件的元素的框图，其可以与表示的分段相对应。
图5是示出用于解码流式媒体数据的示例系统的概念图。
图6是示出示例解码引擎和相关的接口的框图。
图7是示出示例视频解码器硬件引擎和示例视频解码器实例的框图。
图8是示出根据本公开的技术的具有聚合输出缓冲区的多视频解码器(multiplevideo decoder，MVD)的概念图。
图9是示出根据本公开的技术的示例基于视频的点云(Video-based PointCloud，V-PCC)解码器的概念图。
图10是示出根据本公开的用于对解码器实例进行分组的示例技术的流程图。
具体实现
在一些媒体应用中，媒体场景由多个视频组成。这样的视频可以被后处理，然后被联合显现。例如，它们可以被缝合、覆盖，或者场景组合产生身临其境的体验。本公开描述了可以应用于包括沉浸式媒体数据(例如，音频和视频数据)的比特流的技术。
在一些示例中，多视频解码器(multiple video decoder，MVD)通过API(如OpenMAX IL或Android的MediaCodec API)提供对解码硬件的访问。这些API使MVD能够创建和运行多个解码器实例，即使只有一个硬件解码器。
然而，这些API可能缺乏一些处理沉浸式媒体的能力。例如，API可能缺乏发现MVD的聚合处理能力的能力。例如，来自不同流的多个样本的逻辑分组用于同时解码可能是不可能的。在一些示例中，可以根据缓冲区报头中的nTimestamp参数来推断聚合，但是当解码这些相关的样本时，MVD组件没有信息来将延迟偏差保持为最小。此外，对不同解码器实例的调度的精细粒度控制可能是不可能的。
根据本公开的技术，对解码器API的抽象扩展可以为沉浸式媒体提供更好的支持，并解决上述问题。例如，这些抽象扩展可以被映射到OpenMAX IL和MediaCodec。
本公开的技术可应用于符合根据ISO基本媒体文件格式、可伸缩视频编码(Scalable Video Coding，SVC)文件格式、高级视频编码(Advanced Video Coding，AVC)文件格式、第三代合作伙伴计划(3GPP)文件格式和/或多视图视频编码(Multiview VideoCoding，MVC)文件格式或其它类似视频文件格式中的任一者封装的视频数据的视频文件。
在HTTP流中，经常使用的操作包括HEAD、GET和partial GET。HEAD操作检索与给定的统一资源定位符(uniform resource locator，URL)或统一资源名称(uniform resourcename，URN)相关联的文件的报头，而不检索与URL或URN相关联的有效载荷。GET操作检索与给定URL或URN相关联的整个文件。Partial GET操作接收字节范围作为输入参数，并检索文件的连续字节数，其中字节数与接收的字节范围相对应。因此，可以为HTTP流提供电影片段，因为partial GET操作可以获得一个或多个单独的电影片段。在电影片段中，可以有几个不同轨道的轨道片段。在HTTP流中，媒体呈现可以是客户端可访问的数据的结构化集合。客户端可以请求并下载媒体数据信息，以向用户呈现流式服务。
在使用HTTP流来流式3GPP数据的示例中，多媒体内容的视频和/或音频数据可能有多种表示。如下所述，不同的表示可以与不同的编码特性(例如，视频编码标准的不同配置文件或级别)、不同的编码标准或编码标准的扩展(诸如多视图和/或可伸缩扩展)、或者不同的比特率相对应。这样的表示的清单可以在媒体呈现描述(Media PresentationDescription，MPD)数据结构中定义。媒体呈现可以与HTTP流客户端设备可访问的结构化数据集合相对应。HTTP流客户端设备可以请求并下载媒体数据信息，以向客户端设备的用户呈现流式服务。媒体呈现可以在MPD数据结构中描述，其可以包括MPD的更新。
媒体呈现可以包含一个或多个时段的序列。每个时段可以延伸到下一个时段的开始，或者在最后一个时段的情况下，延伸到媒体呈现的结束。每个时段可以包含相同的媒体内容的一个或多个表示。表示可以是音频、视频、定时文本或其他这样的数据的多个可选编码版本之一。这些表示可以因编码类型而不同，例如，视频数据的比特率、分辨率和/或编解码器以及音频数据的比特率、语言和/或编解码器。术语“表示”可以用来指与多媒体内容的特定时段并以特定方式编码相对应的编码音频或视频数据的一部分。
特定时段的表示可以被分派给由MPD中的属性指示的组，该属性指示该表示所属的适配集。相同的适配集中的表示通常被认为是彼此可替换的，因为客户端设备可以在这些表示之间动态且无缝地切换，例如，以执行带宽适配。例如，特定时段的视频数据的每个表示可以被分派给相同的适配集，使得可以选择任何表示进行解码，以呈现相应时段的多媒体内容的媒体数据，诸如视频数据或音频数据。在一些示例中，一个时段内的媒体内容可以由来自组0的一个表示(如果存在的话)或者来自每个非零组的至多一个表示的组合来表示。时段的每个表示的定时数据可以相对于时段的开始时间来表示。
表示可以包括一个或多个分段。每个表示可以包括初始化分段，或者表示的每个分段可以是自初始化的。当存在时，初始化分段可以包含用于访问表示的初始化信息。通常，初始化段不包含媒体数据。分段可以由标识符唯一引用，诸如统一资源定位符(URL)、统一资源名称(URN)或统一资源标识符(uniform resource identifier，URI)。MPD可以为每个分段提供标识符。在一些示例中，MPD还可以以范围属性的形式提供字节范围，其可以对应于可由URL、URN或URI访问的文件内的分段的数据。
可以为不同类型的媒体数据的基本上同时的检索选择不同的表示。例如，客户端设备可以选择音频表示、视频表示和定时文本表示，从中检索分段。
在一些示例中，客户端设备可以选择特定的适配集来执行带宽适配。也就是说，客户端设备可以选择包括视频表示的适配集、包括音频表示的适配集和/或包括定时文本的适配集。或者，客户端设备可以为某些类型的媒体(例如，视频)选择适配集，并直接为其他类型的媒体(例如，音频和/或定时文本)选择表示。
图1是示出实现通过网络流式媒体数据的技术的示例系统10的框图。在这个示例中，系统10包括内容准备设备20、服务器设备60和客户端设备40。客户端设备40和服务器设备60通过网络74通信耦合，网络74可以包括互联网。在一些示例中，内容准备设备20和服务器设备60也可以通过网络74或另一网络耦合，或者可以直接地通信耦合。在一些示例中，内容准备设备20和服务器设备60可以包括相同的设备。
在图1的示例中，内容准备设备20包括音频源22和视频源24。音频源22可以包括例如麦克风，该麦克风产生表示要由音频编码器26编码的捕获的音频数据的电信号。可选地，音频源22可以包括存储先前记录的音频数据的存储介质、诸如计算机化合成器的音频数据生成器或者任何其他音频数据源。视频源24可包含产生将由视频编码器28编码的视频数据的视频相机、用先前记录的视频数据编码的存储介质、诸如计算机图形源的视频数据产生单元或任何其它视频数据源。在所有示例中，内容准备设备20不必通信地耦合到服务器设备60，而是可以将多媒体内容存储到由服务器设备60读取的单独介质。
原始音频和视频数据可以包括模拟或数字数据。模拟数据可以在被音频编码器26和/或视频编码器28编码之前被数字化。音频源22可以在发言的参与者发言时从发言的参与者获得音频数据，并且视频源24可以同时地获得发言的参与者的视频数据。在其他示例中，音频源22可以包括包含存储的音频数据的计算机可读存储介质，并且视频源24可以包括包含存储的视频数据的计算机可读存储介质。以这样的方式，本公开中描述的技术可以应用于实况、流式、实时音频和视频数据，或者应用于存档的、预先记录的音频和视频数据。
与视频帧相对应的音频帧通常是包含音频数据的音频帧，该音频数据是由音频源22与包含在视频帧内的由视频源24捕获(或生成)的视频数据同时捕获(或生成)的。例如，当发言的参与者通常通过发言产生音频数据时，音频源22捕获音频数据，并且视频源24同时(也就是说，当音频源22捕获音频数据时)捕获发言的参与者的视频数据。因此，音频帧可以在时间上与一个或多个特定的视频帧相对应。因此，与视频帧相对应的音频帧通常对应于同时捕获音频数据和视频数据的情形，并且对于该情形，音频帧和视频帧分别包括同时捕获的音频数据和视频数据。
在一些实例中，音频编码器26可在每个编码的音频帧中编码时间戳，其表示记录编码的音频帧的音频数据的时间，且类似地，视频编码器28可在每个编码的视频帧中编码时间戳，其表示记录编码的视频帧的视频数据的时间。在这样的示例中，与视频帧相对应的音频帧可以包括包含时间戳的音频帧和包含相同的时间戳的视频帧。内容准备设备20可以包括内部时钟，音频编码器26和/或视频编码器28可以根据该内部时钟生成时间戳，或者音频源22和视频源24可以使用该内部时钟将音频和视频数据分别与时间戳相关联。
在一些实例中，音频源22可向音频编码器26发送与记录音频数据的时间相对应的数据，且视频源24可向视频编码器28发送与记录视频数据的时间相对应的数据。在一些实例中，音频编码器26可在编码的音频数据中编码序列标识符以指示编码的音频数据的相对时间排序，但不一定指示记录音频数据的绝对时间，且类似地，视频编码器28也可使用序列标识符来指示编码的视频数据的相对时间排序。类似地，在一些示例中，序列标识符可以被映射或以其他方式与时间戳相关联。
音频编码器26通常产生编码的音频数据流，而视频编码器28产生编码的视频数据流。每个单独的数据流(无论是音频还是视频)可以被称为基本流。基本流是一种表示的单个数字编码(可能是压缩的)分量。例如，表示的编码视频或音频部分可以是基本流。在封装到视频文件中之前，可以将基本流转换成封包化的基本流(packetized elementarystream，PES)。在相同的表示中，流ID可以用于将属于一个基本流的PES包与另一个区分开来。基本流的基本数据单元是封包化的基本流(PES)包。因此，编码的视频数据通常与基本视频流相对应。类似地，音频数据与一个或多个相应的基本流相对应。
许多视频编码标准，诸如ITU-T H.264/AVC和即将到来的高效视频编码(HEVC)标准，定义了无错比特流的语法、语义和解码过程，其中任何一个都符合特定的配置文件或级别。视频编码标准通常不指定编码器，但是编码器的任务是保证生成的比特流符合解码器的标准。在视频编码标准的背景下，“配置文件(profile)”与应用于它们的算法、特征或工具和约束的子集相对应。例如，如H.264标准所定义的，“配置文件”是由H.264标准指定的整个比特流语法的子集。“级别(level)”与解码器资源消耗的限制相对应，例如诸如解码器存储器和计算，其与图像分辨率、比特率和块处理速率相关。可以用profile_idc(配置文件指示符)值来发信号通知配置文件，而可以用level_idc(级别指示符)值来发信号通知级别。
例如，H.264标准认识到，在由给定配置文件的语法强加的界限内，仍然可能需要编码器和解码器的性能有很大的变化，这取决于比特流中语法元素所取的值，诸如解码的图像的指定大小。H.264标准进一步认识到，在许多应用中，实现能够处理特定配置文件内语法的所有假设使用的解码器既不实际也不经济。因此，H.264标准将“级别”定义为对比特流中的语法元素的值施加的一组特定约束。这些约束可能是对值的简单限制。或者，这些约束可以采取对值的算术组合的约束的形式(例如，图像宽度乘以图像高度乘以每秒解码的图像数量)。H.264标准进一步规定，各个实现可以为每个支持的配置文件支持不同的级别。
符合配置文件的解码器通常支持配置文件中定义的所有特征。例如，作为编码特征，B图像编码在H.264/AVC的基线配置文件中不被支持，但是在H.264/AVC的其他配置文件中被支持。符合级别的解码器应该能够解码任何不需要超出该级别中定义的限制的资源的比特流。配置文件和级别的定义可能有助于提高可解释性。例如，在视频传输期间，可以为整个传输会话协商并同意配置文件和级别定义的对。更具体地，在H.264/AVC中，级别可以定义对需要处理的宏块数量、解码的图像缓冲区(decoded picture buffer，DPB)大小、编码的图像缓冲区(coded picture buffer，CPB)大小、垂直运动向量范围、每两个连续MB的最大运动向量数量、以及B块是否可以具有小于8×8像素的子宏块分区的限制。以这样的方式，解码器可以确定解码器是否能够正确解码比特流。
在图1的示例中，内容准备设备20的封装单元30从视频编码器28接收包括编码的视频数据的基本流，并从音频编码器26接收包括编码音频数据的基本流。在一些实例中，视频编码器28和音频编码器26可各自包括打包器，用于从编码数据形成封包化的基本系统(packetized elementary system，PES)包。在其它实例中，视频编码器28和音频编码器26可各自与各自的打包器接口，以从编码的数据形成PES包。在又一实例中，封装单元30可包含用于从编码的音频和视频数据形成PES包的打包器。
视频编码器28可以各种方式对多媒体内容的视频数据进行编码，以产生具有各种比特率和各种特性的多媒体内容的不同表示，所述特性诸如像素分辨率、帧速率、符合各种编码标准、符合各种配置文件和/或各种编码标准的配置文件级别、具有一个或多个视图的表示(例如，用于二维或三维回放)、或其它这样的特性。如在本公开中所使用的，表示可以包括音频数据、视频数据、文本数据(例如，用于隐藏字幕)或其他这样的数据中的一种。该表示可以包括基本流，诸如音频基本流或视频基本流。每个PES包可包括标识PES包所属的基本流的stream_id。封装单元30负责将基本流组装成各种表示的视频文件(例如，分段)。
封装单元30从音频编码器26和视频编码器28接收表示的基本流的PES包，并从PES包形成相应的网络抽象层(network abstraction layer，NAL)单元。编码的视频分段可以被组织成NAL单元，其提供了“网络友好”的视频表示，解决了诸如视频电话、存储、广播或流式的应用。NAL单元可分类为视频编码层(Video Coding Layer，VCL)NAL单元和非VCL NAL单元。VCL单元可以包含核心压缩引擎，并且可以包括块、宏块和/或切片级别数据。其他NAL单位可能是非VCL NAL单位。在一些示例中，一个时间实例中的编码的图像(通常呈现为主编码的图像)可以包含在包括一个或多个NAL单元的访问单元中。
非VCL NAL单元可以包括参数集NAL单元和补充增强信息(SupplementalEnhancement Information，SEI)NAL单元等。参数集可以包含序列级别报头信息(在序列参数集(sequence parameter set，SPS)中)和不经常改变的图像级别报头信息(在图像参数集(picture parameter set，PPS)中)。利用参数集(例如，PPS和SPS)，不经常改变的信息不需要为每个序列或图像重复；因此，可以提高编码效率。此外，参数集的使用可以实现重要报头信息的带外传输，避免了对用于错误恢复的冗余传输的需要。在带外传输的示例中，参数集NAL单元可以在与其他NAL单元不同的信道上传输，诸如SEI NAL单元。
SEI可以包含对来自VCL NAL单元的编码的图像样本进行解码所不需要的信息，但是可以帮助与解码、显示、错误恢复和其他目的相关的处理。SEI消息可被包含在非VCL NAL单位中。SEI消息是一些标准规范的标准部分，因此对于符合标准的解码器实现并不总是强制性的。SEI消息可以是序列级别SEI消息或图像级别SEI消息。一些序列级别信息可以被包含在SEI消息中，诸如SVC示例中的可伸缩性信息SEI消息和MVC中的视图可伸缩性信息SEI消息。这些示例SEI消息可以传达关于例如操作点的提取和操作点的特性的信息。此外，封装单元30可以形成清单文件，诸如描述表示特性的媒体呈现描述符(media presentationdescriptor，MPD)。封装单元30可以根据可扩展标记语言(extensible markup language，XML)来格式化MPD。
封装单元30可以向输出接口32提供多媒体内容的一个或多个表示的数据以及清单文件(例如，MPD)。输出接口32可以包括网络接口或用于写入存储介质的接口，诸如通用串行总线(USB)接口、光盘(CD)或数字视频光盘(DVD)写入器或刻录机、到磁或闪存介质的接口、或用于存储或传输媒体数据的其他接口。封装单元30可以向输出接口32提供多媒体内容的每个表示的数据，输出接口32可以经由网络传输或存储介质向服务器设备60发送数据。在图1的示例中，服务器设备60包括存储各种多媒体内容64的存储介质62，每个多媒体内容包括各自的清单文件66和一个或多个表示68A-68N(表示68)。在一些示例中，输出接口32也可以直接地向网络74发送数据。
在一些示例中，表示68可以被分成适配集。也就是说，表示68的各种子集可以包括相应的公共特性的集合，诸如编解码器、配置文件和级别、分辨率、视图数量、分段的文件格式、可以标识要与例如由扬声器解码和呈现的表示和/或音频数据一起显示的文本的语言或其他特性的文本类型信息、可以描述适配集中表示的场景的相机角度或真实世界相机视角的相机角度信息、描述内容对特定观众的适用性的评级信息等。
清单文件66可以包括指示与特定适配集相对应的表示68的子集的数据，以及适配集的共同特性。清单文件66还可以包括表示个体特性的数据，诸如适配集的个体表示的比特率。以这样的方式，适配集可以提供简化的网络带宽适配。可以使用清单文件66的适配集元素的子元素来指示适配集中的表示。
服务器设备60包括请求处理单元70和网络接口72。在一些示例中，服务器设备60可以包括多个网络接口。此外，服务器设备60的任何或所有特征可以在内容递送网络的其他设备上实现，诸如路由器、网桥、代理设备、交换机或其他设备。在一些示例中，内容递送网络的中间设备可以缓存多媒体内容64的数据，并且包括与服务器设备60的组件基本一致的组件。通常，网络接口72被配置为通过网络74发送和接收数据。
请求处理单元70被配置为从诸如客户端设备40的客户端设备接收对存储介质62的数据的网络请求。例如，请求处理单元70可以实现超文本传输协议(hypertext transferprotocol，HTTP)版本1.1，如在1999年6月，IETF，网络工作组，R.Fielding等人，RFC 2616中，“超文本传输协议-HTTP/1.1”中所述。也就是说，请求处理单元70可被配置为接收HTTPGET或partial GET请求，且响应于所述请求而提供多媒体内容64的数据。这些请求可以例如使用分段的URL来指定表示68之一的分段。在一些示例中，请求还可以指定分段的一个或多个字节范围，因此包括partial GET请求。请求处理单元70还可以被配置为服务HTTPHEAD(HTTP报头)请求，以提供表示68之一的分段的报头数据。在任何情况下，请求处理单元70可以被配置为处理请求，以向诸如客户端设备40的请求设备提供所请求的数据。
附加地或可替换地，请求处理单元70可以被配置为经由广播或多播协议，诸如演进多媒体广播和多播服务(Multimedia Broadcast and Multicast Service，eMBMS)，来递送媒体数据。内容准备设备20可以以与所述基本相同的方式创建动态自适应HTTP流式(Dynamic Adaptive Streaming over HTTP，DASH)分段和/或子分段，但是服务器设备60可以使用eMBMS或另一广播或多播网络传输协议来递送这些分段或子分段。例如，请求处理单元70可被配置为从客户端设备40接收多播组加入请求。也就是说，服务器设备60可以向与特定媒体内容(例如，直播事件的广播)相关联的客户端设备(包括客户端设备40)通告与多播组相关联的互联网协议(IP)地址。客户端设备40进而可以提交加入多播组的请求。该请求可以在整个网络74中传播，例如组成网络74的路由器，使得路由器将去往与多播组相关联的IP地址的业务定向到订阅客户端设备，诸如客户端设备40。
如图1的示例中所示，多媒体内容64包括清单文件66，清单文件66可以对应于媒体呈现描述(MPD)。清单文件66可以包含不同替代表示68(例如，具有不同质量的视频服务)的描述，并且该描述可以包括例如编解码器信息、配置文件值、级别值、比特率和表示68的其他描述性特性。客户端设备40可以检索媒体呈现的MPD以确定如何访问表示68的分段。
具体来说，检索单元52可检索客户端设备40的配置数据(未图示)以确定视频解码器48的解码能力和视频输出44的显现能力。配置数据还可包括客户端设备40的用户选择的语言偏好、与客户端设备40的用户设置的深度偏好相对应的一个或多个相机视角、和/或客户端设备40的用户选择的评级偏好中的任何一个或全部。检索单元52可以包括例如被配置为提交HTTP GET和partial GET请求的网络浏览器或媒体客户端。检索单元52可以与由客户端设备40的一个或多个处理器或处理单元(未示出)执行的软件指令相对应。在一些实例中，关于检索单元52描述的全部或部分功能可在硬件或硬件、软件和/或固件的组合中实施，其中可提供必要的硬件来执行软件或固件的指令。
尽管在图1的示例中仅示出了单个视频解码器48，但是如下面更详细讨论的(例如，参考图8)，客户端设备40可以被配置为包括多个视频解码器。另外，解封装单元50可被配置为包括解复用器，所述解复用器解复用多个编码的视频比特流(例如，针对经立方体映射的视频数据的不同瓦片)，且将编码的视频比特流引导到不同视频解码器。解封装单元50可包括接口，诸如将各种视频比特流的视频数据引导到对应视频解码器的应用编程接口(API)。另外，客户端设备40可包含同步单元，其在时间上同步来自多个视频解码器的解码的视频数据(例如，图像)，以及由音频解码器46解码的音频数据。
检索单元52可将客户端设备40的解码和显现能力与由清单文件66的信息指示的表示68的特性进行比较。检索单元52最初可以检索清单文件66的至少一部分，以确定表示68的特性。例如，检索单元52可以请求描述一个或多个适配集的特性的清单文件66的一部分。检索单元52可以选择具有客户端设备40的编码和显现能力可以满足的特性的表示68的子集(例如，适配集)。检索单元52然后可以确定适配集中的表示的比特率，确定当前可用的网络带宽量，并且从具有网络带宽可以满足的比特率的表示之一中检索分段。
一般而言，较高比特率表示可以产生较高质量的视频回放，而当可用网络带宽减少时，较低比特率表示可以提供足够质量的视频回放。因此，当可用网络带宽相对较高时，检索单元52可从相对高比特率表示中检索数据，而当可用网络带宽较低时，检索单元52可从相对低比特率表示中检索数据。以这样的方式，客户端设备40可以通过网络74流式多媒体数据，还适应网络74的变化的网络带宽可用性。
附加地或可替换地，检索单元52可以被配置为根据广播或多播网络协议，诸如eMBMS或IP多播，来接收数据。在这样的示例中，检索单元52可提交加入与特定媒体内容相关联的多播网络组的请求。在加入多播组之后，检索单元52可以接收多播组的数据，而无需向服务器设备60或内容准备设备20发出进一步的请求。当不再需要多播组的数据时，检索单元52可提交离开多播组的请求，例如停止回放或将频道改变到不同的多播组。
网络接口54可以接收并向检索单元52提供所选表示的分段的数据，检索单元52又可以向解封装单元50提供分段。解封装单元50可将视频文件的元素解封装为组成PES流，解封包化PES流以检索编码的数据，且依据编码的数据是音频还是视频流的一部分(例如，如由流的PES包报头所指示)，将编码的数据发送到音频解码器46或视频解码器48。音频解码器46解码编码的音频数据，并将解码的音频数据发送到音频输出42，而视频解码器48解码编码的视频数据，并将解码的视频数据发送到视频输出44，所述解码的视频数据可包括流的多个视图。
视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、检索单元52和解封装单元50中的每个都可以被实现为可适用的各种合适的处理电路中的任何一种，诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑电路、软件、硬件、固件或其任何组合。视频编码器28和视频解码器48中的每个可被包括在一个或多个编码器或解码器中，所述编码器或解码器中的之一可集成为组合的视频编码器/解码器(CODEC(编解码器))的一部分。同样，音频编码器26和音频解码器46中的每个可被包括在一个或多个编码器或解码器中，所述编码器或解码器中的之一可集成为组合的编解码器的一部分。包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、检索单元52和/或解封装单元50的装备可以包括集成电路、微处理器和/或无线通信设备，诸如蜂窝电话。
客户端设备40、服务器设备60和/或内容准备设备20可以被配置为根据本公开的技术进行操作。出于示例的目的，本公开描述了关于客户端设备40和服务器设备60的这些技术。然而，应该理解，内容准备设备20可以被配置为代替(或除了)服务器设备60来执行这些技术。
封装单元30可形成NAL单元，其包括标识NAL单元所属的程序的报头，以及有效负载，例如音频数据、视频数据或描述与NAL单相元对应的传输或程序流的数据。例如，在H.264/AVC中，NAL单元包括1字节的报头和可变大小的有效载荷。在其有效载荷中包括视频数据的NAL单元可以包括各种粒度级别的视频数据。举例来说，NAL单元可包含视频数据块、多个块、视频数据切片、或整个视频数据图像。封装单元30可从视频编码器28接收基本流的PES包形式的编码的视频数据。封装单元30可以将每个基本流与相应的程序相关联。
封装单元30还可以从多个NAL单元组装访问单元。一般而言，访问单元可以包括一个或多个NAL单元，用于表示视频数据帧以及与该帧相对应的音频数据(当这种音频数据可用时)。访问单元通常包括一个输出时间实例的所有NAL单元，例如一个时间实例的所有音频和视频数据。例如，如果每个视图具有每秒20帧(frames per second，fps)的帧速率，则每个时间实例可以对应于0.05秒的时间间隔。在该时间间隔期间，可以同时显现相同的访问单元(相同的时间实例)的所有视图的特定帧。在一个示例中，在一个时间实例中，访问单元可以包括编码的图像，其可以作为主编码的图像呈现。
因此，访问单元可包含公共时间实例的所有音频和视频帧，例如，与时间X相对应的所有视图。本公开还将特定视图的编码的图像称为“视图分量(view component)”。也就是说，视图分量可以包括特定时间的特定视图的编码的图像(或帧)。因此，访问单元可以被定义为包括公共时间实例的所有视图分量。访问单元的解码顺序不必与输出或显示顺序相同的。
媒体呈现可以包括媒体呈现描述(MPD)，其可以包含不同替代表示(例如，具有不同质量的视频服务)的描述，并且该描述可以包括例如编解码器信息、配置文件值、和级别值。MPD是清单文件的一个示例，诸如清单文件66。客户端设备40可以检索媒体呈现的MPD以确定如何访问各种呈现的电影片段。电影片段可以位于视频文件的电影片段框(MOOF框)中。
清单文件66(其可以包括例如MPD)可以通告表示68的分段的可用性。也就是说，MPD可以包括指示表示68之一的第一分段变得可用的挂钟时间的信息，以及指示表示68内的分段的持续时间的信息。以这样的方式，客户端设备40的检索单元52可以基于开始时间以及特定分段之前的分段的持续时间来确定每个分段何时可用。
在封装单元30基于接收到的数据将NAL单元和/或访问单元组装成视频文件之后，封装单元30将视频文件传递给输出接口32用于输出。在一些示例中，封装单元30可以本地存储视频文件或者经由输出接口32将视频文件发送到远程服务器，而不是将视频文件直接地发送到客户端设备40。输出接口32可以包括例如发送器、收发器、用于将数据写入计算机可读介质的设备，例如光驱、磁介质驱动器(例如，软盘驱动器)、通用串行总线(USB)端口、网络接口或其他输出接口。输出接口32将视频文件输出到计算机可读介质，例如诸如传输信号、磁介质、光介质、存储器、闪存驱动器或其他计算机可读介质。
网络接口54可通过网络74接收NAL单元或访问单元，并通过检索单元52将NAL单元或访问单元提供给解封装单元50。解封装单元50可将视频文件的元素解封装为组成PES流，解封包化PES流以检索编码的数据，且依据编码的数据是音频还是视频流的一部分(例如，如由流的PES包报头所指示)，将编码的数据发送到音频解码器46或视频解码器48。音频解码器46解码编码的音频数据，并将解码的音频数据发送到音频输出42，而视频解码器48解码编码的视频数据，并将解码的视频数据发送到视频输出44，所述解码的视频数据可包括流的多个视图。
图2是更详细说明图1的检索单元52的示例组件的集合的框图。在该示例中，检索单元52包括eMBMS中间件单元100、DASH客户端110和媒体应用112。
在这个示例中，eMBMS中间件单元100还包括eMBMS接收单元106、缓存104和代理服务器单元102。在此实例中，eMBMS接收单元106被配置为经由eMBMS接收数据，例如，根据T.Paila等人于2012年11月在tools.ietf.org/html/rfc6726.可得的网络工作组RFC 6726的“FLUTE-单向传输上的文件递送”中所描述的单向传输上的文件递送(File Deliveryover Unidirectional Transport，FLUTE)。也就是说，eMBMS接收单元106可经由广播从例如服务器设备60接收文件，服务器设备60可充当广播/多播服务中心(broadcast/multicast service center，BM-SC)。
当eMBMS中间件单元100接收文件数据时，eMBMS中间件单元可将接收的数据存储在缓存104中。缓存104可以包括计算机可读存储介质，诸如闪存、硬盘、RAM或任何其他合适的存储介质。
代理服务器单元102可以充当DASH客户端110的服务器。例如，代理服务器单元102可以向DASH客户端110提供MPD文件或其他清单文件。代理服务器单元102可以通告MPD文件中分段的可用时间，以及可以从中检索分段的超链接。这些超链接可以包括与客户端设备40相对应的本地主机地址前缀(例如，IPv4的127.0.0.1)。以这样的方式，DASH客户端110可以使用HTTP GET或partial GET请求从代理服务器单元102请求分段。例如，对于可从链接http：//127.0.0.1/rep1/seg3获得的分段，DASH客户端110可以构造包括对http：//127.0.0.1/rep1/seg3的请求的HTTP GET请求，并将该请求提交给代理服务器单元102。代理服务器单元102可以从缓存104中检索所请求的数据，并且响应于这样的请求将该数据提供给DASH客户端110。
图3是示出示例多媒体内容120的元素的概念图。多媒体内容120可以对应于多媒体内容64(图1)，或者存储在存储介质62中的另一多媒体内容。在图3的示例中，多媒体内容120包括媒体呈现描述(MPD)122和多个表示124A-124N(表示124)。表示124A包括可选的报头数据126和分段128A-128N(分段128)，而表示124N包括可选的报头数据130和分段132A-132N(分段132)。为了方便起见，字母N用于指定每个表示124中的最后一个电影片段。在一些示例中，在表示124之间可以有不同数量的电影片段。
MPD 122可以包括与表示124分离的数据结构。MPD 122可以对应于图1的清单文件66。同样，表示124可以对应于图1的表示68。一般而言，MPD122可以包括一般描述表示124的特性的数据，诸如编码和显现特性、适配集、MPD 122对应的配置文件、文本类型信息、相机角度信息、评级信息、特技模式信息(例如，指示包括时间子序列的表示的信息)、和/或用于检索远程时段的信息(例如，用于在回放期间将目标的通告插入媒体内容)。
当存在报头数据126时，报头数据126可以描述分段128的特性，例如，随机访问点(RAP，也被称为流访问点(SAP))的时间位置，分段128中的哪些包括随机访问点、分段128内到随机访问点的字节偏移、分段128的统一资源定位符(URL)或分段128的其他方面。当存在报头数据130时，报头数据130可以描述分段132的类似特性。附加地或可替换地，这些特性可以完全被包括在MPD 122中。
分段128、132包括一个或多个编码的视频样本，每个编码的视频样本可以包括视频数据的帧或切片。分段128的每个编码的视频样本可以具有相似的特性，例如高度、宽度和带宽要求。这样特性可以由MPD 122的数据来描述，尽管这种数据没有在图3的示例中示出。MPD 122可以包括3GPP规范所描述的特性，并添加了本公开中描述的任何或所有发信号通知的信息。
每个分段128、132可以与唯一的统一资源定位符(URL)相关联。因此，每个分段128、132可以使用诸如DASH的流式网络协议来独立检索。以这样的方式，诸如客户端设备40的目的设备可以使用HTTP GET请求来检索分段128或132。在一些示例中，客户端设备40可以使用HTTP partial GET请求来检索分段128或132的特定字节范围。
MPD 122可以包括表示媒体文件复杂度的数据，例如，每秒要处理的视频块的最大数量、每秒要处理的像素的最大数量、解码器实例的最大数量、和/或并发解码器实例的最大数量。在一些示例中，复杂度可以由视频配置文件、等级(tier)和/或级别值来表示。在一些示例中，配置文件、等级和/或级别值可以在参数集中发信号通知(附加地或替代地)，诸如视频参数集(video parameter set，VPS)、序列参数集(SPS)或图像参数集(PPS)。也就是说，图1的内容准备设备20可以构造MPD 122(或图1的清单文件66)来指示对应比特流的配置文件、等级和/或级别信息的值。
图4是示出示例视频文件150的元素的框图，其可以对应于表示的分段，诸如图3的分段128、132之一。每个分段128、132可以包括基本上符合图4的示例中所示的数据排列的数据。可以说视频文件150封装了分段。如上所述，根据ISO基本媒体文件格式及其扩展的视频文件将数据存储在一系列被称为“盒子”的对象中。在图4的示例中，视频文件150包括文件类型(file type，FTYP)框152、电影(movie，MOOV)框154、分段索引(segment index，sidx)框162、电影片段(movie fragment，MOOF)框164、和电影片段随机访问(moviefragment random access，MFRA)框166。尽管图4表示视频文件的示例，但是应当理解，根据ISO基本媒体文件格式及其扩展，其他媒体文件可以包括与视频文件150的数据类似构造的其他类型的媒体数据(例如，音频数据、定时文本数据等)。
文件类型框152通常描述视频文件150的文件类型。文件类型框152可以包括标识描述视频文件150的最佳用途的规范的数据。可选地，文件类型框152可以放置在MOOV框154、电影片段框164、和/或MFRA框166之前。
在一些示例中，诸如视频文件150的分段可以在文件类型框152之前包括MPD更新框(未示出)。MPD更新框可以包括指示与包括视频文件150的表示相对应的MPD将被更新的信息，以及用于更新MPD的信息。例如，MPD更新框可以提供用于更新MPD的资源的URI或URL。作为另一个示例，MPD更新框可以包括用于更新MPD的数据。在一些示例中，MPD更新框可以紧跟在视频文件150的分段类型(segment type，TYP)框(未示出)之后，其中STYP框可以定义视频文件150的分段类型。
在图4的示例中，MOOV框154包括电影报头(movie header，MVHD)框156、轨道(TRAK)框158和一个或多个电影扩展(movie extend，MVEX)框160。通常，MVHD框156可以描述视频文件150的一般特性。例如，MVHD框156可以包括描述视频文件150最初被创建的时间、视频文件150最后被修改的时间、视频文件150的时间刻度、视频文件150的回放持续时间的数据，或者一般描述视频文件150的其他数据。
TRAK框158可以包括视频文件150的轨道的数据。TRAK框158可以包括描述与TRAK框158相对应的轨道特性的轨道报头(TKHD)框。在一些示例中，TRAK框158可以包括编码的视频图像，而在其他示例中，轨道的编码的视频图像可以被包括在电影片段164中，电影片段164可以被TRAK框158和/或sidx框162的数据引用。
在一些示例中，视频文件150可以包括多于一个轨道。因此，MOOV框154可以包括与视频文件150中的轨道数量相等的多个TRAK框。TRAK框158可以描述视频文件150的相应轨道的特性。例如，TRAK框158可以描述对应轨道的时间和/或空间信息。当封装单元30(图3)在诸如视频文件150的视频文件中包括参数集轨道时，类似于MOOV框154的TRAK框158的TRAK框可以描述参数集轨道的特性。封装单元30可以发信号通知描述参数集轨道的TRAK框内的参数集轨道中序列级别SEI消息的存在。
MVEX框160可以描述对应的电影片段164的特性，例如发信号通知视频文件150除了被包括在MOOV框154内的视频数据(如果有的话)之外还包括电影片段164。在流式视频数据的情况下，编码的视频图像可以被包括在电影片段164中，而不是在MOOV框154中。因此，所有编码的视频样本可以被包括在电影片段164中，而不是在MOOV框154中。
MOOV框154可以包括数量等于视频文件150中电影片段164数量的MVEX框160。每个MVEX框160可以描述相应的一个电影片段164的特性。例如，每个MVEX框可以包括描述对应的一个电影片段164的时间持续时间的电影扩展报头(movie extends header，MEHD)框。
如上所述，封装单元30可将序列数据集存储在不包括实际编码的视频数据的视频样本中。视频样本通常可以对应于访问单元，该访问单元是特定时间实例的编码的图像的表示。在AVC的上下文中，编码的图像包括一个或多个VCL NAL单元，其包含用于构造访问单元和其他相关联的非VCL NAL单元的所有像素的信息，诸如SEI消息。因此，封装单元30可在一个电影片段164中包括可包含序列级别SEI消息的序列数据集。封装单元30可进一步发信号通知序列数据集和/或序列级别SEI消息的存在，其存在于与电影片段164之一相对应的MVEX框160之一内的电影片段164之一中。
SIDX框162是视频文件150的可选元素。也就是说，符合3GPP文件格式或其他这样的文件格式的视频文件不一定包括SIDX框162。根据3GPP文件格式的示例，SIDX框可用于标识分段的子分段(例如，包含在视频文件150内的分段)。3GPP文件格式将子分段定义为“一个或多个连续电影片段框的自含式集合，其具有对应的媒体数据框，并且包含由电影片段框引用的数据的媒体数据框必须在该电影片段框之后并且在包含关于相同的轨道的信息的下一个电影片段框之前”。3GPP文件格式还指示SIDX框“包含对由框记录的(子)分段的子分段的一系列引用。引用的子分段在呈现时间上是连续的。类似地，由分段索引框引用的字节在分段内总是连续的。引用的大小给出了引用的材料中的字节数的计数”。
SIDX框162通常提供表示被包括在视频文件150中的分段的一个或多个子分段的信息。例如，这样到信息可以包括子分段开始和/或结束的回放时间、子分段的字节偏移、子分段是否包括(例如，开始于)流访问点(SAP)、SAP的类型(例如，SAP是否是瞬时解码器刷新(instantaneous decoder refresh，IDR)图像、干净随机访问(clean random access，CRA)图像、断开链接访问(broken link access，BLA)图像等)、子分段中SAP的位置(就回放时间和/或字节偏移而言)等。
电影片段164可以包括一个或多个编码的视频图像。在一些示例中，电影片段164可以包括一个或多个图像组(broken link access，GOP)，每个图像组可以包括多个编码的视频图像，例如帧或图像。另外，如上所述，在一些示例中，电影片段164可以包括序列数据集。每个电影片段164可以包括电影片段报头框(MFHD，图4中未示出)。MFHD框可以描述相应电影片段的特性，诸如电影片段的序列号。电影片段164可以按照视频文件150中的序列号的顺序被包括。
MFRA框166可以描述视频文件150的电影片段164内的随机访问点。这可以有助于执行特技模式，诸如对由视频文件150封装的分段内的特定时间位置(即，回放时间)执行搜索。在一些示例中，MFRA框166通常是可选的，并且不需要被包括在视频文件中。同样，诸如客户端设备40的客户端设备不一定需要参考MFRA框166来正确地解码和显示视频文件150的视频数据。MFRA框166可以包括多个轨道片段随机访问(track fragment randomaccess，TFRA)框(未示出)，其数量等于视频文件150的轨道数量，或者在一些示例中，等于视频文件150的媒体轨道(例如，非提示轨道)的数量。
在一些示例中，电影片段164可以包括一个或多个流访问点(SAP)，诸如IDR图像。同样，MFRA框166可以提供SAP在视频文件150内的位置的指示。因此，视频文件150的时间子序列可以由视频文件150的SAP形成。时间子序列还可以包括其他图像，诸如从属于SAP的P帧和/或B帧。时间子序列的帧和/或切片可以排列在分段内，使得依赖于子序列的其他帧/切片的时间子序列的帧/切片可以被正确地解码。例如，在数据的分层排列中，用于预测其他数据的数据也可以被包括在时间子序列中。
图5是示出用于解码流式媒体数据的示例系统300的概念图。系统300包括应用302、多解码器310(其可以是MVD的示例)、图形处理单元(GPU)304、视频输出缓冲区306A-306N(视频输出缓冲区306)和视口308。在一些示例中，视频输出缓冲区306可以是如图6所示的单个缓冲区。
一般而言，系统300动态地使用用户的姿势信息和可能的其他交互数据来组合场景以进行适当的显现。具体地，系统300可以使用姿态信息从各种视频对象320A-320N(视频对象320)中选择要检索的相应视频流。具体地，系统300根据例如姿态信息从相应的视频对象320中检索同步单元322A-322N(同步单元322)。例如，系统300可以检索用户正直接观看的视口308的一部分的相对高质量的视频流，以及用户看不到的或在用户视角外围的视口308的一部分的相对低质量的视频流。每个视频对象320可以具有可用于检索的不同质量(例如，不同分辨率)。例如，可以在视野中应用较高分辨率的解码，而背景信息可以以较低质量解码。
一般而言，每个同步单元322包括要在相同的(或基本相同的)时间显现或组装的相应图像集。因此，通过检索相应的同步单元322，系统300可以确保检索到的同步单元以同步方式被解码、显现和/或组装。
系统300可以被配置为动态地使用可用的流式/网络访问比特率以及多解码器310的可用解码资源来最大化用户体验。因此，系统300可以动态地使用可用的网络和硬件解码资源来适应网络条件以及用户反馈。一个问题是应用302可以提供明确定义的接口，以便使用硬件解码资源。
不同质量或比特率的可用视频对象320可以由单个解码器实例解码。根据情况，视频对象320可以动态地共享资源。多解码器310可将视频对象320中的每个输出到可由应用302引用的视频输出缓冲区306中的单独相应之一，例如，以支持用于显现的基于GPU的修改。系统300可以相应地同步输出数据，例如，通过向多解码器310提供同步单元322。本公开的技术可以提供明确定义的多解码器接口/API(应用编程接口)以及由后续显现单元(例如，GPU 304的一部分或与GPU 304分离)引用每个解码器的输出的适当能力。通过这样做，可以有效地使用可用的硬件资源。解码器接口可以是编解码器不可知的，甚至可以在解码会话内使用不同的编解码器，例如，AVC、HEVC和/或AV1。
以这样的方式，图5的系统300表示用于解码媒体数据的设备的示例，该设备包括被配置为存储媒体数据的存储器，以及在电路中实现并通信地耦合到该存储器的一个或多个处理器，该一个或多个处理器被配置为确定两个或更多个解码器实例是否意图被同步，并且基于两个或更多个解码器实例意图被同步，控制两个或更多个解码器实例，以便能够在相同的呈现时间显现来自两个或更多个解码器实例中的每个解码器实例的解码的数据。
沉浸式媒体呈现通常需要显现大量的2D和3D资产，这些资产被组合在一起以向用户提供沉浸式体验。这些媒体资产中的许多可能需要对它们的至少一些组件进行硬件加速解码来显现。
如N18868所讨论的，2019年10月，日内瓦，CH的“关于沉浸式媒体的视频解码接口工作草案的考虑”，MVD通过应用编程接口(API)如OpenMAX IL或Android的MediaCodec API提供对解码硬件的访问。这些API允许应用创建和运行多个解码器实例，即使只有一个硬件解码器。
然而，这些API可能缺乏一些处理沉浸式媒体的能力。例如，API可能缺乏发现MVD的聚合处理能力的能力。例如，来自不同流的多个样本的逻辑分组用于同时解码目前是不可能的。在一些示例中，可以根据缓冲区报头中的nTimestamp参数来推断聚合，但是当解码这些相关的样本时，MVD组件没有信息来将延迟偏差保持为最小。此外，对不同解码器实例的调度的精细粒度控制可能是不可能的。
根据本公开的技术，对解码器API的抽象扩展为沉浸式媒体提供更好的支持，并解决了上述问题。例如，这些抽象扩展可以映射到OpenMAX IL和MediaCodec。
现在讨论MVD能力的发现。媒体解码硬件上的负载随着时间而变化，这取决于当时有多少解码器实例被实例化以及正在被解码的内容的特性。因此，对于诸如沉浸式媒体显现引擎的应用来说，能够发现诸如多解码器310的MVD的即时能力和资源可用性可能是重要的。
应用(例如，应用302)可使用以下函数来查询(和确定)特定编解码器组件的MVD的瞬时聚合能力。例如，在OpenMAX集成层中，组件表示单个功能块。组件可以是源、接收点(sink)、编解码器、过滤器、分离器、混合器或任何其他数据运算符。根据实现，组件可能表示硬件、软件编解码器、其他处理器或它们的组合。该能力信息可以用于对MVD的访问控制和/或用于基于资源可用性调整解码过程。
一个函数可以如下：
object queryCurrentAggregateCapabilities(string componentName,intflags)
componentName提供查询适用的MVD的媒体组件的名称。名称“全部”可用于指示查询不是针对特定组件，而是针对MVD的所有组件。
以下能力标志可以单独查询，也可以在单个函数调用中查询：
·CAP_INSTANCES：该标志指示此时可以为所提供的解码器组件实例化的解码器实例的最大数量。
·CAP_BUFFER_MEMORY：该标志指示此时用于与MVD组件的缓冲区交换的MVD上可分配的最大可用缓冲区大小。注意，该值独立于任何媒体组件，并全局应用于MVD。该值可以用字节表示。
·CAP_BITRATE：该标志查询被查询组件此时能够处理的最大编码的比特率，单位为比特/秒。
·CAP_MAX_SAMPLES_SECOND：该标志查询被查询的组件此时每秒能够处理的最大样本数。
·CAP_MAX_PERFORMANCE_POINT：该标志用于查询比特流的最大性能点，该比特流可由该解码器组件的新实例中的指示的组件解码。性能点具有以下参数：
оPICTURE_RATE：最大性能点的图像速率，单位为每秒图像数。
о高度：最高性能点的亮度样本高度
о宽度：最大性能点的亮度样本宽度
о比特深度：最大性能点的亮度样本的比特深度
应当注意，最大性能点的每个参数不一定表示该维度中的最大值。所有维度的组合可以构成最大性能点。
现在讨论解码器实例上的分组。沉浸式媒体资产的内容可能需要对多个分量进行解码，这些分量可被用于呈现引擎(例如，图5的GPU 304)同时用于重建和显现。解码器实例可以被分组在一起，以通知MVD将在MVD输出处同时提供解码的样本，例如用于稍后的同步和联合显现。
图6是示出示例解码引擎和相关的接口的框图。视频解码引擎200(其可以是MVD的示例)可以在输入视频解码接口206处接收元数据流(MD)202A-202N和基本流(ES)204A-204M。输入格式化单元208可以格式化基本流204A-204M，并将格式化的基本流输出到视频解码器实例210A-210M。视频解码器实例210A-210M可以解码格式化的基本流。时间锁定单元212可以基于例如group_id将基本流锁定在一起，group_id可以被包含在元数据流202A-202N中。输出格式化单元214可以格式化解码的流，并且输出视频解码接口可以输出元数据流(MD)218A-218N和解码的序列(DS)220A-220M，例如用于显现。
图7是示出示例视频解码器硬件引擎和示例视频解码器实例的框图。MVD 238可以包括视频解码器硬件引擎240。视频解码器硬件引擎240可以创建和控制视频解码器实例244A-244N。视频解码器硬件引擎240可以包括引擎控制接口242。引擎控制接口242可以是应用302用来控制视频解码器硬件引擎240的接口。每个视频解码器实例244A-244N可以分别包括输入视频接口246A-246N。视频解码器实例244A-244N可以分别通过输入视频接口246A-246N接收要解码的独立视频流。视频解码器实例244A-244N可以分别通过输出视频接口248A-248N输出解码的视频。
图8是示出根据本公开的技术的具有聚合输出缓冲区的示例MVD的概念图。MVD350包括解码器平台控制352、时钟组件354、解码器实例356、解码器实例358、解码器实例360和聚合缓冲区362。相同的组的所有解码器实例(例如，组#4的所有解码器实例356、解码器实例358和解码器实例360)可以连接到相同的时钟组件(例如，时钟组件354)用于同步。相同的组的所有解码器实例可以使用相同的时间戳偏移和测量单位，使得相同的时间戳值(例如，相同的时间戳偏移和测量单位)指示相同的组的解码器实例上的样本具有相同的呈现时间。呈现时间是可以显现解码的流的时间。例如，相同的组MVD 350的每个解码器实例(例如，解码器实例356、358和360)可以连接到相同的时钟(例如，时钟组件354)并使用相同的时间戳偏移和单位。相同的组的每个解码器实例的输出可以被聚合在聚合缓冲区362中，并且可以在相同的呈现时间被呈现。
当创建新的解码器实例时，(图5的)应用302可以通过提供该组的group_id将新的解码器实例分派给已经存在的实例的组。例如，应用302可以创建组4的新的解码器实例，以加入解码器实例356、358和360，并且可以向新的解码器实例提供group_id为4。group_id值为0指示MVD为该解码器实例分派并返回新的group_id。换句话说，如果应用302分派group_id为0的新的解码器实例，则该解码器实例不需要具有与解码器实例356、358和360相同的呈现时间，并且解码器平台控制352可以分派新的group_id(诸如5)给该新的解码器实例。
相同的组(例如，组4)的解码器实例可以使用单个输出缓冲区，诸如聚合缓冲区362。在这种情况下，聚合缓冲区362可以由MVD提供，并且由每个组件使用，以用相同的时间戳的解码的样本填充缓冲区。应用302可以指示在聚合缓冲区362中请求的交织类型。举例来说，解码的网格或点云流可在聚合缓冲区362中具有交织的几何、法线和颜色属性。该指示可以包括来自每个解码器组件的每个样本的格式、偏移和步幅，这将在本公开的后面讨论。在图6的聚合缓冲区362中描绘了交织，其中来自解码器实例356的输出以一个方向上的斜线示出，来自解码器实例358的输出以另一个方向上的斜线示出，来自解码器实例360的输出以交叉影线示出。
现在讨论函数。可以修改创建新的解码器实例的函数，以支持新的解码器实例可能属于的组(例如，组#4)的信令(例如，group_id)。配置函数可以被修改以发信号通知聚合输出缓冲区参数，这将在下面更详细地讨论。例如，应用302可以发信号通知聚合输出缓冲区参数。
OpenMAX IL函数包括OMX_GetHandle和OMX_SetConfig。在下文中，函数被定义为抽象函数，可以映射到OpenMAX、MediaCodec或任何其他类似的API。
object GetInstance(string component_name,int group_id＝-1)
object SetConfig(int instance_id,int parameter,object config_data)
对GetInstance函数调用的成功调用的结果可以包含解码器实例的标识符以及为解码器的实例分派或创建的group_id(如果请求的话)。默认(例如，当group_id等于0时)是解码器实例不属于任何已经建立的组，但是MVD350创建新的组。
SetConfig函数可以用新参数“CONFIG_OUTPUT_BUFFER”来调用，在这种情况下，SetConfig函数提供聚合缓冲区362的格式。
聚合缓冲区362的格式可以包括以下参数：
·sample_format指示每个样本的格式，可以是标量、2D向量、3D向量或4D向量。
·sample_type指示样本的每个分量的类型(例如，几何、颜色属性、法线等)。
·sample_stride指示解码器实例输出的两个连续样本之间的字节数。
·line_stride指示解码器实例输出的一行的第一字节和下一行的第一字节之间的字节数。
·buffer_offset，指示聚合缓冲区362中的偏移，解码器实例的输出帧应该从该聚合缓冲区362中写入。
现在讨论调度和输出控制。沉浸式应用可能需要比非沉浸式应用更精细的解码过程粒度控制。例如，应用302可能想要立即访问所有子帧、关于特定元数据可用性的通知、对解码器组件的输出的过滤、和/或对解码器实例的连续执行的时间抖动的限制。
这些功能可以通过解码器实例配置参数的定义来实现，这些参数可以被设置为解码器实例配置的一部分。例如，当定义新的解码器实例时，应用302可以确定新的解码器实例的解码器实例配置参数。
例如，GetParameter和SetParameter函数可以使用以下配置参数进行扩展：
·PARAM_SUBFRAME_OUTPUT。该参数可用于指示是否需要、期望或不允许子帧的输出。如果不允许输出子帧，则只有完整的解码的帧将被传递到聚合缓冲区362。
·PARAM_METADATA_CALLBACK。该参数可用于为特定元数据类型设置回调函数。支持的元数据类型长度列表取决于编解码器，并且可以为每个编解码器独立定义。
·PARAM_OUTPUT_CROP。该参数可用于指示在输出处(例如，显现器或显示设备)只期望解码的帧的一部分。解码器实例可使用此信息，通过尽可能丢弃未落在经裁剪的输出区域中的单元来智能地减少其解码处理。
·PARAM_MAX_OFFTIME_JITTER。该参数可用于发信号通知解码器实例的连续执行之间的最大时间量(以微秒计)。每当底层硬件组件在多个解码器实例之间共享时，该参数可能是相关的，这需要不同解码器实例之间的上下文切换。
现在讨论沉浸式应用的示例用法。例如，本公开的这一部分描述了在基于视频的点云压缩媒体(V-PCC)的示例中，如何将这些解码器接口扩展用于沉浸式媒体应用。附加的使用情况可以包括以同步方式显现手语翻译器的流和正在由手语翻译器翻译其声音的扬声器的流，或者以同步方式呈现体育赛事中的多个相机角度。
图9是示出了示例V-PCC解码器的框图。V-PCC流由几个子流组成，这些子流包括编码的几何、点云的每个属性、占用图和补丁信息的元数据流。例如，解复用器370可以对V-PCC流解复用。SPS配对单元372可将各种属性与序列参数配对。补丁序列解压缩单元374可以解压缩补丁序列。视频解压缩单元376、视频解压缩单元378和视频解压缩单元380可以解压缩不同的视频数据。几何/属性重建单元382可以重建几何和属性。例如，几何/属性重建单元312确定点云中的点的坐标，并重建与这些点相关联的属性。几何后处理单元384可以平滑这些点的位置。属性转移和平滑单元386可将属性转移到点云中的适当点，并平滑属性，输出重建的点云以供显现。根据点云的属性数量，解码V-PCC资产可能需要同时运行3到16个解码器，1个用于几何，1个用于占用图，每个属性(诸如颜色、法线等)一个。
V-PCC解码器可以将不同视频解码器的输出与帧精度紧密同步，以试图确保正确的点云重建。应用(例如，图5的应用302)可首先查询MVD的瞬时能力，以确定是否可解码V-PCC流的所有分量。例如，如果可用的解码能力不足以解码所有的属性，应用可能决定丢弃一些属性。应用302可以使用GetHandle函数开始创建解码器实例，并将所有解码器实例分派给相同的group_id。这可以通知MVD可能需要这些解码器实例的输出的紧密同步。
为了在GPU(例如，图5的GPU 304)上有效地促进3D点云重建，应用(例如，图5的应用302)可以请求该组中的不同解码器实例共享公共缓冲区(例如，图8的聚合缓冲区362)，该公共缓冲区可以驻留在GPU存储器中并且每帧被写入一次。在一些示例中，不是在公共缓冲区中交织样本，而是样本可以不被交织，因为在一些示例中，样本交织在重建点云之前可能是无用的。
应用(例如，应用302)可以动态地接收场景和姿态信息，并确定在某个时间点不是点云的所有部分都可见。该应用可以使用元数据信息来将点云的可见3D部分映射到补丁的集合和相应的2D区域中。该信息可以被传递到解码实例(例如，图8的解码器实例356、358和360)以请求将输出裁剪到所指示的2D区域。解码器实例可以进一步使用该信息，通过将解码限制到可见的2D区域来减少解码处理。
图10是示出根据本公开的用于对解码器实例进行分组的示例技术的流程图。设备可以确定两个或更多个解码器实例是否意图被同步(390)。例如，MVD 350的解码器平台控制352可以确定两个或更多个解码器实例中的每个解码器实例的组标识符(ID)是否相同。具有相同的组ID可以指示两个或更多个解码器实例将被同步的意图。例如，应用302可以分派两个或更多个打算与相同的组ID被同步的解码器实例。
基于所述两个或更多个解码器实例意图被同步，控制所述两个或更多个解码器实例，以便能够在相同的呈现时间显现来自所述两个或更多个解码器实例中的每个解码器实例的解码的数据(392)。例如，MVD 350可以向两个或更多个解码器实例中的每个解码器实例分派相同的时间戳偏移和单位。相同的时间戳值可以指示两个或更多个解码器实例中的每个解码器实例上的样本具有相同的呈现时间。MVD 350可以将两个或更多个解码器实例中的每个解码器实例耦合到相同的时钟。
此外，在一些示例中，MVD 350可以在图8的聚合缓冲区362中缓冲两个或更多个解码器实例的输出。聚合缓冲区362可以被配置为交织从两个或更多个解码器实例中的每个解码器实例输出的解码的数据。在一些示例中，MVD 350可以例如通过从应用302读取指令来确定聚合缓冲区362的参数。在一些示例中，参数包括样本格式的指示、样本的每个分量的类型的指示、输出的两个连续样本之间的字节数的指示、输出的一行的第一字节和下一行的第一字节之间的字节数的指示、或者输出帧应当被写入的偏移的指示中的一个或多个。在一些示例中，MVD 350可以基于这些参数来配置聚合缓冲区362。
在一些示例中，组ID是第一组ID，并且MVD 350可以从应用接收创建新的解码器实例的请求。该请求可以包括第二组ID。MVD 350可以确定第二组ID是否与第一组ID相同。MVD350可以创建新的解码器实例。MVD 350可以基于第二组ID与第一组ID相同来控制新的解码器实例，以便能够在与两个或更多个解码器实例中的每个解码器实例相同的呈现时间显现来自新的解码器实例的解码的数据。例如，MVD 350可以向新的解码器实例分派与两个或更多个解码器实例中的每个解码器实例相同的时间戳偏移和单位，将新的解码器实例耦合到与两个或更多个解码器实例中的每个解码器实例相同的时钟，和/或在与两个或更多个解码器实例相同的聚合缓冲区中缓冲新的解码器实例的输出。
在一些示例中，组ID是第一组ID，并且MVD 350可以从应用接收创建新的解码器实例的请求。该请求可以包括第二组ID。MVD 350可以确定第二组ID是否等于0。基于第二组ID为0，MVD 350可以创建新的解码器实例，并将该新的解码器实例分派给新的组ID。
在一些示例中，MVD 350可以确定新的解码器实例的参数。例如，MVD可以从应用302读取指令，以确定新的解码器实例的参数。这些参数可以包括以下中的一个或多个：是否需要、期望或不允许输出子帧的指示；为其设置回调函数的特定元数据类型的指示；在输出处是否只需要解码帧的一部分的指示；或者解码器实例的连续执行之间的最大时间量的指示。在一些示例中，MVD 350可以基于参数创建新的解码器实例。
在一些示例中，MVD 350可以确定多视频解码器的当前聚合能力。在一些示例中，响应于从应用302接收到查询，MVD 350可以确定多视频解码器的当前聚合能力。在一些实例中，MVD 350可向应用302发送多视频解码器的当前聚合能力的指示。
在一些示例中，当前聚合能力包括以下中的一个或多个：在创建可被实例化的解码器实例的最大数量的指示时可为所提供的解码器组件实例化的解码器实例的最大数量的指示；在创建可分配的最大可用缓冲区大小的指示时可在MVD上分配用于与MVD的组件进行缓冲区交换的最大可用缓冲区大小的指示；在创建被查询的组件能够处理的最大编码的比特率的指示时被查询的组件能够处理的最大编码的比特率的指示；在创建被查询组件能够处理的每单位时间最大样本数的指示时被查询组件能够处理的每单位时间最大样本数的指示；或者可由解码器组件的新实例中的指示的组件解码的比特流的最大性能点的指示。
在一些示例中，可由指示的组件解码的比特流的最大性能点的指示包括，最大性能点的每单位时间图像的图像速率、最大性能点的亮度样本的高度、最大性能点的亮度样本的宽度、以及最大性能点的亮度样本的比特深度。
在一些示例中，客户端设备40包括被配置为显示点云的显示设备。
以这样的方式，应用可能能够向MVD查询当前能力，来自不同流的多个样本可以被分组以由MVD同时解码，并且应用可能能够对MVD的不同解码器实例的调度施加精细的粒度控制。
本公开包括以下示例。
条款1.一种解码媒体数据的方法，所示方法包括：
由包括多视频解码器的客户端设备确定该客户端设备的多个组件的能力；由客户端设备基于多个组件的能力来控制对多个视频解码器的访问或调整解码过程中的一个或多个；以及由客户端设备基于控制访问或调整解码过程中的一个或多个来解码媒体数据。
条款2.根据条款1所述的方法，其中所确定的能力包括对于多个组件中的第一组件一次可以实例化的解码器实例的最大数量、在与多个组件进行缓冲区交换时可以分配的最大缓冲区大小、第一组件能够处理时的最大编码的比特率、第一组件能够处理时的每单位时间的最大样本数、或者在第一组件的新的解码器实例中第一组件能够解码的比特流的最大性能点。
条款3.根据条款2所述的方法，其中，最大性能点包括最大性能点的每单位时间图像的图像速率、最大性能点的亮度样本的高度、最大性能点的亮度样本的宽度、或最大性能点的亮度样本的比特深度中的一个或多个。
条款4.根据条款3所述的方法，其中，最大性能点包括最大性能点的每单位时间图像的图像速率、最大性能点的亮度样本的高度、最大性能点的亮度样本的宽度、以及最大性能点的亮度样本的比特深度。
条款5.根据条款1-4的任何组合的方法，还包括：确定解码器实例的标识符和解码器实例的组id。
条款6.根据条款1-5的任何组合的方法，还包括：确定输出缓冲区的格式。
条款7.根据条款6所述的方法，其中，输出缓冲区的格式包括每个样本的格式、每个样本的每个分量的类型、输出的两个连续样本之间的字节数、输出的一行的第一字节和输出的下一行的第一字节之间的字节数、或者输出缓冲区中输出帧应该从其开始写入的偏移中的一个或多个。
条款8.根据条款7所述的方法，其中，每个样本的格式包括标量、2D矢量、3D矢量或4D矢量之一。
条款9.根据条款1-8的任何组合的方法，还包括：确定解码器实例的配置。
条款10.根据条款9所述的方法，其中，所述配置包括以下一个或多个：指示子帧的输出是需要、期望或不允许；为元数据类型设置回调函数；指示在输出处只期望解码的帧的一部分；或者发信号通知解码器实例的连续执行之间每单位时间的最大时间量。
条款11.根据第10条所述的方法，其中，所支持的元数据类型的列表是依赖于编解码器的，并且是为每个编解码器独立定义的。
条款12.一种用于解码媒体数据的客户端设备，所述客户端设备包括：被配置为存储媒体数据的存储器；以及在电路中实现的一个或多个处理器，其被配置为：执行多视频解码器；和
条款13.根据条款12所述的客户端设备，还包括显示器，其被配置为显示解码的媒体数据。
条款14.根据条款12-13的任何组合的客户端设备，其中，设备包括相机、计算机、移动设备、广播接收器设备或机顶盒中的一个或多个。
条款15.根据条款12-14的任何组合的客户端设备，还包括多个视频解码器。
条款16.根据条款12-15的任何组合的客户端设备，还包括视频编码器。
条款17.一种用于解码媒体数据的装置，所述装置包括用于执行根据条款1-11的任何组合的一个或多个装置。
条款18.一种其上存储有指令的计算机可读存储介质，所述指令在被执行时使得处理器：执行多视频解码器；并执行根据条款1-11的任何组合。
在一个或多个示例中，所描述的功能可以用硬件、软件、固件或其任意组合来实现。如果以软件实现，这些功能可以作为一个或多个指令或代码存储在计算机可读介质上或在其上传输，并由基于硬件的处理单元执行。计算机可读介质可以包括计算机可读存储介质，其对应于诸如数据存储介质的有形介质，或者通信介质，包括例如根据通信协议便于将计算机程序从一个地方传送到另一个地方的任何介质。以这样的方式，计算机可读介质通常可以对应于(1)有形的非暂时性的计算机可读存储介质，或者(2)诸如信号或载波的通信介质。数据存储介质可以是能够被一个或多个计算机或一个或多个处理器访问以检索用于实现本公开中描述的技术的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。
作为示例而非限制，这样的计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或其他磁存储设备、闪存或可以用于存储指令或数据结构形式的所需程序代码并且可以由计算机访问的任何其他介质。同样，任何连接都被恰当地称为计算机可读介质。例如，如果使用同轴电缆、光纤电缆、双绞线、数字订户线路(DSL)或诸如红外线、无线电和微波的无线技术从网站、服务器或其他远程源传输指令，则同轴电缆、光纤电缆、双绞线、DSL或诸如红外线、无线电和微波的无线技术被包括在介质的定义中。然而，应当理解，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其他暂时性介质，而是指向非暂时性的有形存储介质。这里使用的磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地再现数据，而光盘用激光光学地再现数据。上述的组合也应该包括在计算机可读介质的范围内。
指令可以由一个或多个处理器执行，例如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其他等效的集成或分立逻辑电路。因此，这里使用的术语“处理器”可以指任何前述结构或者适合于实现这里描述的技术的任何其他结构。此外，在一些方面，本文描述的功能可以在被配置用于编码和解码的专用硬件和/或软件模块中提供，或者被结合在组合的编解码器中。同样，这些技术可以完全在一个或多个电路或逻辑元件中实现。
本公开的技术可以在多种设备或装备中实现，包括无线手机、集成电路(IC)或一组IC(例如，芯片组)。在本公开中描述了各种组件、模块或单元，以强调被配置为执行所公开的技术的设备的功能方面，但是不一定需要由不同的硬件单元来实现。相反，如上所述，各种单元可以结合适当的软件和/或固件被组合在编解码器硬件单元中，或者由互操作硬件单元的集合来提供，包括如上所述的一个或多个处理器。
已经描述了各种示例。这些和其他示例在以下权利要求的范围内。

Claims (30)

1.一种解码媒体数据的方法，所述方法包括：
由客户端设备确定两个或更多个解码器实例意图被同步，其中确定两个或更多个解码器实例意图被同步包括确定所述两个或更多个解码器实例中的每个解码器实例的组标识符ID相同；和
基于被确定为相同的所述两个或更多个解码器实例中的每个解码器实例的组ID，确定所述两个或更多个解码器实例意图被同步，控制所述两个或更多个解码器实例，以便能够在相同的呈现时间显现来自所述两个或更多个解码器实例中的每个解码器实例的解码的数据。
2.根据权利要求1所述的方法，其中，组ID是第一组ID，所述方法还包括：
从应用接收创建新的解码器实例的请求，所述请求包括第二组ID；
确定第二组ID与第一组ID相同；
创建新的解码器实例；和
基于第二组ID与第一组ID相同，控制新的解码器实例，以便能够在与所述两个或更多个解码器实例中的每个解码器实例相同的呈现时间显现来自新的解码器实例的解码的数据。
3.根据权利要求1所述的方法，还包括：
从应用接收创建新的解码器实例的请求，所述请求包括第二组ID；
确定第二组ID等于0；和
基于第二组ID等于0，创建新的解码器实例，并为新的解码器实例分派新的组ID。
4.根据权利要求1所述的方法，还包括：
向所述两个或更多个解码器实例中的每个解码器实例分派相同的时间戳偏移和测量单位，其中，相同的时间戳偏移和测量单位指示所述两个或更多个解码器实例中的每个解码器实例上的样本具有相同的呈现时间。
5.根据权利要求4所述的方法，其中，所述两个或更多个解码器实例中的每个解码器实例被耦合到相同的时钟。
6.根据权利要求1所述的方法，还包括：
在聚合缓冲区中缓冲所述两个或更多个解码器实例的输出，其中，聚合缓冲区被配置为交织从所述两个或更多个解码器实例中的每个解码器实例输出的解码的数据。
7.根据权利要求6所述的方法，还包括：
确定聚合缓冲区的参数，其中，参数包括以下中的一个或多个：
样本格式的指示；
样本的每个分量的类型的指示；
解码器实例的输出的两个连续样本之间的字节数的指示；
解码器实例的输出的一行的第一字节和下一行的第一字节之间的字节数的指示；或者
解码器实例的输出帧应从其写入的偏移的指示。
8.根据权利要求1所述的方法，还包括：
确定新的解码器实例的参数，其中，参数包括以下中的一个或多个：
需要、期望或不允许输出子帧的指示；
为其设置回调函数的特定元数据类型的指示；
在输出处只期望解码的帧的一部分的指示；或者
新的解码器实例的连续执行之间的最大时间量的指示。
9.根据权利要求8所述的方法，还包括：
基于参数来创建新的解码器实例。
10.根据权利要求1所述的方法，还包括：
确定多视频解码器的当前聚合能力。
11.根据权利要求10所述的方法，其中，确定多视频解码器的当前聚合能力响应于从应用接收到查询；所述方法还包括：
向应用发送多视频解码器的当前聚合能力的指示。
12.根据权利要求10所述的方法，其中，当前聚合能力包括以下中的一个或多个：
在创建能够被实例化的解码器实例的最大数量的指示时能够为所提供的解码器组件实例化的解码器实例的最大数量的指示；
在创建能够分配的最大可用缓冲区大小的指示时能够在多视频解码器(MVD)上分配用于与MVD的组件进行缓冲区交换的最大可用缓冲区大小的指示；
在创建被查询的组件能够处理的最大编码的比特率的指示时被查询的组件能够处理的最大编码的比特率的指示；
在创建被查询的组件能够处理的每单位时间最大样本数的指示时被查询的组件能够处理的每单位时间最大样本数的指示；或者
能够由解码器组件的新实例中的指示的组件解码的比特流的最大性能点的指示。
13.根据权利要求12所述的方法，其中，能够由指示的组件解码的比特流的最大性能点的指示包括：
最大性能点的每单位时间图像的图像速率；
最大性能点的亮度样本高度；
最大性能点的亮度样本宽度；和
最大性能点的亮度样本比特深度。
14.一种用于解码媒体数据的设备，所述设备包括：
存储器，被配置为存储媒体数据；和
一个或多个处理器，被实现在电路中并通信地耦合到存储器，所述一个或多个处理器被配置为：
确定两个或更多个解码器实例意图被同步，其中作为确定两个或更多个解码器实例意图被同步的一部分，所述一个或多个处理器被配置为确定所述两个或更多个解码器实例中的每个解码器实例的组标识符ID相同；和
基于被确定为相同的所述两个或更多个解码器实例中的每个解码器实例的组ID，确定所述两个或更多个解码器实例意图被同步，控制所述两个或更多个解码器实例，以便能够在相同的呈现时间显现来自所述两个或更多个解码器实例中的每个解码器实例的解码的数据。
15.根据权利要求14所述的设备，其中，组ID是第一组ID，所述一个或多个处理器还被配置为：
从应用接收创建新的解码器实例的请求，所述请求包括第二组ID；
确定第二组ID与第一组ID相同；
创建新的解码器实例；和
基于第二组ID与第一组ID相同，控制新的解码器实例，以便能够在与所述两个或更多个解码器实例中的每个解码器实例相同的呈现时间显现来自新的解码器实例的解码的数据。
16.根据权利要求14所述的设备，其中，所述一个或多个处理器还被配置为：
从应用接收创建新的解码器实例的请求，所述请求包括第二组ID；
确定第二组ID等于0；和
基于第二组ID等于0，创建新的解码器实例，并为新的解码器实例分派新的组ID。
17.根据权利要求14所述的设备，其中，所述一个或多个处理器还被配置为：
向所述两个或更多个解码器实例中的每个解码器实例分派相同的时间戳偏移和测量单位，其中，相同的时间戳偏移和测量单位指示所述两个或更多个解码器实例中的每个解码器实例上的样本具有相同的呈现时间。
18.根据权利要求17所述的设备，还包括通信耦合到所述两个或更多个解码器实例中的每个解码器实例的时钟。
19.根据权利要求14所述的设备，还包括：
通信地耦合到所述一个或多个处理器的聚合缓冲区，所述聚合缓冲区被配置为交织从所述两个或更多个解码器实例中的每个解码器实例输出的解码的数据。
20.根据权利要求19所述的设备，其中，所述一个或多个处理器还被配置为：
确定聚合缓冲区的参数，其中，参数包括以下中的一个或多个：
样本格式的指示；
样本的每个分量的类型的指示；
解码器实例的输出的两个连续样本之间的字节数的指示；
解码器实例的输出的一行的第一字节和下一行的第一字节之间的字节数的指示；或者
解码器实例的输出帧应从其写入的偏移的指示。
21.根据权利要求20所述的设备，其中，所述一个或多个处理器还被配置为基于参数来配置聚合缓冲区。
22.根据权利要求14所述的设备，其中，所述一个或多个处理器还被配置为：
确定新的解码器实例的参数，其中，参数包括以下中的一个或多个：
需要、期望或不允许输出子帧的指示；
为其设置回调函数的特定元数据类型的指示；
在输出处只期望解码的帧的一部分的指示；或者
新的解码器实例的连续执行之间的最大时间量的指示。
23.根据权利要求22所述的设备，其中，所述一个或多个处理器还被配置为：
基于参数来创建新的解码器实例。
24.根据权利要求14所述的设备，其中，所述一个或多个处理器还被配置为：
确定多视频解码器的当前聚合能力。
25.根据权利要求24所述的设备，其中，所述一个或多个处理器响应于从应用接收到查询来确定多视频解码器的当前聚合能力，并且其中所述一个或多个处理器还被配置为：
向应用发送多视频解码器的当前聚合能力的指示。
26.根据权利要求24所述的设备，其中，当前聚合能力包括以下中的一个或多个：
在创建能够被实例化的解码器实例的最大数量的指示时能够为所提供的解码器组件实例化的解码器实例的最大数量的指示；
在创建能够分配的最大可用缓冲区大小的指示时能够在多视频解码器(MVD)上分配用于与MVD的组件进行缓冲区交换的最大可用缓冲区大小的指示；
在创建被查询的组件能够处理的最大编码的比特率的指示时被查询的组件能够处理的最大编码的比特率的指示；
在创建被查询的组件能够处理的每单位时间最大样本数的指示时被查询的组件能够处理的每单位时间最大样本数的指示；或者
能够由解码器组件的新实例中的指示的组件解码的比特流的最大性能点的指示。
27.根据权利要求26所述的设备，其中，能够由指示的组件解码的比特流的最大性能点的指示包括：
最大性能点的每单位时间图像的图像速率；
最大性能点的亮度样本高度；
最大性能点的亮度样本宽度；和
最大性能点的亮度样本比特深度。
28.根据权利要求14所述的设备，还包括通信耦合到所述一个或多个处理器的显示设备，所述显示设备被配置为显示点云。
29.一种存储指令的非暂时性计算机可读存储介质，当所述指令由一个或多个处理器执行时，使得所述一个或多个处理器：
确定两个或更多个解码器实例意图被同步，其中作为确定两个或更多个解码器实例意图被同步的一部分，所述一个或多个处理器被配置为确定所述两个或更多个解码器实例中的每个解码器实例的组标识符ID相同；和
基于被确定为相同的所述两个或更多个解码器实例中的每个解码器实例的组ID，确定所述两个或更多个解码器实例意图被同步，控制所述两个或更多个解码器实例，以便能够在相同的呈现时间显现来自所述两个或更多个解码器实例中的每个解码器实例的解码的数据。
30.一种用于解码媒体数据的设备，所述设备包括：
用于确定两个或更多个解码器实例意图被同步的装置，其中作为确定两个或更多个解码器实例意图被同步的一部分，所述一个或多个处理器被配置为确定所述两个或更多个解码器实例中的每个解码器实例的组标识符ID相同；和
用于基于被确定为相同的所述两个或更多个解码器实例中的每个解码器实例的组ID，确定所述两个或更多个解码器实例意图被同步，控制所述两个或更多个解码器实例，以便能够在相同的呈现时间显现来自所述两个或更多个解码器实例中的每个解码器实例的解码的数据的装置。
CN202180008168.5A 2020-01-09 2021-01-08 用于流式媒体数据的多解码器接口 Active CN114930862B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202062959064P 2020-01-09 2020-01-09
US62/959,064 2020-01-09
US17/143,633 US11388427B2 (en) 2020-01-09 2021-01-07 Multiple decoder interface for streamed media data
US17/143,633 2021-01-07
PCT/US2021/012682 WO2021142246A1 (en) 2020-01-09 2021-01-08 Multiple decoder interface for streamed media data

Publications (2)

Publication Number Publication Date
CN114930862A CN114930862A (zh) 2022-08-19
CN114930862B true CN114930862B (zh) 2025-01-10

Family

ID=76763749

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180008168.5A Active CN114930862B (zh) 2020-01-09 2021-01-08 用于流式媒体数据的多解码器接口

Country Status (5)

Country Link
US (1) US11388427B2 (zh)
EP (1) EP4088476A1 (zh)
CN (1) CN114930862B (zh)
TW (1) TW202127897A (zh)
WO (1) WO2021142246A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11729395B2 (en) * 2021-11-26 2023-08-15 Huawei Technologies Co., Ltd. Methods and devices for extracting motion vector data from compressed video data
WO2024063920A1 (en) * 2022-09-20 2024-03-28 Qualcomm Incorporated Mixed media data format and transport protocol
US20240098130A1 (en) * 2022-09-20 2024-03-21 Qualcomm Incorporated Mixed media data format and transport protocol

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101132262B (zh) * 2006-08-21 2011-04-20 大唐移动通信设备有限公司 一种tdd系统同步harq的实现及数据传输的方法
WO2015197815A1 (en) * 2014-06-27 2015-12-30 Koninklijke Kpn N.V. Determining a region of interest on the basis of a hevc-tiled video stream
US10855741B2 (en) * 2015-08-06 2020-12-01 Sensormatic Electronics, LLC System and method for multiplexed video stream decoding in web browser
US9854375B2 (en) * 2015-12-01 2017-12-26 Qualcomm Incorporated Selection of coded next generation audio data for transport
GB2550912B (en) * 2016-05-27 2019-09-04 Canon Kk Method, device and computer program for encapsulating and parsing timed media data
US11140417B2 (en) * 2016-11-01 2021-10-05 Nokia Technologies Oy Apparatus, a method and a computer program for video coding and decoding
US10805650B2 (en) * 2017-03-27 2020-10-13 Qualcomm Incorporated Signaling important video information in network video streaming using mime type parameters
US11581022B2 (en) * 2019-05-29 2023-02-14 Nokia Technologies Oy Method and apparatus for storage and signaling of compressed point clouds
US11245899B2 (en) * 2019-09-22 2022-02-08 Tencent America LLC Method and system for single loop multilayer coding with subpicture partitioning

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Multi-Decoder Interface: Concepts and Requirements;Thomas Stockhammer;INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO;20190131;第3-7节 *

Also Published As

Publication number Publication date
TW202127897A (zh) 2021-07-16
US11388427B2 (en) 2022-07-12
US20210218976A1 (en) 2021-07-15
CN114930862A (zh) 2022-08-19
EP4088476A1 (en) 2022-11-16
WO2021142246A1 (en) 2021-07-15

Similar Documents

Publication Publication Date Title
US11405699B2 (en) Using GLTF2 extensions to support video and audio data
US20230283863A1 (en) Retrieving and accessing segment chunks for media streaming
CN113287323B (zh) 用于检索媒体数据的方法、客户端设备及计算机可读介质
CN112154672B (zh) 一种检索媒体数据的方法、设备及可读存储介质
JP6254291B2 (ja) Ｄａｓｈのロバストなライブ動作
CN114930862B (zh) 用于流式媒体数据的多解码器接口
US11184665B2 (en) Initialization set for network streaming of media data
JP2019520741A (ja) サンプルエントリーおよびランダムアクセス
CN117397227A (zh) 实时增强现实通信会话
CN110870323B (zh) 使用全向媒体格式处理媒体数据
US20220321897A1 (en) Transporting heif-formatted images over real-time transport protocol
CN118511534A (zh) 用于自适应流式传输的动态分辨率更改提示
US20240163461A1 (en) Transporting heif-formatted images over real-time transport protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant