Showing Posts From

Uvc

《Microsoft Skype for Business H.264 Video Encoder Specification》学习笔记

对于要通过Mircosoft的Teams或者Skype For Business认证的视频会议系统，要使用H.264来进行图像传输的情况，就需要对图像视频压缩所使用的H.264编码器进行Teams和Skype For Business的认证，才能打上对应的认证Logo。而这个对于H.264编码器进行认证的规范指导文件就是《Microsoft Skype for Business H.264 Video Encoder Specification》，文档编号为H105958。 - 注意：这个规范文件和认证流程针对的是单纯的H.264编码器，而不是整个摄像头系统。所有的指标、功能性要求以及进行测试和验证的流程，都是针对链路上所使用的H.264编码器。 在该规范文档中，把要通过Teams和Skype For Business认证的H.264编码器分为以下三种情况： - Category 1：USB Camera内部包含的H.264编码器； - Category 2：笔记本、平板电脑和手机中集成的摄像头内部自带的H.264编码器； - Category 3：通用的H.264硬件编码器。 如同其他所有的Teams认证的规范文档，通过Teams的H.264 Encoder的认证，同样存在Standard和Premium两种认证规格，后者的指标和功能要求更加严格一些。而只要通过Standard的指标要求，就可以打上Teams的认证Logo。 无论对于Standard还是Premium类型的认证而言，对于H.264编码器的基本要求就是能够支持UCConfig Mode 1，也就是需要H.264编码器至少能够支持SVC的Temporal Layer。所以那些不支持SVC模式的编码器就可以洗洗睡了：（4.1）Encoders must support UCConfig Mode 1 and the corresponding requirements outlined below in order to participate in the Skype for Business Logo program。另外要通过这个认证，需要编码器支持的最大分辨率至少要是1080P。 - UCConfig Mode 1的定义：SVC temporal scalability with hierarchical P with Simulcast (number of simulcast streams >= 1). H.264编码器进行Teams认证的测试流程 微软为了进行这个H.264编码器的一致性测试，专门提供了一个测试工具：Microsoft Skype Video Encoding Conformance (MLVEC) toolkit。这个工具主要分为两个部分：H.264的码流产生器（BitStream Generator）和码流一致性验证器（Conformance Verifier）。 !Untitled.png BitStream Generator： - BitStream Generator的输入有两个：一个是Skype Business进行测试认证的录像片段（不同分辨率、不同场景），也就是上面的Skype Logo Clips；另外一个就是Config Scripts，在其中定义了测试编码器需要设置编码器的参数和工作流程，编码器按照该脚本的命令进行工作。 - 对于USB Camera而言，要进行这个测试肯定就没那么容易了，因为没有办法很容易的把这些认证录像片段方便的送入USB Camera的编码器中进行编码。所以针对这个问题，文档中明确规定，对于这类USB Camera的认证而言，Camera的生产厂家，要自己想办法（例如通过一个专门的开发板）把测试录像片段送入Camera内部的编码器，并按照要求自行完成码流的生成。（5.3）Tethered USB webcams usually don’t have a possibility to feed the pre-recorded clips into the hardware encoder. Due to this we are currently requiring these tests to be run on a development kit which allows feeding the pre-recorded clips into the encoder. - BitStream Generator的输出就是各种不同测试参数状态下的码流文件，以及运行中所产生的的log。 Conformance Verifier： - Conformance Verifier读取BitStream Generator所产生的码率文件和运行log，基于其内部的功能性分析工具进行判断，看编码器所产生的的码率及其运行过程的指标性数据，是否符合Standard和Premium的标准，给出最终的测试判定报告。 H.264编码器认证需求 - Aspect ratios and image resolutions：对于编码器能够支持的图像长宽比和分辨率的要求，三个Category的编码器有不同的长宽比和分辨率编码测试要求； !Untitled.png !Untitled.png - Frame rate：不同分辨率下的编码帧率要求 !Untitled.png - Video preview：对于Preview视频的输出需求。内置H.264编码器的USB Camera需要能够同时提供一路小分辨率（640x480或者640x360 30fps）的YUV图像作为Preview的功能。 - 不是很清楚对于USB UVC camere而言，如何能够在传输H.264 main Streaming的同时，把这个YUV的preview video也传过去？具体应该怎么做？ - Encoder latency：编码延迟指标，对于编码进行编码导致的Pipeline延迟不应该影响帧率，或者造成图像在传输和解码回放时出现抖动。 - Dynamic resolution change：编码器应该能够支持在Pipelien的编码器正常运行的过程中，动态的调整分辨率。且有一定的调整延迟指标。 - Dynamic profile/level change：编码器应该能够支持在Pipelien的编码器正常运行的过程中，根据具体情况动态调整编码的profile和level的设置。且有一定的调整延迟指标。 - Dynamic add/remove temporal layers：对于支持SVC扩展的编码器而言，能够在编码过程中，动态的增加或者删除帧率扩展层（temporal layer），且有一定的调整延迟指标。 - Bitstream Conformance：这部分对于编码器在各种模式下输出的码率的设置有明确的的要求。 - Quality Conformance：对编码器产生的码率，经过解压缩以后的图像质量有明确的要求。 其他 - 对于USB Camera而言，如果要通过Teams的这个H.264 Video Encoder认证，需要在USB Camera中支持UVC1.5规范：实际上UVC1.1已经可以通过Frame Based的方式来支持H.264的Payload了，但是把H.264当成一种独立的payload来进行支持的话，只能使用UVC1.5规范。不过UVC1.5的兼容性不大好，只有在Win8及其以后的系统中才能够支持。 参考资料： - Microsoft Skype for Business H.264 Video Encoder Specification，H105958 - Unified Communication Specification for H.264 AVC and SVC UCConfig Modes, V1.1

UVC的视频格式协商流程-Video Probe&Commit Request

UVC设备与Host之间进行视频传输格式协商的通信流程，是Host与UVC设备的Video Streaming Interface来进行通信的。两者之间的通信数据包的格式如UVC协议SET/GET Request结构解析一文中的VideoStreaming Requests部分所述。 Probe&Commit工作流程 Video Streaming Interface在Host和UVC camera之间使用一种Probe+Commit的方式来实现两者之间传输的视频格式协商流程的实现。 大致的流程是： - UVC设备的USB描述符中，在Video Streaming Interface的声明上，包含了该设备所能够支持的所有YUV、MJPEG以及H.264等各种格式、不同分辨率帧率视频的列表，后续Host主要就是从这个列表中进行选择； - 在协商过程中，Host端基于USB描述符中的format和分辨率、帧率等信息，以及自己的支持情况，选择一组期望的视频格式参数，通过Video Probe Control/SET_CUR命令发送给Device； - Device收到以后Host发过来的视频格式参数后，对这个参数进行检查，看自己能不能完整支持： - 如果能够支持的话，就在这个参数结构中保持Host发过来的参数； - 如果无法支持就把对应的参数项设置为0，这样Host读回之后就会知道Device无法支持这个设置选项； - 然后Host端再通过Video Probe Control/GET_CUR命令把Device检查过的参数读回来； - 如果Host读回的参数跟自己使用SET_CUR命令设置的参数完全一致的话，就表示两者已经协商一致，下一步就可以通过Commit命令向Device确认这个协商过的参数，并启动device开始按照这个参数发送图像流了； - 如果Host读回的参数有部分选项被Device修改为0，就表示Device无法支持该选项，这个时候Host就需要重新回到第二步，把Device无法支持的选项指标参数调低，然后再通过Probe/Get_cur和Probe/Set_Cur命令重新进行协商，直至达成一致； - Host与Device按照以上Probe的协商流程达成一致后，就再通过Commit/SET_CUR指令向Device确认之前协商一致的参数，并启动图像流的传输； 简化版的工作流程如下图所示： !Untitled.png - 在以上流程中，Host与Device只进行了一次格式协商就达成一致； 更完整的协商流程图如下所示： !Untitled.png - 当Host读回的协商数据结构体出现不一致的情况下，就需要重新从头再进行协商。 协商数据结构体 | Offset | Field | Size | Description | | ------ | -------------------------- | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | bmHint | 2 | 这个参数用于指定在Host和Device在协商过程中，如果协商参数不一致、需要进一步协商的情况下，应该保持哪些属性不变。该参数由Host指定，对于Device而言是只读的。 | | 2 | bFormatIndex | 1 | 本次协商Host所选择的格式索引（YUV/MJPEG/H.264），Device支持的格式列表及其索引在USB配置描述符中。该参数由Host指定。 | | 3 | bFrameIndex | 1 | 本次协商Host所选择的图像帧分辨率索引，Device支持的分辨率参数列表及其索引在USB配置描述符中。该参数由Host指定。 | | 4 | dwFrameInterval | 4 | 本次协商Host所选择的帧率，以100ns为单位； | | 8 | wKeyFrameRate | 2 | 本次协商Host所选择的关键帧间隔帧数量。 | | 10 | wPFrameRate | 2 | 本次协商Host所选择的两个关键帧之间所包含的P Frame的数量。除了关键帧和P帧，剩下的就是B帧了。 | | 12 | wCompQuality | 2 | 本次协商Host所选择的图像压缩质量即Compression Quality。取值范围为1（图像质量最低）-10000（图像质量最高）. | | 14 | wCompWindowSize | 2 | 本次协商Host所选择的计算平均码率的图像帧数量。UVC1.5协议中提供了一个例子，设置目标平均码率为100Kbps的情况下，当把wCompWindowSize设置为10的话，就表示单个帧的大小可以大于或者小于100Kbps，但是连续计算10个图像帧的平均码率的话，这个平均码率大致就是100Kbps。 | | 16 | wDelay | 2 | 从视频图像采集，到显示出来的图像延迟。以ms为单位。 | | 18 | dwMaxVideoFrameSize | 4 | Device与Host在进行视频数据传输时，一个图像帧的数据量大小的最大值。 | | 22 | dwMaxPayloadTransferSize | 4 | Device与Host在进行视频数据传输的过程中，一次传输的packet中包含的数据大小的最大值。该参数由Device端设置，Host只读。 | | 26 | dwClockFrequency | 4 | Device端设置的时钟频率，以Hz为单位。在设备端发给Host的图像流的Payloader Header中依据这个参数来计算时间戳信息。这个参数由Device端设置，Host只读。 | | 30 | bmFramingInfo | 1 | 与Device发给Host的每一个图像帧数据的payload header的设置有关的位设置。 | | 31 | bPreferedVersion | 1 | 该参数用于进行视频帧数据向Host传输的封装Payload格式的版本。每种Format可能会包含多个payload格式定义的版本，收发双方需要在这个版本上达成一致。Host端会把bPreferedVersion、bMinVersion和bMaxersion这三个参数在第一次进行Probe/Set的时候设置为0，具体的值由Device进行设置。然后Host在Probe/Get命令读取到Device端的设置值，在下次进行SET命令的时候设置自己期望使用的bPreferedVersion（min和max之间），但是bMinVersion和bMaxVersion必须保持为device设置的值。 | | 32 | bMinVersion | 1 | 参考bPreferedVersion的解释 | | 33 | bMaxVersion | 1 | 参考bPreferedVersion的解释 | | 34 | bUsage | 1 | Device与Host传输图像视频的视频流模式，包括实时流、广播、文件存储等工作模式。 | | 35 | bBitDepthLuma | 1 | bit_depth_luma_minus8 + 8 | | 36 | bmSettings | 1 | temporally encoded video stream类型的传输流（例如H.264）专用，与这类图像流传输的Payload设置有关。 | | 37 | bMaxNumberOfRefFramesPlus1 | 1 | Host端需要保存的最多参考帧的数量。 | | 38 | bmRateControlModes | 2 | 码率控制模式设置。最多可以支持同时传输4条独立的视频流，每条流的码率控制模式都可以单独设置，控制模式用4bit表示，总共就是两个字节。如果这条流不支持码率控制，应该设置为0。 | | 40 | bmLayoutPerStream | 8 | 视频编码算法的分层结构设置。最多可以支持同时传输4条独立的视频流，每条流的码率控制模式都可以单独设置，控制模式用2字节表示，总共就是八个字节。没有增强层的情况下，这个选项应该设置为0； | 协商数据结构体是Host和Device之间使用Probe/Commit命令进行数据交换的格式。 - UVC1.5和UVC1.1的这个数据结构体的定义不同，UVC1.5是48字节，UVC1.1是34字节。以下以UVC1.5为准进行该结构体各个Field的说明。 问题 _既然UVC设备对于视频格式的支持情况在其USB配置描述符中的Video Streaming Interface中已经包含了，对于Host而言，只需要从其中选择然后通过Commit直接设置即可，为什么还要通过这个来回反复的Probe/Set和Probe/Get命令来进行协商确定呢？_ 答案从以上协商数据中包含的各个Field的定义就可以看出来：通过Probe&Commit机制协商的视频图像参数，与USB配置描述符信息中所包含的信息并不一样。 这个媒体格式协商的机制就是在Device提供的Format和Frame的基础上进行选择，然后再在Probe&Commit的流程中对于可以协商的参数进行进一步明确和细化的完整通信流程。 参考资料： 1. UVC1.5 specification； 2. AN75779 - How to implement an image sensor interface using EZ-USB FX3 in a UVC framework_Framework-ApplicationNotes-v13_00-EN.pdf?fileId=8ac78c8c7cdc391c017d073ad2b85f0d) 3. Getting video stream from USB web-camera on Arduino Due - Part 1: Getting Started - CodeProject

USB UVC协议SET/GET Request结构解析

本文主要是在对UVC 1.5协议第四章Class-Specific Requests学习的基础上，整理出来的UVC SET和GET请求的数据结构，方便对UVC通信协议的实现过程进行完整的理解。 UVC Class Specific Request的通信流程 实际上UVC class specific request都是在端点0上进行的控制类传输（Control Transfer），按照Control Transfer的规范定义，这些请求主要包含由三个阶段组成：Setup Stage、Data Stage和Status Stage。而每个命令选项的SET和GET Request实际上也包含了以上三个阶段，都是从Host发出一个Setup Packet开始的： !Untitled.png 对于Set类请求而言（例如上图的SET_CUR），完整的通信流程是： - Host先发出一个Setup Packet，其中包含有要设置的选项的定位信息、选项类型、设置数据长度（对于每一个选项而言，数据长度都是确定的，具体的数据在Data Packet中传输）等； - 然后Host继续发出一个Data Packet，其中包含有具体的设置数据； - 如果Device能够在10ms之内返回状态信息，就给Host直接在控制传输的Status Stage直接返回状态；如果大于10ms，则需要通过接口注册的中断端点向Host返回状态信息； 而对于Get类请求而言（例如上图的GET_CUR），完整的通信流程是： - Host先发出一个Setup Packet，其中包含有要读取的选项的定位信息、选项类型、读取数据长度（对于每一个选项而言，数据长度都是确定的，具体的数据在Data Packet中传输）等； - Device收到以后，会向Host发回一个Data Packet，其中包含有具体的选项数据读取； - 最后Device继续在控制传输的Status Stage向Host返回状态包； 关于控制传输和Setup packet的内容可以参考： - USB传输类型之Control Transfer - USB控制传输中的Setup Packet 相关术语 - Control Selector：实际上就是要设置或者读取的具体选项类型。 - Entity：通信的目的实体，可以是一个接口Interface，也可以是接口中的一个单元Unit。一个Entity中可能有1个或者多个选项（Control Selector）可以存取。 UVC class specific request的总体数据结构 UVC class specific request总体上可以分为两类：Set类请求和Get类请求。前者用于设置UVC camera中的运行参数；后者则用户读取当前运行参数、参数的设置范围、默认值等。 Set Request !Untitled.png - bmRequestType： - bit7为0表示这个这个Packet是由Host发给Device； - bit6..5为0b01表示这个setup packet是一个class级别的包； - bit4..0：为1表示这个setup packet是要发给接口，为2则是要发给端点；具体要看这个设置命令在协议中是如何定义的； - bRequest： - 在UVC规范的Table A.8中有定义，因此此处的SET_CUR对应的就是0x01； !Untitled.png - wIndex和wValue配合起来用于定位本次Set请求是要发送到哪个接口/Unit/端点上，要设置具体的选项是什么； - 一般在wValue的高字节中传递要设置的选项的类型；如果通信目的的Entity有多个设置选项的话，使用wValue来定位是要设置哪个选项；如果Entity只有一个选项，可以把这个wValue用于传递其他的参数； - wIndex的低字节用于指定通信目的的接口编号或者端点地址，高字节用于指定要设置的Entity/Unit的编号或者0； - UVC Device收到的UVC Set/Get Request是发给Video Control interfac还是发给Video Streaming Interface的，就是由wIndex的低8位来决定。wIndex的低8位在此处就对应于Interface Index，与USB枚举信息中定义的两个接口的Index number相一致； - 所以结合wIndex和wValue就可以定位这个命令是要发送到什么地方，设置什么选项； - wLength：Data Stage的数据长度，每个要设置的选项参数长度不同 - Data：具体的设置数据，包含在Data Packet中。Setup Packet只包含前面的5个field； Get Request !Untitled.png - bmRequestType：与Set Request相同，区别是bit7为1，表示本次通信的Data Stage是要从Device端读取； - bRequest：在UVC规范的Table A.8中有定义 - wIndex和wValue的定义与Set Request相同 - wLength：Data Stage的数据长度，每个要读取的选项参数长度不同 - Data：具体的读取数据，包含在Data Packet中。Setup Packet只包含前面的5个field； VideoControl Requests 对于Video Control Interface的Request而言，包含两类请求：接口级别的Interface Control Requests，和端子/单元级别的Unit and Terminal Control Requests。 Interface Control Requests 这类命令是直接发给Video Control Interface，直接由interface来进行处理的： !Untitled.png - wValue指定要设置的接口选项的id，video control interface支持的接口级别的选项只有两个：Power Mode Control和Request Error Code Control，分别对应CS=0和CS=1； - wIndex设置为Video Control Interface的接口编号； - 其他Field与通用的Set Request和Get Request中的描述保持一致 Unit and Terminal Control Requests 这类命令是发给Video Control Interface下面的端子Terminal和各个单元Unit的，每个端子和单元所能支持的选项各自不同。 !Untitled.png - wValue指定要设置的选项id，Video Control Interface中包含的各个Terminal和Unit所支持的选项数量众多，通过这个CS（Control Selector）来区分是要对哪个选项进行操作； - ALL类型的request因为对整个Unit或者Terminal中包含的所有选项进行操作，所以直接设置wValue为0； - wIndex指定要是这的Unit和Terminal的索引编号，在UVC的配置描述符中进行定义； - 其他Field与通用的Set Request和Get Request中的描述保持一致 VideoStreaming Requests 因为Video Streaming Interface没有Unit和Terminal的概念，所以所有的请求命令都是直接发给interface级别来直接进行处理的。 !Untitled.png - wValue指定要存取的接口选项id，UVC device通过这个id来分析这个命令要访问的Video Streaming Interface的选项是什么； - wIndex设置Video Streaming Interface的接口编号； - 其他Field与通用的Set Request和Get Request中的描述保持一致 参考文档： - USB Device Class Definition for Video Devices V1.5：4 Class-Specific Requests

USB复合设备及UVC Profile的描述符详解

USB Composite Device 所谓的USB composite device就是一个USB设备中包含有多项功能，每项功能的具体实现都包含一个或者多个相互独立的Interface，但是整个设备只有一个PID和VID。多个设备功能通过内部逻辑和接口组合的形式形成一个对外的设备。 USB Composite device可以分为两种情况： - 该设备中的每个单独的功能function的实现都只用到一个Interface - 就是所谓的Composite device without multi-interface functions，例如：HID Transfer + MSC、 HID Transfer + HID Keyboard和HID Mouse + HID Keyboard； - 在这种情况下需要设置这个USB设备的设备描述符bDeviceClass、bDeviceSubClass、bDeviceProtocol这三个参数为0x00、0x00、0x00； - 这个设备的配置描述符中通过bNumInterfaces参数指定内部有多少个接口； - 然后在每个接口的接口描述符中通过bInterfaceClass、bInterfaceSubclass、bInterfaceProtocol三个参数指定这个接口提供的USB function的类型usb class； - 该设备中的某项单独功能需要用到多个Interface的组合 - 就是所谓的Composite device with multi-interface function，例如：VCOM + HID Transfer、VCOM + MSC、VCOM + HID Keyboard、Dual VCOM和Audio + HID Transfer。 - 这种情况下需要使用IAD描述符把multi interface功能的多个接口组合在一起，此时就要设置这个USB设备的设备描述符bDeviceClass、bDeviceSubClass、bDeviceProtocol这三个参数为0xEF、0x02、0x01。 USB Composite Device和USB Compound Device的区别: - USB Composite Device是一个USB设备，只有一个PID和VID，但是这个设备里面包含了多个功能，在内部逻辑上通过多个接口Interface来分别实现这些功能； - USB Compound Device内部包含一个USB Hub和多个USB功能设备，这些设备通过内部Hub与外部的USB Host进行连接，每个USB设备都有自己的PID和VID，相当于每个设备都是一个独立的外设，因此一个USB Compound Device包含多组PID/VID； - 在USB2.0的规范中定义如下： - When multiple functions are combined with a hub in a single package, they are referred to as a compound device. - A device that has multiple interfaces controlled independently of each other is referred to as a composite device. IAD描述符 USB的IAD描述符用于把一个USB设备中包含的多个interface合并为一个function提供出来。 - 因此可以把IAD描述符看成是对多个interface的分组操作，把多个interface分成一组来对外提供一个完整的功能function。 对于IAD设备而言，在这个USB设备的设备描述符中需要按照以下规则设置bDeviceClass、bDeviceSubClass、bDeviceProtocol等参数，USB Host才能够正确的识别和解析这个IAD设备后续的配置描述符信息： - bDeviceClass：0xEF - bDeviceSubClass：0x02b - DeviceProtocol：0x01。 而这个IAD描述符所指定的Function功能即USB class则通过IAD描述符中的bFunctionClass、bFunctionSubClass、bFunctionProtocol这三个参数进行指定，例如如果这个IAD描述符定义的是一个USB Video class的function，需要按照如下参数设置IAD描述符的相关信息： - bFunctionClass： 0x0E - bFunctionSubClass： 0x03 - bFunctionProtocol： 0x00 IAD描述符各个选项参数的定义： !Untitled.png - bFirstInterface表示这个IAD描述符所使用的第一个Interface的编号 - bInterfaceCount表示这个IAD描述符需要包含的interface数量 - bFunctionClass、bFunctionSubClass和bFunctionProtocol定义的是这个描述符所实现的是USB哪个class的功能； 在USB规范中定义需要使用IAD描述符的USB device class主要有： - USB Video Class Specification（class code=0x0E） - USB Audio Class Specification（class code=0x01） - USB Bluetooth Class Specification（class code=0xE0） 注意： - IAD描述符中指定使用的多个Interface的编号必须要是连续的，即这个IAD下面的Interface Group的各个Interface的编号必须是连续的； - 一个Composite USB设备中可以包含由多个IAD描述符，只需要使用IAD描述符中的接口配置信息定义清楚这个IAD功能所占用的接口，并且每个IAD描述符必须位于它所包含的多个接口描述符之前； UVC设备的接口与IAD描述符 所有的UVC设备都是多Interface设备，一个UVC设备最起码应该有两个Interface：VideoControl（VC）Interface和VideoStream(VS) Interface。 Spec明确要求一个具有可用的，具有实际UVC功能的设备要有一个VC Interface，一个或多个VS Interface。 - VCInterface用于进行配置，操控，设置UVC设备进入不同的功能状态； - VSInterface则负责定义这个UVC设备所支持的各种视频流的格式以及视频数据流的传输； - 完整的UVC功能需依赖VS Interface和VC Interface的配合才能实现。 因为UVC设备是需要把两个接口（VS+VC）结合在一起来提供音视频传输与控制的服务，因此UVC的Spec还明确要求UVC设备必须要使用一个Interface Association Descriptor（IAD）来描述这个包含了VC和VS的Interfaces集合。 - 在UVC的设备描述符中，也需要设置这个设备DeviceClass、Device Subclass以及Device Protocol为IAD设备； Video Control Interface Video Control Interface中包含的主要组件： - Input Terminal：描述这个设备的输入端，及其支持的功能； - Output Terminal：描述这个设备的输出端，及其支持的功能； - Camera Terminal：描述这个设备的相机功能，例如Focus、Zoom等功能； - Select Unit：实际上就是Mux复用组件； - Processing Unit：描述这个设备的图像处理功能，例如灰度、曝光、亮度控制的功能； - Extension Unit：描述这个设备支持的额外扩展性功能，可有可无； 一个Video Control Interface的例子： !Untitled.png 因此实际上Video Control Interface就是把上面的多种类型的Terminal和Unit连接起来组成的一个提供音视频流处理的pipeline，最终通过Output Terminal对外提供音视频流数据。 USB Host对UVC camera发送的所有控制类型的命令都是通过这个interface来完成的。 Video Streaming Interface Video Streaming Interface则专门负责用于传输UVC设备的Video数据到Host端。 一个UVC camera通常会支持多种不同的Format不同分辨率和帧率的图像传输格式，需要在Video Streaming Interface的接口描述中把支持的所有视频格式使用Video Streaming Frame Type描述符进行定义。 - 不同编码格式、分辨率、帧率对于USB传输带宽的要求各不相同，目前能够支持的主要的编码格式是YUV、MJPEG和H.264； - 要能够支持高清高帧率图像的UVC传输，就只能使用MJPEG和H.264这类压缩数据格式； 每个Video Streaming Interface必须要包含一个ISO或者Bulk端点用于传输Video Streaming数据，以及一个可选的Bulk端点用于传输静态图片数据（在UVC Camera中已经实现了静态图片拍照的机制的前提下）。 一个USB接口UVC Camera+HID设备的例子 参考资料USB Interface Association Descriptor中提供了一个包含有UVC Camera和HID功能的USB设备的例子。 该设备具有两部分功能： - Video Class，即UVC功能 - 该功能由一个IAD描述符定义，其中包含一个Video Control Interface（即Interface 0）和一个Video Streaming Interface（即Interface 1）； - USB Host端解析到这个IAD描述及其下面的VC和VS Interface描述符后，会加载video class driver进行处理。 - HID功能 - 该功能包含有一个实现HID功能的Interface（即Interface 2）； - USB Host解析该接口对应的描述符会后自动加载Host端的HID class driver来进行处理； 该设备的USB描述符结构： 设备描述符 - 表示这是一个包含有IAD描述符的multi function composite USB device； 配置描述符 - bNumInterfaces为其内部包含的USB接口数量，其中UVC功能通过IAD描述符包含有2个Interafce，HID包含一个Interface； IAD描述符 - bInterfaceCount表示这个IAD描述符需要包含的interface数量，这里是2个，也就是Video Control Interafce和Video Streaming Interface； - bFirstInterface表示这个IAD描述符所使用的第一个Interface的编号，这里是0，也就是说这个IAD用的两个Interface就是：Interface0和Interface1； - 后续的bFunctionClass、bFunctionSubClass和bFunctionProtocol定义了这是一个Video class的功能； Video Control Interface描述符 - 此后是Video Control Interface的内部描述信息（即这个VC Interface中包含的各个Terminal和Unit的组织情况）及这个接口的端点信息描述符； Video Streaming Interface描述符 此后是Video Streaming Interface的内部描述信息（即这个VS Interface中包含的各种Video Format的详细信息列表）及这个接口的端点信息描述符； HID功能对应的Interface描述符 最后是HID功能接口的详细配置信息及其对应的端点描述符信息； 参考资料 - UVC（USB Video Class）协议讲解 - USB Video Class 簡介 - USB Interface Association Descriptor