实时远程医学影像服务质量保障与网络优化
?
實時遠程醫(yī)學影像產品對圖像傳輸的失真、卡頓、延時的要求尤為嚴苛。在LiveVideoStackCon2019深圳大會上,華大智造音視頻技術專家 黃翠萍詳細了介紹如何在現有網絡保障實時遠程醫(yī)學影像的服務質量及在網絡方面所做的優(yōu)化。
?
文 / 黃翠萍
整理 / LiveVideoStack
1
產品介紹
華大影像團隊成立的意義:通過集成機器人技術、實時遠程控制技術及超聲影像技術,解決偏遠地區(qū)、基層醫(yī)療機構缺少超聲醫(yī)生、以及現有醫(yī)生超負荷工作的現狀;打破傳統(tǒng)超聲診療方式的局限,克服時空的障礙,改善醫(yī)療資源分布不均衡的現狀;使全民平等的享受優(yōu)質的醫(yī)療服務。
2
面臨挑戰(zhàn)
在遠程醫(yī)療視頻方面的挑戰(zhàn)主要有三方面:失真、卡頓、延時。
失真:醫(yī)生最關注遠程超聲視頻能否保證醫(yī)生診斷準確,0誤診
卡頓:超聲影像為動態(tài)實時,出現卡頓,會導致醫(yī)生需要反復確認,降低檢查效率
延時:醫(yī)生通過操作遠程機械臂進行超聲檢查,手法對應超聲視頻同步要求高
?
為了應對挑戰(zhàn),首要任務是分析產品產生失真、卡頓、延時的原因是什么?
失真主要由以下三個模塊產生:
發(fā)送端:數據采集、前處理、視頻編碼壓縮產生失真;
網絡側:丟包導致信息丟失及發(fā)送端為了緩解網絡擁塞主動降碼率產生失真;
接收端:視頻數據不全解碼殘幀產生失真。
卡頓主要由三部分產生,人眼最高捕獲幀率為30幀每秒,當幀間間隔分布不均、渲染幀率過低,人會感知卡頓。
發(fā)送端:如果發(fā)送端發(fā)送的幀率偏低,例如通訊軟件的幀率一般在15幀每秒,幀率的流暢性不符合醫(yī)學要求;
網絡端:弱網延時過大、或視頻幀丟失,會產生冥想卡頓;
接收端:如果幀率為30幀每秒的幀率可以穩(wěn)定的情況下,不會感覺明顯卡頓,但是如果幀率不穩(wěn)定,忽高忽低情況下,用戶就會感知卡頓,會降低用戶體驗。
根據ITU-T G.114國際標準規(guī)定,端到端的延時控制在200毫秒以內時,則用戶體驗良好,整體感知不到明顯延時,對于我們產品的延時主要有兩大類:固有延時和網絡延時。
?
系統(tǒng)固有延時:僅僅指端的采集、視頻編解碼的延時;
網絡延時:不僅僅指網絡傳輸的延時,會增加抗網絡丟包和抖動的手段,例如NACK、FEC本身引入的緩存所導致的延時,可以歸類為網絡延時。
?
根據通訊行業(yè)標準規(guī)定,網絡質量分為良好、較差、惡劣三個等級,實際在互聯網應用中發(fā)現,大多數網絡并不滿足如圖所示行業(yè)標準規(guī)定。一般網絡環(huán)路延時大概在70、80毫秒左右,丟包在8%左右,因此如果想要提供良好的遠程服務,控制系統(tǒng)的固有延時和網絡延時需要在200毫秒以內。
通過分析總結出4個模塊內容可進行優(yōu)化:
降低系統(tǒng)固有失真優(yōu)化
降低系統(tǒng)固有延時優(yōu)化
視頻播放幀率平滑優(yōu)化
網絡抗丟包和抖動優(yōu)化
3
應對措施
對于醫(yī)生面對產品所產生的顧慮:是否會導致誤診?
?
使用體模方式把關超聲視頻質量,針對掃描不同的臟器器官購買了不同的體模,進行0失真驗證;再增加psnr+ssim+vamf方式把關視頻質量,以保證在任何情況下,在發(fā)送端發(fā)送0失真數據,完善把關方法后,就可以分析發(fā)送端到接收端中所有可優(yōu)化的點,進而采取相應優(yōu)化措施。結合網絡質量動態(tài)優(yōu)化編碼算法,在高碼率的情況下保證速度優(yōu)先,低碼率情況下保證質量優(yōu)先,中等碼率情況下均衡二者的關系。對于接收端,使用私有協(xié)議對視頻報文、幀、幀間參考關系進行完整性判斷,其中首先對RTP報文的完整性進行判斷,如若不完整則使用HARQ進行重傳修復,如若單幀不完整則采取丟幀操作等對應的操作,以保證接收端接受的信息無異常并且高質量及完整。
網絡RTT延時大多在80毫秒左右,同時要考慮RTT對NACK的影響等,留給系統(tǒng)的固有延時非常有限。因此進行端到端分析引入延時的點有:
采集設備選型:視頻采集幀率60fps。在醫(yī)學實際應用中,很多情況要求采集幀率高,例如心臟科等。
數據傳輸優(yōu)化:減少采集數據轉換。視頻采集可用MGP或YUV格式,針對不同情況,選用對視頻傳輸最有利的格式。
編解碼器優(yōu)化:禁止編碼B幀。
渲染性能優(yōu)化:openGL渲染。
系統(tǒng)性能優(yōu)化:熱點函數優(yōu)化、親核設計。
經過優(yōu)化的超聲系統(tǒng)的固有延時控制在40-50毫秒左右。
?
如若沒有經過任何緩存,直接播放情況下視頻播放時間由:采集時間、編碼延時、解碼延時、渲染延時共同決定,對于以上幾種延時情況較為穩(wěn)定,而網絡傳輸延時是影響視頻能否平穩(wěn)播放的主要因素,因此系統(tǒng)就需要根據網絡延時情況配置合理的緩存時間,同時,接收端使用濾波算法,綜合考慮傳輸大幀引起的延時、網絡噪聲引起的延時以及幀間間隔,計算合理的視頻播放時間,平滑渲染幀率,以保證視頻平穩(wěn)播放。
冗余協(xié)議局限性及優(yōu)化
常用的抗網絡丟包方法有冗余、重傳和SVC編碼,但這三種方法各有優(yōu)缺點。例如RFC 2198冗余協(xié)議的性價比低;XOR_FEC協(xié)議性價比略高,但恢復能力有限;RS_FEC冗余算法的恢復能力強,但合適的冗余度配置度較難。
常規(guī)算法:當前丟包率、丟包率加權平均值(恢復能力差)、窗口期最大丟包率(帶寬利用率低)。
遠程超聲冗余度配置方法:卡爾曼+窗口期最大丟包率加權平均值,同時使用多幀FEC冗余機制和深度優(yōu)化參數,根據視頻幀率、RTT環(huán)路延時,動態(tài)調整FEC冗余幀數,以保證視頻傳輸實時性。
重傳協(xié)議局限性及優(yōu)化
ACK重傳:TCP常用,收到報文則進行ACK響應,其缺點是帶寬利用率低,效率差
NACK重傳:音視頻領域常用,帶寬利用率明顯提升,其缺點是受RTT延時影響嚴重。在環(huán)路延時較大時,會引入系統(tǒng)延時高。
針對RTT延時對NACK的影響較嚴重的問題,針對不同情況提出三種應對策略:
RTT延時在50ms以下,適合使用ONLY NACK保護機制。即使用RTT/2作為是否進行丟包緩沖延時的判別標志;使用重傳次數的RTT倍的時長作為是否進行多次重傳延時的判別標志。
RTT延時在50-100ms之間,適合使用HARQ,以FEC數據恢復為主,NACK輔助。
RTT延時在100ms以上,則不適合使用NACK保護機制,否則用戶延時感知明顯。
時間可適編碼局限性及優(yōu)化
SVC時間可適性編碼:通過改變幀間參考關系,降低丟一幀導致整個GOP都不可用的概率,但是增加了時間冗余度信息,導致編碼后的碼率上升。對于超聲影像,幀間幅度的改變較小,但每增加一層Temporal Layer,實測碼率會上浮10%。
低延時、低丟包網絡下,僅使用NACK抗丟包保護。
高延時、高丟包網絡下,僅使用SVC抗丟包保護。
其他情況,使用SVC+HARQ抗丟包保護,策略是,在SVC不同TL層,使用不同的FEC、NACK保護力度,重點保護TL0層,盡力保護其余層。
智能選路
由于NAT原因,很多網絡不能丟P2P,需要租用服務器,但是網絡中跨運營商之間易產生大量丟包,例如從移動切換到電信網絡,丟包至少10%,因此需要租用多臺BGP網絡服務器。
對于多臺BGP網絡服務器的路徑選擇問題,使用心跳機制(目前所使用的方式)或使用RTX重傳報文、FEC冗余報文實時探測網絡RTT、丟包率等網絡QOS,根據反饋,綜合考慮負載均衡等因素,動態(tài)調整網絡傳輸路徑。
4
成果展示
如圖是項目應用情況,經過若干優(yōu)化工作后,目前遠程超聲項目可以在RTT延時100毫秒以內,網絡丟包30%以內,實現0失真、0卡頓、低延時傳輸。
5
未來展望
華大智造是為了解決就醫(yī)難而成立,未來有以下幾方面的展望:
遠程計移動超聲診斷:借助5G網絡,進一步將遠程計移動超聲覆蓋更多有需要的地方;
醫(yī)學影像云服務:綜合5G+AI+云技術,為醫(yī)生和患者提供更快捷、更準確的診斷體驗。
通過不斷技術更新,進而實現智慧醫(yī)院整體方案和智慧醫(yī)療平臺。
相關鏈接
Akamai Martin Hor?i?ka:最新網絡優(yōu)化技術及編程語言分析
Facebook:對比COPA 與CUBIC,BBR v1在擁塞控制及視頻質量的表現
實時視頻傳輸中的BBR擁塞控制
LiveVideoStackCon 2020
上海/北京/舊金山 講師招募
2020年LiveVideoStackCon將持續(xù)迭代,LiveVideoStackCon將分別在上海(6月13-14日),北京(9月11-12日)和舊金山(11月)舉行。歡迎將你的技術實踐、踩坑與填坑經歷、技術與商業(yè)創(chuàng)業(yè)的思考分享出來,獨樂不如眾樂。請將個人資料和話題信息郵件到 speaker@livevideostack.com 或點擊【閱讀原文】了解成為LiveVideoStackCon講師的權益與義務,我們會在48小時內回復。
超強干貨來襲 云風專訪:近40年碼齡,通宵達旦的技術人生總結
以上是生活随笔為你收集整理的实时远程医学影像服务质量保障与网络优化的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Netflix选择AVIF作为下一代图片
- 下一篇: 当SRS遇到K8s:如何实现高可用、回滚