1. QT的客户端，c的服务器之间不好沟通。解决：框架用 QT风格写(包括信号与槽，QT界面，连接服务器，发送接收等)，数据用c的风格写，做到与服务器一致。

2. Tcp粘包拆包，收发数据一致，结构体成员类型大小一致。

3. Tcp处理登录，udp处理发送视频，导致开线程pthread_create传参不好传。Tcp的connfd,udpfd封装成结构体传，或者开2个线程。

4. 回收资源时候，关闭connf;但不能关闭udpfd,否则下一次连接传不了图片(视频)了。

5. V4l2框架需要自学，转码压缩算法需要自学。

6. Memcpy之段错误: //1在unix上，系统对内存管的比较松，而在linux下，指针可能是指向了一个只读的内存。buffer = (char*)malloc(outqueue.length);

7. Arm-linux-gcc编译代码的时候需要很多头文件和库的支持(sqlite3,jpeg)，应该将它们放在相应的位置。

8. -ljpeg一直报错，cannot found。

通过比对正常的库文件：libsqlite3.la

# Directory that this library needs to be installed in:

libdir='/home/farsight/libjpeg/lib'

发现libjpeg.la虽然通过arm-linux-gcc交叉编译了的，但是生成的文件的路径仍为gcc编译后libjpeg目录，而不是自己修改后的armjpeg目录。

# Directory that this library needs to be installed in:

libdir='/home/farsight/libjpeg/lib'

解决：删除解压后的文件，重新解压，重新arm-linux生成新的文件夹

9. 应该用buf【】装图片数据，不应该用char* buf = NULL装。

10. 应该把摄像头采集等模块分开，便于调试。

11. 自学M0模块(串口函数)，LCD模块。

12. 服务器循环发图片，QT客户端只显示了一张，因为虚拟机的原因，交叉编译放在板子上跑，ok

13. 多个客户端同时访问的时候出现图片花的情况，因为会出现抢占队列资源的情况。把get_picture单独开一个线程，把取得的图片放在全局变量buf里，客户端访问buf就好，因为客户端要读buf，服务器要写buf，所以得加锁保护。Udp发送不消耗时间，mencpy消耗时间，避免抢锁，udp发送后加点延时

14. 客户端异常卡死，服务端while(1)发送，客户端无法及时处理，数据太多，导致卡死。???

15. 视频不流畅，图片数据太大，占宽带，设置320*240，QT设置为饱满缩放scaledContents打钩

16. 图片花，QT那边接受数组定小了。

17. Test_ser模式加不加锁都OK。True_ser模式加不加锁两个客户端都相互干扰，且段错误。

18. True_ser中：pthread_t pid_play;//多客户端会导致值被修改，导致干扰

19. True_ser中：pthread_cancel(pid_play);//存在暴力取消，导致死锁的风险

20. True_ser中：因为udp的关系，无法判断客户端什么时候退出，客户端退出时候，服务器依然会发送图片，浪费。综上放弃true_ser,采用test_ser。