tiny6410 linux内核2.6.38 视频采集问题

操作环境:

硬件平台:tiny6410 内核版本:2.6.38 摄像头:罗技的c210 usb摄像头

遇到的问题是:

1)用linux下的v4l2API采集出来的图像分辨率为176*144,而用户手册上给出的最大分辨率可以为640*480。

2)因为现在的video capture 设备可能带有多个功能,例如c210除了有video capture功能外,还有内置的麦克风,我的理解就是v4l2所说的audio(语音)。v4l2中有关于语音的输入通道的查询、选择等。但是我找了半天没找到怎么对语音数据采集的接口。很是郁闷。(此问题没有在此文章讨论,有待解决)

初步猜测有时以下原因:

1.tiny6410的usb host接口为usb1.1版本的,而罗技的c210接口为usb2.0,且在linux下这款摄像头用的为uvc驱动,而Uvc官网有解释说当摄像头连接到Usb1.1版本的时候可能会出问题,最好接到usb2.0接口上。

2.就是v4l2API调用不对,这种可能性基本排除掉了。首先v4l2官网有示范的capture video 例子,将自己的程序与之相对,基本一致。第二,我将相同的采集程序放到我pc上在虚拟机中运行的ubuntu10.10,pc的usb版本为usb2.0,摄像头还是c210,但是采集出来的图像分辨率就是程序所要求的640*480。ubuntu的内核版本为2.6.35。所以初步断定为就是摄像头硬件和开发板的usb接口问题造成。

以下有些内容是对此博客的引用:http://blog.csdn.net/yaozhenguo2006/article/details/7074706

在嵌入式系统中,视频采集主要采用两种接口:一种是标准摄像头接口,一种是USB接口(USB1.1)。标准的摄像头接口,接口复杂,但传输速度快,适合高质量视频采集,而USB接口,接口简单,但有性能瓶颈,只能用于低质量的视频采集。

以上程序可以正确的进行摄像头的视频采集与显示,但是最大只能采集到176 × 144 的低质量图像,如果采集分辨里达到320 * 240 图像会非常卡,有明显的延迟与丢帧现象,这种原因是USB1.1每秒所传的帧数有限造成的。USB1.1最大每秒可传的帧数由图像大小和USB速度共同决定。下面以320×240 YUYV格式的图像为例,计算USB1.1最大每秒可传的帧数。

    (1)每帧需要传输的数据量为 320 × 240 × 2 × 8 = 1228800bit = 1.2288Mbit
    (2)USB协议规定:USB1.1的最大传输比特率为12M也就是每秒传12Mbit。这只是理论上的数据,实际传输也就10M左右。我们以10Mbps为例
    (3)USB协议规定:同步传输不得超过总线的带宽的90%,所以传播速度还得乘以0.9,为9Mbps。
    (4)USB传输速度包括了协议相关的位,USB协议规定USB同步传输包,每个包的协议信息为9个字节。每秒帧数还与每个USB帧(1mS)传输的包的数量有关系,这与同步端点的最大数据有关系,我的摄像头同步端点最大数据为8字节。所以每个包的数据与协议数据比就是 8 : 9, 这样一来带宽还得乘以一个 8/17,为4.2353Mbps
    (5) 最后算出每秒帧数据就是 4.2353 / 1.2288 = 3.4
    以上计算没有考虑SOF包,以及USB位填充,以及其他的因素,粗略的算出,对于320×240的一幅YUYV格式的图像,USB1.1最大每秒传输3.4帧。可谓是非常小了,但这只是理论的值,实际我用gettimeofday测出的只有每秒一帧多,这样的速度不卡才怪。所以最后得出的结论就是:由于USB1.1的速度限制,采用USB1.1做图像采集,在USB摄像头输出格式为未压缩的原始数据(如:RGB,YUV)的前提下只能采集到低分辨率,低质量的画面。基本上不能用于产品,我查了一些资料,USB1.1数据采集的系统,USB摄像头采集出来的数据格式大多是已经压缩过的,如JPEG格式,这样可大大减轻USB传输的负担,提高视频采集的采集质量。但是这样也有弊端,采集回的数据不是原始数据,不方便对数据的二次处理。所以这种压缩输出格式的USB摄像头基本上都是USB1.1的,USB2.0的摄像头输出格式基本上都是未经处理的原始数据,因为2.0的速度已经足够快,理论480Mbps的速度绝对满足需要。
 
3.内核中的摄像头驱动有问题,可是将摄像头接入时,系统会自动识别,并创建设备文件,所以我认为应该不是驱动的问题。

你可能感兴趣的:(tiny6410 linux内核2.6.38 视频采集问题)