1. QT的客戶端，c的服務(wù)器之間不好溝通。解決：框架用 QT風(fēng)格寫(包括信號(hào)與槽，QT界面，連接服務(wù)器，發(fā)送接收等)，數(shù)據(jù)用c的風(fēng)格寫，做到與服務(wù)器一致。

2. Tcp粘包拆包，收發(fā)數(shù)據(jù)一致，結(jié)構(gòu)體成員類型大小一致。

3. Tcp處理登錄，udp處理發(fā)送視頻，導(dǎo)致開線程pthread_create傳參不好傳。Tcp的connfd,udpfd封裝成結(jié)構(gòu)體傳，或者開2個(gè)線程。

4. 回收資源時(shí)候，關(guān)閉connf;但不能關(guān)閉udpfd,否則下一次連接傳不了圖片(視頻)了。

5. V4l2框架需要自學(xué)，轉(zhuǎn)碼壓縮算法需要自學(xué)。

6. Memcpy之段錯(cuò)誤: //1在unix上，系統(tǒng)對(duì)內(nèi)存管的比較松，而在linux下，指針可能是指向了一個(gè)只讀的內(nèi)存。buffer = (char*)malloc(outqueue.length);

7. Arm-linux-gcc編譯代碼的時(shí)候需要很多頭文件和庫(kù)的支持(sqlite3,jpeg)，應(yīng)該將它們放在相應(yīng)的位置。

8. -ljpeg一直報(bào)錯(cuò)，cannot found。

通過(guò)比對(duì)正常的庫(kù)文件：libsqlite3.la

# Directory that this library needs to be installed in:

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

發(fā)現(xiàn)libjpeg.la雖然通過(guò)arm-linux-gcc交叉編譯了的，但是生成的文件的路徑仍為gcc編譯后libjpeg目錄，而不是自己修改后的armjpeg目錄。

# Directory that this library needs to be installed in:

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

解決：刪除解壓后的文件，重新解壓，重新arm-linux生成新的文件夾

9. 應(yīng)該用buf【】裝圖片數(shù)據(jù)，不應(yīng)該用char* buf = NULL裝。

10. 應(yīng)該把攝像頭采集等模塊分開，便于調(diào)試。

11. 自學(xué)M0模塊(串口函數(shù))，LCD模塊。

12. 服務(wù)器循環(huán)發(fā)圖片，QT客戶端只顯示了一張，因?yàn)樘摂M機(jī)的原因，交叉編譯放在板子上跑，ok

13. 多個(gè)客戶端同時(shí)訪問的時(shí)候出現(xiàn)圖片花的情況，因?yàn)闀?huì)出現(xiàn)搶占隊(duì)列資源的情況。把get_picture單獨(dú)開一個(gè)線程，把取得的圖片放在全局變量buf里，客戶端訪問buf就好，因?yàn)榭蛻舳艘�讀buf，服務(wù)器要寫buf，所以得加鎖保護(hù)。Udp發(fā)送不消耗時(shí)間，mencpy消耗時(shí)間，避免搶鎖，udp發(fā)送后加點(diǎn)延時(shí)

14. 客戶端異�？ㄋ溃�服務(wù)端while(1)發(fā)送，客戶端無(wú)法及時(shí)處理，數(shù)據(jù)太多，導(dǎo)致卡死。???

15. 視頻不流暢，圖片數(shù)據(jù)太大，占寬帶，設(shè)置320*240，QT設(shè)置為飽滿縮放scaledContents打鉤

16. 圖片花，QT那邊接受數(shù)組定小了。

17. Test_ser模式加不加鎖都OK。True_ser模式加不加鎖兩個(gè)客戶端都相互干擾，且段錯(cuò)誤。

18. True_ser中：pthread_t pid_play;//多客戶端會(huì)導(dǎo)致值被修改，導(dǎo)致干擾

19. True_ser中：pthread_cancel(pid_play);//存在暴力取消，導(dǎo)致死鎖的風(fēng)險(xiǎn)

20. True_ser中：因?yàn)閡dp的關(guān)系，無(wú)法判斷客戶端什么時(shí)候退出，客戶端退出時(shí)候，服務(wù)器依然會(huì)發(fā)送圖片，浪費(fèi)。綜上放棄true_ser,采用test_ser。