简介
UVC : USB video device class,是一种USB设备类,这种设备用于通过USB总线传输视频流,例如网络摄像头(webcam)等,这些年随着监控和网络直播的兴起,webcam类的设备大量出现,而这些设备与上位机的数据传输,必然绕不开uvc协议。
相关资料链接
维基百科中的描述:
https://en.wikipedia.org/wiki/USB_video_device_class
uvc协议下载:
https://www.usb.org/documents
https://www.usb.org/document-library/video-class-v15-document-set
https://www.usb.org/document-library/video-class-v11-document-set
https://www.usb.org/document-library/audiovideo-device-class-v10-spec-and-adopters-agreement
目前uvc协议主要分为1.0,1.1和1.5这三种,前两者使用相对较为广泛。上面的连接分别是这三种协议的文档,读者可自行下载参考。
<=======================>
下面详细摘一些UVC相关的知识点
<=======================>
UVC Descriptor Hierarchy(来自UVC1.1规范)
几个名词的解释:
术语 | 解释 |
---|---|
Configuration | A collection of one or more interfaces that may be selected on a USB device. |
Descriptor | Data structure used to describe a USB device capability or characteristic. |
Device | USB peripheral. |
Endpoint | Source or sink of data on a USB device. |
Interface | An Entity representing a collection of zero or more endpoints that present functionality to a Host. |
IAD | Interface Association Descriptor. This is used to describe that two or more interfaces are associated to the same function. An ‘association’ includes two or more interfaces and all of their alternate setting interfaces. |
文摘与解读:
根据上文描述,USB设备的视频相关的功能是由设备层级架构中的interface层来具体实现的。每个video function(此处应该理解为configuration)均是由一个VC interface和若干个VS interface共同组成的,事实上,我接触的摄像头设备中,大多只有一个VS interface。
当然了,除了视频功能,该设备也可以同时拥有其它功能,比如MTP,这样的话,设备层往下会有第二个configuration,这个configuration又会有其它的interfaces。
UVC协议的具体实现就放在这些interfaces中,为了实现UVC的相关功能,协议特别引入了units和terminals两个概念:
units可以理解为UVC相关子功能的具体实现单元,这种模块单元由多个输入和一个输出构成。terminal可以理解为数据流的端节点,分为input terminal (IT)和 output terminal(OT),分别代码视频数据流的输入起始点和输出终点。当然了,IT和OT之间少不了还有一些units,用于对数据进行相应处理。注意,unit和terminal都有对应的descriptor。
UVC规范中定义了一些基础的unit和terminal:
• Input Terminal
• Output Terminal
• Selector Unit
• Processing Unit
• Extension Unit
这些unit和terminal可以实现绝大部分的功能。除此之外,还有一些特殊的terminal,比如Media Transport Terminal和Camera Terminal,用于实现一些特殊的功能。当然了,对于初级玩家来说,上面5个unit和terminal已经足够使用了。
每一个unit或者terminal中又包含了若干个setting,用于实现不同的video controls,比如,在processing unit中,相机的亮度(brightness)信息包含在current setting中,如果主机侧想读取现在的亮度值,可以向这个setting发起request来获得。主要的setting分为:
• Current setting
• Minimum setting
• Maximum setting
• Resolution
• Size
• Default
对主机侧来说,通过 unit descriptor,terminal descriptor和video control,就可以完整获取到该UVC设备的控制信息。
下面是interface层几个主要组件的介绍:
下面一段话关于操作模式的,比较有意思:
这段话也再次确认了,一个设备可以有多个configuration,每个configuration可以有多个interface。同一个设备中可以同时存在多个独立的视频功能(我个人理解为这指的就是configuration),每个视频功能是由多个interface去支撑的,因此隶属于同一个功能的interface就形成了一个组,这个组就叫video interface collection,其描述符就叫IAD。如果一个设备有多个独立的视频功能,则它必然拥有多个video interface collection。
如前所述,一个video interface collection含有一个(且是唯一一个)video control interface和若干个video streaming interface。 这个VC interface是由两个endpoint组成的:
• A control endpoint for manipulating Unit and Terminal settings and retrieving the state of the video function. This endpoint is mandatory, and the default endpoint 0 is used for this purpose.
• An interrupt endpoint for status returns. This endpoint is optional, but may be mandatory under certain conditions. See section 2.4.2.2, "Status Interrupt Endpoint" for further information.
下面是对这两种endpoint的详细描述:
下面是video streaming interface相关的内容:
A video (or still image) sample refers to an encoded block of video
data that the format-specific decoder is able to accept and interpret in
a single transmission.
Sample Bulk Transfers
主机如何去控制设备?
2.4.4 Control Transfer and Request Processing
Control transfers minimally have two transaction stages: Setup and Status. A control transfer
may optionally contain a Data stage between the Setup and Status stages. The Setup stage
contains all information necessary to address a particular entity, specify the desired
operation, and prepare for an optional Data stage. A Data stage can be host-to-device (OUT
transactions), or device-to-host (IN transactions), depending on the direction and operation
specified in the Setup stage via the bmRequestType and bRequest fields.
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.