关于摄像头测试程序的修改于疑问

blank

昨天晚上看了一晚上飞凌提供的v4l2摄像头linux测试程序，发现有一些问题很值得拿出来和大家分享下
while(1){
  n=read(v4l2_fd, buf, 320*240*2);
  printf("display %d\n",n);
  show_rgb565_img(fb_buf,buf);
}

在main函数中最后的while循环里执行取数据，画在屏幕上面就是这三句起作用。
read(v4l2_fd, buf, 320*240*2);
这句函数是从摄像头设备驱动里拿出摄像头采集到的数据 并且放到buf里
这里我们回去看下 buf 的 定义 __u8 *buf;
他是无符号8位整数  

然后我们看看他是怎么显示到屏幕上面的

static void show_rgb565_img(void *scr, __u16 *data_buf)
{
__u16 x, y;
__u16 *fb_buf = (__u16 *)scr;
fb_buf += (480*14);
  
  
   for(y=0; y<ROWS; y++) {
    for(x=0; x<COLS; x++) { //calculate 2 time
      fb_buf[x+28]   = *data_buf++ ;
     }
    fb_buf += 480;
   }
}


*scr 传过来的数据就是 关于每一帧的尺寸信息，databuf 这里存放的就是一帧图像的rgb数据所在
这里有个非常有意思的点
__u8 *buf;
show_rgb565_img(fb_buf,buf);
static void show_rgb565_img(void *scr, __u16 *data_buf)；
当我把上面三个函数放在一起就发现 这里面藏了一个让人发现不了的转换  u8到u16
这个转化在一开始我并没有发现，所以导致我 读后面程序的时候，误以为图片传来的数据只要buf的前一半，也就是320*240个数据，通过socket传出来的图像丢失了很多信息，并且尺寸大小也发生了变化，最后发现前半部分后半部数据所呈现的图像完全不一致，所以我断定，buf后半段数据依然有用，但是320*240 明明只有那么多的像素何来320*240*2那么多。
造成这个原因的主要原因是因为，我一直以为这个buf里面每一个存的是一个小于256的值 也就认为图像数据是伪彩图， 最后我又看了下摄像头程序里面的图像处理方面程序 发现 里面存在大量的rgb 只不过转化成了一种565的编码形式  也就是 一个rgb占16位

高五位 r     中6位 g     低5位   b

纵观我拿到的数据如果 16个一拿 不正好是320*240个点么   也就是buf[0]buf[1]  应该是一个数据
再回来看程序 发现了有一个u8-u16的转换  哦  原来如此·····
那么在windows 下 我对拿到的数据进行了 简单的数学处理 将两个8位凑成一个16位数字
然后再通过 除法  和 模运算 提取出  0-4（b）  5-10（g） 11-15（r）数据画在图像里 这里还有一个大小端的问题，和网络大小端的问题 以及windows测试程序大小端的问题，总结起来就是，，拿到的数据 合并时  
是buf[0]*255+buf[1]
还是 buf[1]*255+buf[0]

各位看官自己测试吧


现在说下 我现在还没解决的问题
1由于网络传输中 的异步问题 所以导致 接收数据时 一旦造成丢包现象，会造成图片错位现象，暂时没有找到好的解决方法
2 图片亮度问题，图片经过socket传过来客户端以后显示数据后亮度情况 明显与 开发板上的显示亮度不一致，我在驱动里面没有找到相应的rgb数据亮度调节方法 还希望，飞凌技术能帮助下我。

上图是socket回传回来的图像


上图是由于socket丢包 所导致的接收buf数据混乱 导致的图像错乱

blank

求救 各位飞凌的工程师们······