UVC功能特性(Functional Characteristics)

功能特性

视频功能位于设备类层次结构中的接口级别。它由多个接口组成，这些接口将相关管道分组，共同实现视频功能的接口。

视频功能通过其视频接口进行寻址。每个视频功能都有一个单独的VideoControl（VC）接口，并且可以有几个VideoStreaming（VS）接口。VideoControl（VC）接口用于访问功能的设备控制，而VideoStreaming（VS）接口用于将数据流传输到功能中或从功能中传输出来。属于同一视频功能的单个VideoControl接口和VideoStreaming接口的集合称为视频接口集合（VIC。接口关联描述符（IAD）用于描述视频接口集合。

视频接口类

视频接口类将所有可以与USB兼容视频数据流交互的功能分组。所有在模拟和数字视频域之间转换的功能都可以是此类的一部分。另外，将兼容USB的视频数据流转换为其他兼容USB视频数据流的功能可以是此类的一部分。即使是通过USB控制的模拟视频功能也属于这一类。
事实上，要使视频函数成为此类的一部分，唯一的要求是它暴露一个VideoControl接口。尽管视频接口类中的大多数功能都支持一个或多个可选的VideoStreaming接口，用于消费或生成一个或更多视频数据流，但与该功能的进一步交互不是强制性的。视频接口类代码由USB分配。

视频接口子类和协议

视频接口类被划分为接口子类代码所标识的子类。本规范中定义了以下两个接口子类:

• 视频控制接口
• 视频流接口

以下功能子类用于接口关联描述符：

• 视频接口集合

视频功能拓扑

为了能够操纵视频功能的物理属性，必须将其功能划分为可寻址实体。
以下两个通用实体被识别：

• 单元
• 终端

单元提供了充分描述大多数视频功能的基本构建块。视频功能是通过将其中几个单元连接在一起而构建的。一个单元有一个或多个输入引脚和一个输出引脚，其中每个引脚代表视频功能内的一组逻辑数据流。

单元通过根据所需拓扑连接其I/O引脚连接在一起。单个输出引脚可以连接到一个或多个输入引脚（允许扇出）。但是，单个输入引脚只能连接到一个输出引脚。图形拓扑中不允许循环或环绕。

此外，还介绍了终端的概念。有两种类型的端子。输入终端（IT）是一个实体，代表视频功能内数据流的起点。输出终端（OT）表示数据流的终点。从视频功能的角度来看，USB端点是输入终端或输出终端的典型示例。它要么向视频功能（IT）提供数据流，要么消耗来自视频功能（OT）的数据流。同样，视频功能中内置的电荷耦合器件（CCD）传感器在视频功能的模型中被表示为输入端子。通过单个输入引脚或输出引脚连接到端子。
单元的输入引脚编号从一开始一直到单元上的输入引脚总数。输出引脚编号始终为一，终端有一个始终编号为1的输入或输出引脚。

通过I/O引脚传输的信息不一定具有数字性质。可以使用单元模型来描述全模拟甚至混合视频功能。
I/O引脚连接在一起这一事实（通过构造）保证了通过这些连接（模拟或数字）使用的协议和格式在两端都是兼容的。

视频功能中的每个单元都由其关联的单元描述符（UD）进行充分描述。单元描述符包含识别和描述单元所需的所有字段。同样，在视频功能中，每个终端都有一个终端描述符（TD）。此外，这些描述符提供了关于视频功能的拓扑结构的所有必要信息。它们充分描述了端子和单元是如何互连的。

本规范描述了以下类型的标准单元和终端，这些单元和终端被认为足以代表当今和不久的将来可用的大多数视频功能：

• Input Terminal 输入终端
• Output Terminal 输出终端
• Selector Unit 选择单元
• Processing Unit 处理单元
• Encoding Unit 编码单元
• Extension Unit 拓展单元

此外，还有一些特殊的端子扩展了基本输入和输出终端的功能。这些特殊终端支持特定于这些终端提供的扩展功能的附加终端描述符字段和请求。这些包含如下：

• Media Transport Terminal 媒体支持终端
• Camera Terminal 相机终端

本规范中定义的单元类型可在未来的修订中进行扩展，或通过配套规范进行扩展。例如，可以添加调谐器单元作为配套规范，以适应带有电视调谐器的设备。
在单元或终端内部，通过视频控制进一步描述功能。控制通常提供对特定视频属性的访问。每个控制都有一组属性，这些属性可以被操纵或提供有关控件行为的附加信息。控制具有属性，这些属性可能包括：

• Current setting
• Minimum setting
• Maximum setting
• Resolution 分辨率
• Size
• Default

考虑处理单元内部的亮度控制。通过发出适当的请求，主机软件可以获得亮度控件属性的值，例如，使用它们在用户界面中正确显示控件。通过设置亮度控制的当前设置属性，主机软件可以更改正在流式传输的视频的亮度。单元描述符、终端描述符和视频控制的集合给主机提供了视频功能的完整描述。通用类驱动应能够完全控制视频功能。当功能由扩展单元表示时，类驱动程序应允许通过传递机制访问供应商特定的扩展。

输入终端(Input Terminal)

输入终端（IT）用作视频功能的“外部世界”和视频功能内的其他单元之间的接口。它充当流入视频的数据的容器作用，它的功能是在提取该数据后表示传入数据的来源来自数据源。该数据可以包括与视频流相关联的音频和元数据。这些物理流被分组为一组逻辑流，离开输入终端通过单个输出引脚。

输入终端可以表示除USB OUT端点之外的视频功能的输入。摄像机上的CCD传感器或复合视频输入就是这种非USB输入的例子。然而，如果视频流通过USB OUT端点进入视频功能，则该端点与其关联的输入终端之间存在一对一关系。类特定的输出头描述符包含一个字段，该字段直接引用该输入终端。

主机需要同时使用端点描述符和输入终端描述符来全面了解输入终端的特性和功能。与流相关的参数存储在端点描述符中，控制相关参数存储在终端描述符中。
输入终端的符号如下图所示：

输出终端(Output Terminal)

输出终端（OT）用作视频功能内部单元与“外部世界”之间的接口。它是视频信息的出口，从视频功能中流出。它的功能是表示传出数据的汇点。视频数据流通过单个输入引脚进入输出终端。
输出终端可以表示除USB IN端点之外的视频功能的输出。内置在视频设备中的液晶显示器（LCD）屏幕或复合视频输出连接器就是这种输出的例子。然而，如果视频流通过USB IN端点离开视频功能，则该端点与其关联的输出终端之间存在一对一关系。
类特定的输入头描述符包含一个字段，该字段直接引用该输出端子。

主机需要同时使用端点描述符和输出终端描述符，以充分了解输出终端的特性和功能。与流相关的参数存储在端点描述符中，控制相关参数存储在终端描述符中。
输出终端的符号如下图所示：

相机终端(Camera Terminal)

摄像机终端（CT）控制传输视频流的设备组件的机械（或等效数字）功能。因此，它仅适用于具有可控镜头或传感器特性的视频捕捉设备。
相机终端始终表示为具有单个输出引脚的输入终端。它支持以下功能：

• Scanning Mode (Progressive or Interlaced)
• Auto-Exposure Mode
• Auto-Exposure Priority
• Exposure Time
• Focus
• Auto-Focus
• Simple Focus
• Iris
• Zoom
• Pan
• Roll
• Tilt
• Digital Windowing
• Region of Interest

对任何特定控制的支持都是可选的。焦点控制可以选择性地提供对自动设置的支持（具有开/关状态）。如果支持自动设置并设置为打开状态，设备将提供自动焦点调整，读取请求将反映自动设置的值。当处于自动模式时，尝试以编程方式设置Focus控制将导致协议STALL，错误代码为bRequestErrorCode=“错误状态”。当离开自动对焦模式（进入手动对焦模式）时，控制应保持在转换前的有效值。

选择单元(Selector Unit)

选择器单元（SU）从n个输入数据流中进行选择，并将它们原封不动地路由到单个输出流。它代表一个源选择器，能够在多个源中进行选择。每个源流都有一个输入引脚和一个输出引脚。
选择单元的符号如下图所示：

处理单元(Processing Unit)

处理单元（PU）控制通过它传输的视频的图像属性。它有一个输入和输出引脚。它支持以下功能:

用户控制(User Controls)

• Brightness
• Hue
• Saturation
• Sharpness
• Gamma
• Digital Multiplier (Zoom)

自动控制(Auto Controls)

• White Balance Temperature
• White Balance Component
• Backlight Compensation
• Contrast

其他(Other)

• Gain
• Power Line Frequency
• Analog Video Standard
• Analog Video Lock Status

对任何特定控制的支持都是可选的。特别是，如果设备支持白平衡功能，则应执行白平衡温度控制或白平衡组件控制，但不能同时执行。用户控制表示受用户偏好控制的属性，不受设备的任何自动调整。自动控制将支持自动设置（具有开/关状态）。如果支持特定控制的自动设置并将其设置为打开状态，则设备将提供控制的自动调整，并且对相关控制的读取请求将反映自动设置的值。当处于自动模式时，尝试以编程方式设置Focus控件将导致协议STALL，错误代码为bRequestErrorCode=“错误状态”。当离开自动模式时，相关控制应保持在转换前有效的值。
处理单元的符号如下图所示：

编码单元(Encoding Unit)

编码单元控制编码器的属性，该编码器对通过它传输的视频进行编码。它有一个输入引脚和多个输出引脚。它支持以下功能，这些功能可以在流媒体开始之前或之后使用。

• Select Layer
• Video Resolution
• Profile and Toolset
• Minimum Frame Interval
• Slice Mode
• Rate Control Mode

平均比特率控制
CPB大小控制

• Peak Bit Rate
• Quantization Parameter
• Synchronization and Long Term Reference Frame
• Long Term Reference Buffers
• Long Term Picture
• Valid Long Term Pictures
• LevelIDC
• SEI Message
• QP Range
• Priority ID
• Start or Stop Layer
• Error Resiliency

对编码单元控制的支持是可选的，仅适用于带有车载视频编码器的设备。选择层控制还允许控制支持多个流的联播传输的设备的单个流。单独的有效载荷可以专门化这些控件中的每一个的行为，以与相关编码器（例如H.264）定义的特征集对准。这种特殊行为在相关的有效负载规范中进行了定义。
编码单元的符号如下图所示：

拓展单元(Extension Unit)

扩展单元（XU）是本规范提供的将供应商特定构建块添加到规范中的方法。扩展单元可以有一个或多个输入引脚和一个输出引脚。尽管通用主机驱动程序将无法确定扩展单元中实现了什么功能，但它应向供应商提供的客户端软件报告这些扩展的存在，并提供从客户端软件向单元发送控制请求和从单元接收状态的方法。
扩展单元的符号如下图所示：

操作模型(Operational Model)

一个设备可以支持多种配置。在每个配置中可以有多个接口，每个接口可能具有备用设置。这些接口可以属于共同驻留在同一复合设备中的不同功能。在同一设备中可以存在多个独立的视频功能。属于同一视频功能的接口被分组到由接口关联描述符描述的视频接口集合中。如果设备包含多个独立的视频功能，则必须有多个视频接口集合（以及多个接口关联描述符），每个集合都提供对其相关视频功能的完全访问。

作为一个复合设备的例子，考虑一个配备了内置麦克风的台式相机。这样的设备可以被配置为具有一个处理音频功能的配置和控制的接口集合，而另一个接口集合处理其视频方面。其中一个是VideoControl接口，用于控制功能的内部工作，而另一个是视频流接口，用于处理从摄像机视频子系统接收的数据流量。

视频接口集合在支持多种操作模式的设备中可以是动态的，由于VideoControl接口及其相关的VideoStreaming接口构成了视频功能的“逻辑接口”，因此它们必须同时存在。更改设备的操作模式会将以前的视频接口集合替换为新的视频接口集，然后重新初始化主机软件。本规范没有为主机提供启动这种模式更改的机制，这种模式更改通常是通过设备上的物理交换机启动的。如前所述，视频功能位于设备类层次结构中的接口级别。以下部分介绍视频接口集合，其中包含单个VideoControl接口和可选的VideoStreaming接口，以及用于视频功能控制和数据流传输的相关端点。

视频接口集合(Video Interface Collection)

设备必须使用接口关联描述符来描述每个需要视频控制接口和一个或多个视频流接口的设备功能的视频接口集合。接口关联描述符必须始终作为设备的一部分返回响应GetDescriptor（configuration）请求完成配置描述符。接口关联描述符必须位于VideoControl接口及其关联的视频流接口（包括所有备用设置）之前。关联接口集中的所有接口编号必须是连续的。

视频控制接口(VideoControl Interface)

为了控制特定视频功能的功能行为，主机可以操作视频功能内的单元和终端。要使这些对象可访问，video功能必须公开一个VideoControl接口。此接口可以包含以下端点：

• 一个控制端点，用于操作单元和终端设置并检索视频功能的状态。此端点是必需的，默认端点点0用于此目的
• 返回状态的中断端点。此端点是可选的，但在某些条件下可能是强制性的。

VideoControl接口是访问视频功能内部的单一入口点。所有与视频功能的单元或终端内某些视频控件的操作有关的请求都必须指向视频功能的VideoControl接口。同样，所有与视频功能内部相关的描述符都是类特定VideoControl接口描述符的一部分。本规范定义了VideoControl接口的单个备用设置，默认备用设置为零。

控制端点(Control Endpoint)

视频接口类使用端点0（默认管道）作为使用类特定请求控制视频功能的标准方式。这些请求总是指向构成视频功能的一个单元或终端。

状态中断端点(Status Interrupt Endpoint)

USB视频控制接口可以支持一个可选的中断端点，以通知主机视频功能内不同可寻址实体（终端、单元、接口和端点）的状态。中断端点（如果存在）由整个视频接口集合用于向主机传递状态信息。它被视为VideoControl接口的一部分，因为它是集合的锚定接口。
此中断端点是强制性的，如果：

• 该设备支持静态图像捕获的硬件触发器
• 设备实现任何自动更新控制（支持设备启动的更改的控制）
• 该设备实现任何异步控制

中断数据包是一个可变大小的数据结构，取决于中断状态的发起者。bStatusType和bOriginator字段包含有关中断发起者的信息。bEvent字段包含有关触发中断的事件的信息。如果发起方是视频控制接口，则bSelector字段报告发出中断的控件的控制选择器。视频功能内的任何可寻址实体都可以是发起方。

bOriginator字段的内容必须根据bStatusType类型字段D3…0中的代码进行解释。如果发起方是VideoControl接口，则bOriginator字段包含导致中断发生的实体的终端ID或单元ID。如果bOriginator字段设置为零，则虚拟实体接口为发起方。这可用于向主机报告全局VideoControl接口的更改。如果发起方是VideoStreaming接口，则bOriginator字段包含VideoStreaming界面的接口编号。该方案是明确的，因为机组和终端不允许ID为零。
如果发起方是VideoControl接口，则bAttribute字段指示Control更改的类型。
bEvent字段的内容也必须根据bStatus Type字段的D3…0中的代码进行解释。如果发起方是VideoStreaming接口，则下表中定义了其他按钮按下事件。
对于所有发起者，都定义了一个控制更改事件。当主机启动或外部启动的控制更改发生时，支持此事件的控制将触发中断。只有当设备完成与控制更改相对应的操作时，才应发送中断。

如果以下任何情况属实，控制应支持控制变更事件:

• 控制状态可以独立于主机控制进行更改
• 当传输到设备（SET_CUR操作）时，从数据阶段开始到状态阶段结束，控制可能需要超过10ms的时间

如果需要控件来支持控件更改事件，则应为所有SET_CUR操作发送该事件，即使该操作可以在10ms限制内完成。该设备通过GET_INFO属性表明对任何特定控件的控制更改事件的支持。“控制权转移和请求处理”详细描述了控制权转移（请求）和控制权变更事件的相互作用。
下表规定了状态数据包的格式：


当发起方是视频流接口时，结构的其余部分是：

硬件触发器中断(Hardware Trigger Interrupts)

状态中断端点的定义用途之一是硬件触发器通知主机软件启动静态图像捕获。例如，当硬件检测到按下按钮时，状态中断端点将发出源自相关视频流接口的中断。触发中断的事件（按钮按下或释放）显示在中断数据包中。按钮的默认初始状态为“释放”状态。
设备必须指定是否支持硬件触发器，以及主机软件应如何响应硬件触发器事件。这些是在相关VideoStreaming接口内的类特定描述符中指定的。

静止图像捕获(Still Image Capture)

摄像机的一个共同特征是支持与视频流相关联的静止图像捕获。这可以通过编程软件触发器或硬件触发器启动。根据所使用的方法，静止图像帧可能必须与正在流式传输的视频帧具有相同的大小。有几种支持的捕捉静止图像的方法，设备必须在相关VideoStreaming接口内的类特定描述符中指定支持哪种方法。

• 方法一：当接收到硬件触发事件时，主机软件将从相关VideoStreaming接口中的活动视频管道中提取下一个可用视频帧。在这种情况下，硬件不会中断或改变视频流。对于这种方法，静止图像帧的大小始终与正在流式传输的视频帧的大小相同。
• 方法二：如果设备支持更高质量的静态图像，则可以选择在活动视频管道上传输静态图像特定的数据包。在这种情况下，主机软件将暂时暂停视频流，根据仍然探测/提交协商（取决于带宽可用性），发送VS_STILL_IMAGE_TRIGGER_CONTROL使用“传输静止图像”选项设置请求，并准备接收静止图像数据。该设备传输有效载荷标题中标记的静态图像数据。一旦接收到完整的静止图像，主机软件将恢复到原始的备用设置，并恢复视频流。
• 方法三：这种方法能够从专用的大体积静态图像管道捕获更高质量的静态图像。通过这样做，活动流将不间断地继续。这种方法包括两种情况
  在第一种情况下，主机软件从设备启动静止图像捕获。它通过发出带有“通过专用大容量管道传输静态图像”选项的VS_STILL_IMAGE_TRIGGER_CONTROL Set请求来完成此操作。发出请求后，主机将开始从批量静态图像接收静态图像相关VideoStreaming接口的端点。该设备捕捉高质量的静止图像，并将数据发送到批量静止图像端点。当传输正在发生时，VS_STILL_IMAGE_TRIGGER_CONTROL控件的bTrigger字段应保持为“通过专用大容量管道传输静态图像”。传输完成后，设备应将控制重置为“正常操作”，并通过状态触发控制更改中断中断端点。
  在第二种情况下，设备在检测到硬件触发后启动静止图像传输。当硬件检测到按下按钮时，状态中断端点将发出源自相关视频流接口的中断。如果所选格式描述符的bTriggerUsage字段设置为启动静态图像捕获，则设备应将VS_still_image_TRIGGER_CONTROL控件的bTriger字段设置为“传输静态图像通过专用大体积管道”。然后，主机软件应开始接收设备在接收到中断后捕获的静态图像数据。传输完成后，设备应将bTrigger字段重置为“正常操作”。主机软件可以通过发出带有“中止静止图像传输”选项的VS_STILL_IMAGE_TRIGGER_CONTROL请求来中止数据传输。在任何一种情况下，设备都应通过状态中断端点触发控制更改中断。
  下表总结了各种静态图像捕获方法的端点使用情况：
  

光学变焦与数字变焦(Optical Zoom vs Digital Zoom)

用户希望使用单个控制来遍历整个光学和数字变焦范围。此外，用户期望在实现全光学变焦之前不会应用数字变焦。建议设备强制执行此行为。附录D中提供了一个解决方案，详细说明了如何实现这一点。

视频流接口(VideoStreaming Interface)

VideoStreaming接口用于在主机和视频功能之间交换数字数据流，它们是可选的。一个视频功能可以有零个或多个与其相关的VideoStreaming接口，每个接口都可能携带不同性质和格式的数据。每个VideoStreaming接口可以有一个用于视频的等时或批量数据端点，以及一个用于与视频相关的静态图像的可选专用批量端点（仅适用于静态图像传输的方法3。请参见“静态图像捕获”）。这种构造保证了VideoStreaming接口和与端点相关的单个数据流之间的一对一关系。具有等时端点的VideoStreaming接口必须具有可用于更改接口和基础端点的某些特性的备用设置。备用设置的典型用途是提供一种方法来更改活动等时管道对USB的带宽要求。所有传输等时视频数据的设备必须为每个具有等时视频端点的VideoStreaming接口合并一个零带宽备用设置，并且它必须是默认的备用设置（备用设置为零）。设备向主机软件提供了通过切换到此备用设置来临时放弃USB带宽的选项。零带宽备用设置不包含VideoStreaming等时数据端点描述符。
包含用于流式传输的批量端点的VideoStreaming接口应仅支持备用设置零。在符合视频类规范的设备中，不允许使用包含批量终结点的其他备用设置。当批量端点仅用于静态图像传输方法3时，该限制并不禁止批量端点和等时端点的混合。在这种情况下，每个备用设置都将包括同步端点和批量端点的描述符。
如果具有等时端点的VideoStreaming接口支持一组视频参数组合（包括视频格式、帧大小和帧速率），这些组合在所有组合中使用显著变化的带宽，则建议VideoStreaming界面支持一系列（大于两个）具有变化的最大数据包大小的备用接口设置。通过这样做，主机将能够为给定的视频参数组合选择适当的替代设置，从而最有效地利用总线带宽。对于设备实现者来说，在每个替代设置中确定要提供的替代设置的数量和视频数据端点的最大分组大小的过程取决于实现，并且将取决VideoStreaming接口能够支持的视频参数组合范围内的带宽使用情况。

流带宽选择(Stream Bandwidth Selection)

视频流所需的带宽可以通过等于或大于功能流带宽的USB带宽来满足。这可以说明如下：

通过主机和设备之间的协商，实现了USB带宽的最佳分配，以满足功能的带宽要求。有关协商过程的完整描述，请参见"视频探测和提交控制"(“Video Probe and Commit Control”)。协商过程允许主机向设备提供首选流参数，而设备选择流参数的最佳组合并报告这些设置的最大带宽使用情况。主机将使用带宽信息来识别最佳备用接口。一旦分配了带宽，设备就负责选择直播参数。这些参数可能与协商过程中最初商定的参数不同。然而，在协商过程中，主机向设备提供指示选择直播流参数的优选方式的提示。一旦分配了带宽并开始流传输，就可以在不干扰当前流的情况下执行主机和设备之间的进一步参数协商。流参数被设置为一组，以便函数在尝试确定工作集时拥有所有可用信息。静止图像方法2使用类似的机制（参见第2.4.2.4节"静止图像捕获"）(Still Image Capture)

视频和静态图像示例（Video and Still Image Samples）

视频（或静止图像）样本是指格式特定解码器能够在单个传输中接受和解释的视频数据的编码块。根据所使用的视频格式，单个视频样本可能对应于或可能不对应于单个解码的视频帧。根据所使用的视频格式，单个视频样本可以对应于也可以不对应于单个解码的视频帧。例如，YUV视频流（不具有帧间压缩）将在视频样本和视频帧之间具有一对一的对应关系。然而，MPEG-2TS数据流将需要许多视频样本（或TS分组）来形成解码的视频帧。单个视频样本可能需要多个类别定义的有效载荷传输。相反，在单个有效载荷传输内可能存在一个或多个视频样本。在后一种情况下，每个有效载荷传输中必须有整数个固定大小的样本。VideoStreaming端点使用类定义的Payload Header封装数据。这种封装对于等时和批量端点类型上的Payload Transfer是相同的，并且适用于流和静态图像端点。
以下框图详细介绍了Payload Transfer中使用的协议分层和抽象：

• 从客户端到USB系统软件的I/O请求包（IRP）请求导致USB传输。
• 响应IRP完成，主机软件以有效载荷传输的形式转发数据。批量和等时处理程序隐藏了协议栈上层的传输类型差异。
• 视频样本处理器累积各个有效载荷传输以形成样本传输。

有效载荷传输由类定义的有效载荷头（见第2.4.3.3节“视频和静态图像有效载荷头”）和特定格式的有效载荷数据组成。

Figure 2-11 A Payload Transfer

样品批量传输(Sample Bulk Transfers)

样品同步传输（Sample Isochronous Transfers）

以下示例显示了与设备交换等时传输时视频采样、有效负载传输以及令牌和数据包之间的关系。实际视频样本大小和带宽使用情况（即每个有效载荷的最后事务）将根据设备和有效载荷的要求而变化。
图2-15给出了通过IN端点进行高速/高带宽传输的示例。

图2-16给出了OUT端点上的高速/高带宽传输示例。

图2-17给出了IN端点上的全速或高速传输示例。

图2-18给出了OUT端点上的全速或高速传输示例。

视频和静止图像有效载荷标头(Video and Still Image Payload Headers)

每个包含视频或静态图像样本数据的有效载荷传输都必须以有效载荷标头开头。
有效载荷标头的格式定义如下。


根据在上面的bmHeaderInfo字段中指定的位，以下字段可能包含也可能不包含在标头中。
这些字段按照在上面的位图头字段中指定的顺序，按照最低有效位优先的顺序。因为标头本身将来可能会被扩展，所以dwPresentationTime的偏移量也是可变的。设备将指示其是否支持类特定视频流描述符内的有效载荷格式描述符中的这些字段。参见第3.9.2.3节“有效载荷格式描述符”。

如果以下所有条件都成立，则dwPresentationTime和dwSourceClock字段的定期传输是强制性的。

• 该设备具有多个视频和/或音频源功能，并向主机发送音频和视频流。
• 视频和/或音频流是相互关联的，因此需要保持同步。
• 正在使用的流格式尚未包含时间戳和时钟参考信息（MPEG-2 TS是包含该信息的格式的示例）。
• 样本是视频帧（而不是静止图像帧）的一部分。

对于时间编码的有效载荷，所有视频帧可能需要dwPresentationTime和dwSourceClock字段。有关详细信息，请参阅相应的有效载荷规范。
这些时间信息字段允许主机软件重建源时钟，以支持独立数据管道（音频、视频等）之间的高质量同步以及数据源和信宿之间的速率匹配，如以下部分所述。

流同步和速率匹配(Stream Synchronization and Rate Matching)

为了正确同步来自媒体源的多个音频和视频流，媒体源必须（向媒体接收器）提供其本地流延迟、周期性时钟参考信息，以及媒体接收器确定每个流中样本的正确呈现时间（相对于其他流）的方法。

延迟(Latency)

媒体源需要报告其内部延迟（从数据采集到总线上的数据传输的延迟）。此延迟反映了流源执行的任何缓冲、压缩、解压缩或处理所引入的滞后。如果没有每个流的延迟信息，媒体接收器（或呈现设备）就无法正确关联每个流的呈现时间。

In the case of a video source, this means that the source must guarantee that the portion of a
sample fully acquired as of SOFn (Start Of Frame n) will have been completely sent to the bus as
of SOFn+. Latency  is the source’s internal delay expressed in number of USB frames
(milliseconds). For high-speed endpoints, the resolution increases to 125 microseconds, but the
delay will continue to be expressed in number of USB frames. Every VideoStreaming interface
must report this latency value. See the description of the wDelay parameter in section 4.3.1.1,
“Video Probe and Commit Controls”. By following these rules, phase jitter is limited to ±1
millisecond. It is up to the video sink to synchronize streams by scheduling the rendering of
samples at the correct moment, taking into account the internal delays of all media streams being
rendered.

时钟参考(Clock Reference)

Clock reference information is used by a media sink to perform clock rate matching. Rate
matching refers to the synchronization of the media sink’s rendering clock with the media
source’s sampling clock. Without clock rate matching, a stream will encounter buffer overrun or
underrun errors. This has not been a problem with audio streams due to the relative ease of
performing audio sample rate conversion. However, sample rate conversion is significantly more
difficult with video, so a method for rate matching is required.
To understand the problem of clocks running at slightly different rates, consider the following
example. For simplicity, assume that video buffers can be filled instantaneously, and that there is
one buffer available to be filled at any given time within the video frame interval. Also assume
that the two crystals governing the source and rendering clocks operate with 100ppm (parts per
million) accuracy. The accuracy value is a ratio that can be applied such that for every frame, the
clock will drift by a fraction of the frame that is equal to the ratio. In other words, two clocks
with accuracy of 100ppm could have a worst case drift relative to each other of 1/5,000th of a
frame (two clocks at opposite extremes of their valid operating range for a cumulative error ratio
of 2 * 100/1,000,000). Therefore, a frame glitch will occur once every 5,000 frames. At a frame
rate of 30 fps, this would equate to a glitch every 166.67 seconds. At a frame rate of 60 fps, it’s
worse, with one glitch every 83.3 seconds.
Frame glitches can be postponed, but not avoided, by adding additional buffers to hold video
frames before they are rendered. If the source clock is running slower than the rendering clock,
the buffer underrun could only be postponed by letting the extra buffers fill to a certain threshold
before rendering, resulting in unacceptable latency. Once the first glitch occurs, the extra buffers
are effectively useless, since the behavior will degrade to the single-buffer case from that point
onward.
This specification assumes that in all cases, the media sink has no control over the media source
clock, and that the source and sink do not “slave” to a common clock (the bus clock lacking
sufficient resolution). Also, due to cost constraints, additional isochronous endpoints to
communicate clock rate information will not be used. Therefore, this specification requires that a
video stream include clock reference information that can be used to adjust the rendering clock
rate. The clock reference information may be encapsulated in a transport stream, or it may be
provided via an optional field in each payload header. This field becomes required in the latter
case.

呈现时间(Presentation Time)

对于固定速率流，可以从数据流导出呈现时间。对于固定费率音频流（例如，PCM），媒体接收器可以从流偏移中导出呈现时间（通常是自捕获开始以来的字节数）。对于可变速率流，每个样本必须
附有演示时间戳。媒体接收器负责转换将时间戳转换为本机单元，并调整时间戳以考虑本地时钟偏移
流启动，并考虑源流延迟。即使视频流可能以固定的帧速率到达媒体接收器，如果它们受到可变速率压缩和编码，它们也不被视为固定速率流，并且将需要样本上的时间戳。

动态帧间隔支持(Dynamic Frame Interval Support)

为了适应不同的环境条件，例如变化的照明条件，视频设备（例如相机）可能需要动态地改变帧间隔和传感器曝光时间，以在流式传输时保持可接受的图像质量。
在对应VideoStreaming接口的视频数据管道的总线带宽已经分配并且流已经开始之后，数据源可以动态地改变帧间隔（以及对应的帧速率），只要新的帧间隔不需要比最初分配的更大的总线带宽。数据宿将基于视频有效载荷报头中包括的呈现时间戳（PTS）信息来确定新的帧间隔。

设备启动的动态格式更改支持(Device Initiated Dynamic Format Change Support)

某些设备，例如包含磁带媒体传输的设备，能够在进行流式传输时动态更改流式传输到主机的视频格式。由于新视频格式可能具有与旧格式不同的总线带宽要求，因此必须将格式更改通知主机，并允许主机执行支持新视频格式所需的重新配置和总线带宽重新分配。该设备通过VideoStreaming输入标头的bmInfo字段指示其对动态格式更改事件的支持。参见第3.9.2.1节“输入标题描述符”。
当发生动态格式更改事件时，将执行以下步骤：

• 设备检测到动态格式更改（在进行流传输时）。
• 设备开始向主机发送空数据有效载荷，并在视频中设置错误位流有效载荷报头。
• 设备将流错误代码控制设置为“格式更改”（见第4.3.1.7节“流错误代码控制”）。
• 主机通过带有的VS_PROBE_CONTROL请求查询新流状态GET_CUR属性（参见4.3.1.1“视频探测和提交控制”）。
• 如果主机可以接受新格式，则会发出VS_COMMIT_CONTROL请求
• 具有SET_CUR属性，并且在必要时通过备用接口选择标准请求。如果新格式不可接受，则主机
  将与流PROBE/COMMIT控件协商新的格式。

数据格式类(Data Format Classes)

为了主机处理传入和传出的数据包，USB视频类（UVC）支持的各种视频格式可分为两大类：

• 基于帧的视频格式——这些视频格式要求在带外传输帧/样本边界信息。这种格式的示例是未压缩视频（以各种YUV变体格式化）、MJPEG和DV。对于这些格式，必须支持UVC有效载荷标头中的FID（以及可选的EOF）位。

• 基于流的视频格式——这些视频格式具有在频带内传输的帧/样本边界信息。这种格式的示例是MPEG-2TS、MPEG-2PS和MPEG-1系统流。对于这些格式，FID和EOF位是可选的。如果使用，这些比特允许发送方识别流动接收器通常会使用该信息向解码器提供数据，该解码器的延迟比可能的低缓冲区充满度单独用于触发缓冲区完成（见第4.3.1.1节“视频探测和提交控制”）。

临时编码视频格式–虽然这些视频格式具有在频带内传输的帧/样本边界信息，但它们通常由主机作为帧或子帧进行管理。EOF和EOS位需要向主机指示这些边界，因此主机可以在这些边界上生成时间戳并触发缓冲区完成。时间编码视频格式的示例是H.264和VP8。
以下内容由视频格式分类所依据的格式类别确定：

• 默认的传入/传出数据处理算法
• UVC有效载荷标头中默认支持的位字段（BFH[0]）

以下内容由特定的视频有效载荷格式决定：

• 格式描述符类型

• 帧描述符类型（如果需要）

• 支持UVC有效载荷标头中的时间信息字段

控制传输和请求处理(Control Transfer and Request Processing)

视频类规范的控制传输（或请求）机制建立在以下部分之上5.5，“控制权转让”；8.5.3，“控制权转让”；9.2.6，“请求处理”；和9.3，“USB通用串行总线规范2.0版（USB 2.0规范）的“设备请求”。这些章节描述了控制权转移的时间安排和错误处理，但没有规定
使用中断管道控制传输完成的方法。以下段落描述视频类上下文中的控制传输操作，包括状态的使用
中断管道以提供设备内状态更改的通知。
控制传输至少有两个事务阶段：设置和状态。控制传输可以选择性地包含设置阶段和状态阶段之间的数据阶段。设置阶段包含寻址特定实体、指定所需操作、以及确定所需操作所需的所有信息，并为可选的Data阶段做准备。数据阶段可以是主机到设备（OUT事务），或设备到主机（IN事务），具体取决于通过bmRequestType和bRequest字段设置阶段。

In the context of the Video Class specification, SET_CUR requests will always involve a Data
stage from host to device, and GET_* requests will always involve a Data stage from device to
host. Although none are defined currently, an exception to this rule would be a SET_CUR
request where the bRequest field contains all information necessary to place the device into a
known state. However, “toggle” requests without a Data stage are explicitly disallowed.
The device shall use protocol STALL (not function stall) during the Data or Status stages if the
device is unable to complete the Control transfer (see section 8.5.3.4 of the USB Specification
Revision 2.0). Reasons for protocol STALL include unsupported operations, invalid target entity,
invalid control selector, unexpected Data length, or invalid Data content. The device shall update
the value of Request Error Code Control, and the host may use that control to determine the
reason for the protocol STALL (see section 4.2.1.2 “Request Error Code Control”). The device
must not NAK or STALL the SETUP transaction.
Typically, the host will serialize Control Transfers, meaning that the next Setup stage will not
begin until the previous Status stage has completed. However, in situations where the bus has
experienced errors, a Setup transaction may be sent before the completion of a previous control
transfer. The device must abandon the previous control transfer.
Due to this command serialization, it is important that the duration of control transfers (from
Setup stage through Status stage) be kept as short as possible. For this reason, as well as the
desire to avoid polling for device status, this specification defines an interrupt status mechanism
to convey status changes independently of the control transfers that caused the state change. This
mechanism is described in section 2.4.2.2, “Status Interrupt Endpoint”. Any control that requires
more than 10ms to respond to a SET_CUR request (asynchronous control), or that can change
independently of any external SET_CUR request (Autoupdate control), must send a Control
Change status interrupt. These characteristics will be reflected in the GET_INFO response for
that control (see 4.1.2, “Get Request”).
If a SET_CUR request is issued to an Asynchronous Control with unsupported operations,
invalid target entity, unexpected data Length or invalid data content, the device shall use
protocol STALL since the device is unable to complete the Control Transfer (see section 8.5.3.4
of the USB Specification Revision 2.0). The device shall update the value of the Request Error
Code Control (see section 4.2.1.2 “Request Error Code Control”).
In the case of a SET_CUR request with valid parameters to an Asynchronous Control, the
Control Transfer operation shall enter the Status stage immediately after receiving the data
transferred during the Data stage. Once the Status stage has successfully completed, the device
shall eventually send a Control Change Interrupt that will reflect the outcome of the request:
 If the request succeeded, the Control Change Interrupt will advertise the new value (see
section 2.4.2.2 “Status Interrupt Endpoint”).
 If the request could not be executed, the device shall send a Control Change Interrupt
using the Control Failure Change mechanism to describe the reason for the failure (see
Table 2-1 in section 2.4.2.2 “Status Interrupt Endpoint” and Figure 2-23 in section 2.4.4
“Control Transfer and Request Processing”).
The amount of time between the end of a successful Status stage and the Control Change
interrupt is implementation specific. For instance, a tape transport might take 3-5 seconds to
completely change state, so the Control Change interrupt would be sent within 3-5 seconds.
The following flow diagrams show the Setup, Data and Status stages of SET_CUR Control
Transfers for controls supporting one of the two legal bit combinations with the D1 (SET) bit
enabled. These are described because they show the relationship between a SET_CUR request
and the resulting state change.