Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮?/h1>
瀏覽：21日期：2022-06-21 13:08:25
1. 項(xiàng)目背景視頻傳輸: 在一臺電腦上播放視頻（捕捉攝像頭畫面），同局域網(wǎng)內(nèi)另一臺電腦上實(shí)時(shí)播放，盡量不卡頓。
先放最后的照片，和用gif展示一下視頻效果。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
傳輸視頻可以采取圖片或者流的形式，本文采取傳輸圖片的形式，在1s之內(nèi)顯示多張圖片從而形成連續(xù)的視頻畫面。
經(jīng)費(fèi)有限，所有實(shí)驗(yàn)均基于筆記本電腦。
使用的視頻源是本機(jī)攝像頭，以及進(jìn)擊的巨人720p資源。
2. 解決方案1. 使用Python的Socket，使用opencv捕捉攝像頭/視頻的畫面。
2. 原始的圖片很大（720p的大小是1920*1080*3），整圖就算壓縮成jpg格式其大小也非常大。而UDP最大只能傳輸65535字節(jié)大小的數(shù)據(jù)區(qū)，故對圖片進(jìn)行分塊，分塊過后的數(shù)據(jù)壓縮成jpg格式，并對圖片分塊數(shù)據(jù)進(jìn)行編號。
3. 實(shí)驗(yàn)檢測表明，本文實(shí)驗(yàn)環(huán)境發(fā)送端不需要使用發(fā)送隊(duì)列，基本上新生成的幀很快就能被socket傳輸?shù)簟?/p>
4. 接收端使用多線程接收，每個(gè)線程是一個(gè)socket，接收過后的數(shù)據(jù)存儲于數(shù)據(jù)片池。
5. 接收端另開一個(gè)線程，用于反復(fù)從數(shù)據(jù)片池 讀取數(shù)據(jù)片，根據(jù)數(shù)據(jù)片的編號更新幕布，這里幕布是專門用于圖像顯示的一個(gè)數(shù)組，其維度是720p（1920*1080*3）。更新過后的結(jié)果暫存于圖片池
6. 主線程反復(fù)從圖片池讀取圖片，并顯示。
3. 實(shí)現(xiàn)細(xì)節(jié)3.1 TCP/UDP的選擇為了實(shí)現(xiàn)低延遲，毫無疑問選取無連接的UDP傳輸。
3.2 圖片分片算法這里其實(shí)也談不上什么算法，就是將圖片水平分割。這種做法的好處在于，分割后圖片的編號可以和區(qū)域一一對應(yīng)。本文沒有探索更為復(fù)雜的圖片分片算法。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
經(jīng)過處理，圖片變?yōu)橐粋€(gè)個(gè)分片，如下：
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
對上述圖片進(jìn)行編號，很顯然可以編號0,1,2,3，對于任意分塊（例如2）在圖像數(shù)組中對應(yīng)的區(qū)域是frame[2*piece_size:(2+1)*piece_size]，其中piece_size表示一片數(shù)據(jù)的大小。
這種對應(yīng)關(guān)系方便解壓后的圖像還原操作。
3.3 JPG壓縮這其實(shí)是個(gè)很小的技術(shù)點(diǎn)，因?yàn)槭褂玫膲嚎s算法都是現(xiàn)成的。但是值得一提的是，JPG的壓縮率是真的高，在實(shí)驗(yàn)數(shù)據(jù)上實(shí)現(xiàn)了10-20倍的壓縮率。
使用了多線程壓縮，壓縮完過后，更新對應(yīng)的桶，這里的桶實(shí)際上就是數(shù)據(jù)片。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
由主線程Main Thread反復(fù)從桶里取數(shù)據(jù)片(t1)，每取1片發(fā)送一次，然后再取下一片（t2），直到所有桶都被取了一次（例子中有10片）。
至此，一張圖片的分片數(shù)據(jù)被全部取完，于是開始統(tǒng)計(jì)一些FPS相關(guān)信息。
3.4 接收隊(duì)列接收端開了10個(gè)線程用于異步socket接收數(shù)據(jù)片。
為了保證接收端產(chǎn)生絲滑的視頻效果，使用接收隊(duì)列是個(gè)不錯(cuò)的選擇。本文使用了2個(gè)隊(duì)列的設(shè)計(jì)。實(shí)現(xiàn)數(shù)據(jù)接收的二級緩沖。示意圖如下：
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
這樣一來，視頻效果明顯絲滑了很多。
4. 遇到的坑及解決辦法4.1. Windows防火墻巨坑，最好都關(guān)了。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
4.2. 路由器網(wǎng)絡(luò)頻段同一臺路由器的5G和2.4G頻段有時(shí)候不能互相ping通，要確保兩個(gè)電腦連接在同一頻段上。
4.3. Wifi配置如果上述設(shè)置都對了，但是還是ping不通。將wifi連接設(shè)置成專用網(wǎng)絡(luò)，也許就能解決問題。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
4.4. 硬件瓶頸個(gè)人PC的性能是較大瓶頸，尤其是單機(jī)測驗(yàn)的時(shí)候（本地兩個(gè)終端，一個(gè)發(fā)送、一個(gè)接收），CPU使用率分分鐘到100%。聽某個(gè)技術(shù)大哥說要使用GPU壓縮。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
用兩臺電腦，一臺接收一臺發(fā)送之后，效果要好很多。
4.5. OpenCV讀取攝像頭大坑由于攝像頭驅(qū)動的關(guān)系，在我的電腦上需要設(shè)置以下兩個(gè)變量，才能成功啟用外置的720p攝像頭。
os.environ['OPENCV_VIDEOIO_DEBUG'] = '1'os.environ['OPENCV_VIDEOIO_PRIORITY_MSMF'] = '0'
即使如此，如果不做額外的設(shè)置，讀出來的圖片將是480p的（看起來很像是720p被壓縮過后的）。所以如果要傳輸真·720p，還需要設(shè)置讀出的圖像大小，如下：
self.stream = cv2.VideoCapture(1) # 讀取第一個(gè)外置攝像頭self.stream.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) # floatself.stream.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) # float4.6. Socket卡頓
不知道是不是我寫的有問題，感覺多線程的socket會爭搶資源（發(fā)送和接收的線程間，對應(yīng)5.1節(jié)功能），造成接收端的畫面顯示將變得卡頓。
5. 尚未Bug Free的功能5.1 使用TCP回傳幀率信息為了計(jì)算網(wǎng)絡(luò)時(shí)延，采取類似伽利略測光速的方法。從數(shù)據(jù)包打包之前，到對方收到數(shù)據(jù)包之后，再將這個(gè)數(shù)據(jù)回傳到發(fā)送方。
這樣就不存在兩臺機(jī)器時(shí)間差校準(zhǔn)的問題。
該算法的大致流程如下圖所示。
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
這種計(jì)算方式應(yīng)該是自己的實(shí)驗(yàn)環(huán)境下比較準(zhǔn)確的方法了。
時(shí)延信息的反饋不需要特別快（比如200-500ms發(fā)送一次），所以使用TCP技術(shù)
其實(shí)TCP和UDP在使用Python編程的時(shí)候代碼差距可以說極小…
但是！！！
自己目前在實(shí)現(xiàn)信息回傳的時(shí)候，會莫名卡頓起來。
接收端建立回傳的socket之后，甚至還沒傳輸數(shù)據(jù)，整個(gè)程序運(yùn)行起來就變得非常卡頓，這個(gè)讓我比較苦惱，目前正在找bug.
5.2 擁塞控制 （流量控制）的算法這部分的思想是流量控制，感謝評論區(qū)指正。
5.1節(jié)如果一并回傳接收端隊(duì)列狀態(tài)信息。如果接收端隊(duì)列太滿，說明來不及處理視頻幀了，從而對發(fā)送端的發(fā)送速度進(jìn)行控制，才是“擁塞控制”
這個(gè)本來是想著和5.1綜合起來用的，已經(jīng)寫好了，但是還沒能真正展現(xiàn)價(jià)值，設(shè)計(jì)是否合理也值得商榷。
控制的是發(fā)送端的發(fā)送頻率，從而實(shí)現(xiàn)接收端的流暢播放
思想和TCP的擁塞控制一樣慢增長，快下降。如果接收端的隊(duì)列一直處于較空的狀態(tài)，則表明還有一定的性能剩余，此時(shí)可以緩慢加快發(fā)送的頻率；如果檢測到接收端隊(duì)列中數(shù)據(jù)較多，表明發(fā)送速度太快來不及顯示，這時(shí)候就大幅下降發(fā)送的頻率。
這個(gè)擁塞控制的算法基于幾個(gè)假設(shè)：
1.網(wǎng)絡(luò)情況良好，丟包率比較低；
2接收端電腦的性能足夠高，來得及處理解包、顯示圖像。
如果5.1能夠正確實(shí)現(xiàn)，則應(yīng)該根據(jù)網(wǎng)絡(luò)時(shí)延![Python使用UDP實(shí)現(xiàn)720p視頻傳輸?shù)牟僮? src=]()
的大小來控制發(fā)送的頻率。
6. 總結(jié)這個(gè)項(xiàng)目是一周的時(shí)間內(nèi)完成的，目前還有點(diǎn)bug。小組內(nèi)的成員分別在不同技術(shù)方向上進(jìn)行了探索，收獲都還挺大的。這篇博客就當(dāng)一個(gè)項(xiàng)目總結(jié)吧，寫的難免有紕漏之處。
github地址：https://github.com/820fans/UDP-Video-Transfer
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持好吧啦網(wǎng)。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。
相關(guān)文章：
1. 解決Python數(shù)據(jù)可視化中文部分顯示方塊問題2. python開發(fā)一個(gè)解析protobuf文件的簡單編譯器3. ASP編碼必備的8條原則4. python 根據(jù)列表批量下載網(wǎng)易云音樂的免費(fèi)音樂5. python中round函數(shù)保留兩位小數(shù)的方法6. python 基于AioHttp 異步抓取火星圖片7. 利用python+ffmpeg合并B站視頻及格式轉(zhuǎn)換的實(shí)例代碼8. Android實(shí)現(xiàn)儀表盤控件開發(fā)9. Python基于traceback模塊獲取異常信息10. 深入理解JavaScript字節(jié)二進(jìn)制知識以及相關(guān)API
視頻傳輸: 在一臺電腦上播放視頻（捕捉攝像頭畫面），同局域網(wǎng)內(nèi)另一臺電腦上實(shí)時(shí)播放，盡量不卡頓。
先放最后的照片，和用gif展示一下視頻效果。
傳輸視頻可以采取圖片或者流的形式，本文采取傳輸圖片的形式，在1s之內(nèi)顯示多張圖片從而形成連續(xù)的視頻畫面。
經(jīng)費(fèi)有限，所有實(shí)驗(yàn)均基于筆記本電腦。
使用的視頻源是本機(jī)攝像頭，以及進(jìn)擊的巨人720p資源。
2. 解決方案1. 使用Python的Socket，使用opencv捕捉攝像頭/視頻的畫面。
2. 原始的圖片很大（720p的大小是1920*1080*3），整圖就算壓縮成jpg格式其大小也非常大。而UDP最大只能傳輸65535字節(jié)大小的數(shù)據(jù)區(qū)，故對圖片進(jìn)行分塊，分塊過后的數(shù)據(jù)壓縮成jpg格式，并對圖片分塊數(shù)據(jù)進(jìn)行編號。
3. 實(shí)驗(yàn)檢測表明，本文實(shí)驗(yàn)環(huán)境發(fā)送端不需要使用發(fā)送隊(duì)列，基本上新生成的幀很快就能被socket傳輸?shù)簟?/p>
4. 接收端使用多線程接收，每個(gè)線程是一個(gè)socket，接收過后的數(shù)據(jù)存儲于數(shù)據(jù)片池。
5. 接收端另開一個(gè)線程，用于反復(fù)從數(shù)據(jù)片池 讀取數(shù)據(jù)片，根據(jù)數(shù)據(jù)片的編號更新幕布，這里幕布是專門用于圖像顯示的一個(gè)數(shù)組，其維度是720p（1920*1080*3）。更新過后的結(jié)果暫存于圖片池
6. 主線程反復(fù)從圖片池讀取圖片，并顯示。
3. 實(shí)現(xiàn)細(xì)節(jié)3.1 TCP/UDP的選擇為了實(shí)現(xiàn)低延遲，毫無疑問選取無連接的UDP傳輸。
3.2 圖片分片算法這里其實(shí)也談不上什么算法，就是將圖片水平分割。這種做法的好處在于，分割后圖片的編號可以和區(qū)域一一對應(yīng)。本文沒有探索更為復(fù)雜的圖片分片算法。
經(jīng)過處理，圖片變?yōu)橐粋€(gè)個(gè)分片，如下：
對上述圖片進(jìn)行編號，很顯然可以編號0,1,2,3，對于任意分塊（例如2）在圖像數(shù)組中對應(yīng)的區(qū)域是frame[2*piece_size:(2+1)*piece_size]，其中piece_size表示一片數(shù)據(jù)的大小。
這種對應(yīng)關(guān)系方便解壓后的圖像還原操作。
3.3 JPG壓縮這其實(shí)是個(gè)很小的技術(shù)點(diǎn)，因?yàn)槭褂玫膲嚎s算法都是現(xiàn)成的。但是值得一提的是，JPG的壓縮率是真的高，在實(shí)驗(yàn)數(shù)據(jù)上實(shí)現(xiàn)了10-20倍的壓縮率。
使用了多線程壓縮，壓縮完過后，更新對應(yīng)的桶，這里的桶實(shí)際上就是數(shù)據(jù)片。
由主線程Main Thread反復(fù)從桶里取數(shù)據(jù)片(t1)，每取1片發(fā)送一次，然后再取下一片（t2），直到所有桶都被取了一次（例子中有10片）。
至此，一張圖片的分片數(shù)據(jù)被全部取完，于是開始統(tǒng)計(jì)一些FPS相關(guān)信息。
3.4 接收隊(duì)列接收端開了10個(gè)線程用于異步socket接收數(shù)據(jù)片。
為了保證接收端產(chǎn)生絲滑的視頻效果，使用接收隊(duì)列是個(gè)不錯(cuò)的選擇。本文使用了2個(gè)隊(duì)列的設(shè)計(jì)。實(shí)現(xiàn)數(shù)據(jù)接收的二級緩沖。示意圖如下：
這樣一來，視頻效果明顯絲滑了很多。
4. 遇到的坑及解決辦法4.1. Windows防火墻巨坑，最好都關(guān)了。
同一臺路由器的5G和2.4G頻段有時(shí)候不能互相ping通，要確保兩個(gè)電腦連接在同一頻段上。
4.3. Wifi配置如果上述設(shè)置都對了，但是還是ping不通。將wifi連接設(shè)置成專用網(wǎng)絡(luò)，也許就能解決問題。
個(gè)人PC的性能是較大瓶頸，尤其是單機(jī)測驗(yàn)的時(shí)候（本地兩個(gè)終端，一個(gè)發(fā)送、一個(gè)接收），CPU使用率分分鐘到100%。聽某個(gè)技術(shù)大哥說要使用GPU壓縮。
用兩臺電腦，一臺接收一臺發(fā)送之后，效果要好很多。
4.5. OpenCV讀取攝像頭大坑由于攝像頭驅(qū)動的關(guān)系，在我的電腦上需要設(shè)置以下兩個(gè)變量，才能成功啟用外置的720p攝像頭。
os.environ['OPENCV_VIDEOIO_DEBUG'] = '1'os.environ['OPENCV_VIDEOIO_PRIORITY_MSMF'] = '0'
即使如此，如果不做額外的設(shè)置，讀出來的圖片將是480p的（看起來很像是720p被壓縮過后的）。所以如果要傳輸真·720p，還需要設(shè)置讀出的圖像大小，如下：
self.stream = cv2.VideoCapture(1) # 讀取第一個(gè)外置攝像頭self.stream.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) # floatself.stream.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) # float4.6. Socket卡頓
不知道是不是我寫的有問題，感覺多線程的socket會爭搶資源（發(fā)送和接收的線程間，對應(yīng)5.1節(jié)功能），造成接收端的畫面顯示將變得卡頓。
5. 尚未Bug Free的功能5.1 使用TCP回傳幀率信息為了計(jì)算網(wǎng)絡(luò)時(shí)延，采取類似伽利略測光速的方法。從數(shù)據(jù)包打包之前，到對方收到數(shù)據(jù)包之后，再將這個(gè)數(shù)據(jù)回傳到發(fā)送方。
這樣就不存在兩臺機(jī)器時(shí)間差校準(zhǔn)的問題。
該算法的大致流程如下圖所示。
這種計(jì)算方式應(yīng)該是自己的實(shí)驗(yàn)環(huán)境下比較準(zhǔn)確的方法了。
時(shí)延信息的反饋不需要特別快（比如200-500ms發(fā)送一次），所以使用TCP技術(shù)
其實(shí)TCP和UDP在使用Python編程的時(shí)候代碼差距可以說極小…
但是！！！
自己目前在實(shí)現(xiàn)信息回傳的時(shí)候，會莫名卡頓起來。
接收端建立回傳的socket之后，甚至還沒傳輸數(shù)據(jù)，整個(gè)程序運(yùn)行起來就變得非常卡頓，這個(gè)讓我比較苦惱，目前正在找bug.
5.2 擁塞控制 （流量控制）的算法這部分的思想是流量控制，感謝評論區(qū)指正。
5.1節(jié)如果一并回傳接收端隊(duì)列狀態(tài)信息。如果接收端隊(duì)列太滿，說明來不及處理視頻幀了，從而對發(fā)送端的發(fā)送速度進(jìn)行控制，才是“擁塞控制”
這個(gè)本來是想著和5.1綜合起來用的，已經(jīng)寫好了，但是還沒能真正展現(xiàn)價(jià)值，設(shè)計(jì)是否合理也值得商榷。
控制的是發(fā)送端的發(fā)送頻率，從而實(shí)現(xiàn)接收端的流暢播放
思想和TCP的擁塞控制一樣慢增長，快下降。如果接收端的隊(duì)列一直處于較空的狀態(tài)，則表明還有一定的性能剩余，此時(shí)可以緩慢加快發(fā)送的頻率；如果檢測到接收端隊(duì)列中數(shù)據(jù)較多，表明發(fā)送速度太快來不及顯示，這時(shí)候就大幅下降發(fā)送的頻率。
這個(gè)擁塞控制的算法基于幾個(gè)假設(shè)：
1.網(wǎng)絡(luò)情況良好，丟包率比較低；
2接收端電腦的性能足夠高，來得及處理解包、顯示圖像。
如果5.1能夠正確實(shí)現(xiàn)，則應(yīng)該根據(jù)網(wǎng)絡(luò)時(shí)延的大小來控制發(fā)送的頻率。
這個(gè)項(xiàng)目是一周的時(shí)間內(nèi)完成的，目前還有點(diǎn)bug。小組內(nèi)的成員分別在不同技術(shù)方向上進(jìn)行了探索，收獲都還挺大的。這篇博客就當(dāng)一個(gè)項(xiàng)目總結(jié)吧，寫的難免有紕漏之處。
github地址：https://github.com/820fans/UDP-Video-Transfer
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持好吧啦網(wǎng)。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。
網(wǎng)公網(wǎng)安備