工業技術研究院 資訊與通訊研究所 鍾國煌 薛德輝 高志忠 劉柏凱 許振嘉 Yerule Sanket Nagnath

工研院研發AI導播技術，應用於桌球賽事轉播，減輕拍攝團隊人力負擔。

球賽賽事轉播是由多位不同角色組成的團隊所共同完成；本技術著重於以AI（Artificial Intelligence）導播技術減輕傳統拍攝團隊中攝影師及導播的工作負擔。在球賽轉播中，攝影團隊會配置多名攝影師，每名攝影師被賦予各自的任務，並視比賽狀態捕捉場上各種精彩鏡頭；導播做為球賽賽事轉播的靈魂人物，負責視賽事狀況指揮各攝影師拍攝的角度，並切換適當的鏡頭。本文以桌球賽事轉播為例，闡述AI導播技術可協助拍攝團隊進行拍攝，在減輕拍攝團隊人力負擔的同時，也產出高品質的球賽賽事轉播內容。

系統架構 

做為球賽轉播的主要工作團隊，攝影師負責從不同角度拍攝賽事現場畫面，導播則需時時刻刻緊盯賽事狀況，適時切換不同畫面呈現給觀眾，皆是需要大量時間及專注力的工作。

AI導播技術可依事先設定參數，協助攝影師控制攝影機進行拍攝，攝影機可自動辨識場上的人群，並判斷有興趣的人物自動進行追蹤，同時需接收比賽狀態的訊息進行運鏡切換；另外，也可在賽事進行中，依據比賽狀態協助導播適時進行畫面切換，讓觀眾在適當的時刻看到有興趣的鏡頭，可大幅降低現行賽事轉播所需的人力，並提供高品質的賽事轉播內容。

AI運鏡技術 

運動賽事局面瞬息萬變，即時追蹤掌握核心運動選手的位置並捕捉其精湛嫻熟的運動技巧和高亢激昂或懊惱惋惜的表情畫面，是AI運鏡系統核心開發的目的。

1.AI運鏡系統架構

AI運鏡架構如圖2，系統前端採用AW-UE150[1]PTZ攝影機與Spark Pro視訊轉換設備將運動選手畫面傳送給PTZ AI Server進行人像追蹤分析，AI Server中包含物件偵測與追蹤（Object Detection&Tracking）進行人像辨識追蹤，並將辨識到的目標選手人像座標輸出給PTZ Tracking模組進行鏡頭角度調整和變焦縮放。另外該系統也接收動作姿態辨識主機（Decision Server）所判斷比賽當下的狀態訊號，例如是否為發球、攻防、得分等情況，藉由這些訊號調整相機鏡位。

圖2 AI運鏡系統架構圖

2.人像追蹤
運動賽事現場的人像辨識追蹤技術會遭遇許多挑戰，包含短時間內的劇烈肢體運動與大幅度的身體位移，及多人同時出現在畫面中且不時會遮擋目標選手等情況皆會導致電腦辨識追蹤人像時的困惑而降低辨識追蹤精準度。

工研院團隊採用了AI開源物件追蹤技術[2][3]，並針對專案需求重新淬鍊AI模型，導入清晰且數量多的crowdhuman人像資料集強化AI模型，使其在複雜多變的比賽現場中較能精準辨識運動比賽選手和回傳選手座標，此外工研院團隊更進一步添加了智能攝影機的狀態機制功能協助追蹤人像，在選手被人群等其他物體短暫遮住時，該狀態機制追蹤技術能夠在選手重新出現時即時找回選手身影，且辨識幀數達到30FPS/S。其中所涵蓋的技術包括，（1）物件偵測（Object Detection）：採用了性能優越的免錨點（anchor-free）機制的中心點網路（CenterNet）架構來偵測人像。
（2）物件追蹤（Object Tracking）：結合了偵測前景物件、卡爾曼濾波器（Kalman Filter）預測人像移動位置和特徵識別（ID-feature）核對新偵測到的人像特徵是否與選手特徵接近等3項機制，這些機制確保了可以從多個人像中找出感興趣的比賽選手人像。

3.PTZ相機人物特寫追蹤控制
PTZ攝影機的鏡頭可以進行左右轉動（Pan）、上下傾斜（Tile）與縮放（Zoom in/out）等不同的功能。AI運鏡技術中的PTZ相機人物追蹤控制，是以人像追蹤模組輸出的人像座標當作追蹤標的，然後分為「計算誤差值」、「計算調整值」「輸出PTZ控制命令」等3個主要步驟來完成。此3步驟概述如下：

⦁ 計算誤差值
誤差值包含相機鏡頭上下左右的拍攝角度誤差及縮放倍率誤差。由於相機畫面上的顯示的物件皆成像於相機內的感光晶片，所以拍攝角度誤差可以利用成像在畫面的相對位置與像距之間的三角關係來求得，如圖3所示。縮放倍率誤差則可以利用成像的畫面占比與目標占比的比值取log來求得。
 

圖3 計算相機鏡頭偏差角度

⦁ 計算調整值
由於選手相對於相機的位置是一直在變動的，為了穩定控制相機鏡頭的旋轉與縮放，我們應用PID控制器[4]中的PD控制單元來實現上下左右的追蹤，縮放部分則利用P控制單元來實現。

⦁ 輸出PTZ控制命令
最後將步驟2求出的調整值，透過PTZ相機控制介面模組轉化成PTZ相機的控制命令，令相機鏡頭進行左右與上下的角速度調整及縮放。
然後在每個frame中重複1～3步驟，直到誤差值收斂到可容許範圍內，即可達到人物特寫追蹤的目的。但在實際應用中，有可能發生無法偵測到人像或追丟（lose tracking），所以針對lose tracking還會增加「維持」、「減速」、「回復預設鏡位」等3階段控制機制以確保系統穩定度。

動作與姿態辨識模組 

1.環境布置與系統架設說明
動作與姿態辨識子系統運用機器學習技術實現即時理解賽場內裁判及球員之動作，並進而推論賽事狀態；透過人工智慧導播系統可提出切換畫面的判斷，減少現場導播和攝影師的工作量。為實現動作與姿態辨識子系統，桌球場上架設了3支辨識用之攝影機，其中2支用於拍攝球員、1支用於拍攝裁判動作，如圖4所示。

圖4 動作與姿態辨識子系統桌球賽場攝影架設示範圖

2.裁判動作辨識演算模組
透過攝影機畫面，動作辨識子系統將裁判動作分為左邊得分、右邊得分、左邊發球、右邊發球、暫停（或觸網）、及無動作，共6種姿態動作，如圖5所示。本系統於2021年1月10日至1月11日經由新北市中等學校運動會桌球賽共15場賽事驗證，共進行2,576次辨識，平均辨識準確率為97.4％，其混淆矩陣（Confusion matrix）於表1所示，其中RS、RP、P、LP、LS、NA分別代表右邊發球、右邊得分、暫停、左邊得分、左邊發球、無動作。

圖5 裁判動作由左而右依序為右邊得分、右邊發球、左邊得分、左邊發球、暫停（或觸網）、及無動作


表1 動作與姿態辨識子系統-裁判動作辨識混淆矩陣數據

3.球員準備發球狀態識別演算模組

透過拍攝球員的2支攝影機畫面，動作辨識子系統先找出如圖6之球員骨架節點（key-points）後，藉由觀察時間序畫面計算出左邊球員及右邊球員彎腰角度（angle）及穩固性（steadiness）的參數，若其中一位球員彎腰且兩方球員都進入穩固狀態，則判定為準備發球，其中代表第n個畫面第0號骨架節點。

圖6 骨架節點定義

第一步，我們計算頸部kp（1）、腰部kp（8）及水平線所形成的角度視為彎腰角度，由圖6可看出當球員直立時，該角度約為90度上下。當球員彎腰時，不論是向左彎或向右彎，當角度小於70度則視為該球員彎腰。

第二步，我們計算第n張畫面，左邊球員與右邊球員分別的穩固狀態。從第n張及第n-1張畫面間，頸部、肩膀與、手肘與及手腕與頸部‖kp_n (1)-kp_(n-1) (1)‖ 、肩膀‖kp_n (2)-kp_(n-1) (2)‖ 與 ‖kp_n (5)-kp_(n-1) (5)‖、手肘‖kp_n (3)-kp_(n-1) (3)‖ 與 ‖kp_n (6)-kp_(n-1) (6)‖及手腕‖kp_n (4)-kp_(n-1) (4)‖ 與‖kp_n (7)-kp_(n-1) (7)‖間歐式距離的平均。若連續5張畫面，也就是第n張至第n-4張畫面間，的平均值皆小於20即視為雙方球員都進入穩固狀態。若其中一位球員彎腰且兩方球員都進入穩固狀態，則判定為準備發球。

本系統於2021年1月10日至1月11經由新北市中等學校運動會桌球賽共13場賽事驗證，單打賽事共進行472次辨識，雙打賽事共進行366次辨識，其中單打賽事正確判斷（True positive, Tp）準備發球447次、遺漏判斷（True negative, Tn）25次、誤判斷（False positive, Fp）23次，偵測率Recall rate為94.7％，準確率Precision rate為95.1％。雙打賽事正確判斷（True positive）準備發球335次、遺漏判斷（True negative）31次、誤判斷（False positive）10次，偵測率Recall rate為91.5％，準確率Precision rate為97.1％，整體平均偵測率Recall rate達93.3％，準確率Precision rate達96.0％，其中Recall及Precision 計算於公式1及公式2。

Recall =  T_p  ⁄  (T_p + T_n  ) ……………………………………………………….……..... （1）
Precision =  T_p  ⁄  (T_p + F_n  ) ……………………………………………………….…….....（2）

決策系統模組 

決策子系統內管理一組賽局狀態機，用以管理賽局、選手及裁判狀態，而觸發狀態機遷移之輸入訊號，則來自於動作識別計算節點所辨識出來的動作分類；當狀態機發生狀態遷移時，會依據賽局狀態發送鏡位訊號至自動運鏡計算節點中，同時，訊源切換指令也會發送至導播機中來進行轉播畫面切換，以提供觀眾如同電視球賽轉播之觀看體驗。

決策子系統為網頁應用程式，為各系統之中樞，如圖7所示，其子系統可進一步分為前端及後端，如圖8所示。後端負責連接各子系統，並管理為了某種球類比賽所訂製的狀態機；於前端部分可對後端的狀態機資訊以及各子系統（如：動作識別、自動運鏡及導播機）之連接狀態，進行資料可視化處理，亦可設定部分後端功能。

1.系統特點—狀態機設計

有別於一般狀態機設計，我們以平行狀態機（Parallel/Orthogonal State Machine）[5]實作桌球賽局狀態，如圖9所示，於賽局子狀態機中儲存賽局狀態，裁判子狀態機中儲存裁判行為狀態及選手子狀態機中儲存比賽選手準備狀態，子狀態機內之狀態意義如下：

⦁ 賽局子狀態機
   閒置：目前無任何比賽相關事件
   發球：準備進行發球
   正在進行對打：選手開始進行對打
⦁ 裁判子狀態機
   閒置：選手尚未就定位，裁判尚無任何動作
   正在關注賽局：裁判已有發球指示或發現雙方選手已就定位
⦁ 選手子狀態機
  尚未準備完畢：雙方選手尚未在球桌附近準備進行對打
  準備完畢：其中一方已有發球事實或雙方正在進行對打

此設計目的為：
⦁ 部分錯誤的動作識別結果不會導致狀態機遷移，因子狀態機間可以相互參考。
⦁ 一般真人導播於訊源切換時會參考賽局及場上人員的個別狀態進而切換導播機訊源，此平行狀態機設計上符合上述決策邏輯。

圖9 桌球規則狀態機

2.系統特點—子系統間連接與低延遲通訊

為了與真人導播切換訊源的延遲趨於一致以達到最佳的觀看體驗，各子系統間需以低延遲高效率的方式進行訊息傳輸，常見且容易實作的通訊方式為使用RESTful APIs[6]並以輪詢（Polling）的方式接收訊息，單位時間內輪詢的次數越多次，其訊息傳輸延遲越低，但帶來的頻寬占用越大，若降低輪詢次數，則又會使傳輸延遲增大，故我們使用Web Sockets通訊協定[7]，其底層以TCP全雙工的模式進行傳輸，於子系統間的訊息傳遞占用頻寬及延遲相比RESTful APIs搭配輪詢來得更低，如圖10及圖11所示。此外，為了快速部署，子系統間會以組播域名解析（multicast DNS）[8]進行服務搜索並據此進行連線，子系統間不需要知道彼此的位址及埠號，僅透過服務名稱即可相互連接，在初期網路設置上可達成零配置網路服務（Zero Configuration Networking）[9]。

圖10 輪詢及Web Sockets間的所需頻寬比較 [10]


圖11 輪詢及Web Sockets間的延遲比較 [10]

3.系統特點—資訊可視化
為了讓各子系統的連接狀態一目了然，資訊可視化也是決策子系統中的特點之一，如圖12所示，於系統儀表板中，我們能即時監看整個系統的連線狀態，而存在於後端的賽局子狀態機，會以有向圖的形式即時繪製於系統儀表板中並隨著賽局的進行動態顯示當前比賽狀態，而系統日誌用來追蹤子系統間的細部通訊過程。圖13中呈現了子系統間的網路設定頁面，我們僅需勾選服務名稱即可連接各個子系統，進而在動態主機組態協定（DHCP）的浮動環境中達到網路零配置的目的。

圖12 決策子系統之系統儀表板

圖13 決策子系統之網路設定頁面
 

AI導播技術  助賽事轉播一臂之力 

工研院資通所研發之AI導播技術，開發並整合AI運鏡、動作及姿態辨識技術、決策系統等模組，可協助一般球賽賽事轉播團隊進行拍攝，減輕攝影師及導播負擔。 然而各類球賽規則、著重的拍攝角度及切換鏡頭考量皆不同，不同的賽事轉播，須有不同的運鏡方式進行攝影，也須要對球員進行姿態動作辨識，並判斷比賽狀態，進行運鏡方式調整及畫面切換。 本技術以桌球為標的賽事，開發適用於桌球賽事場域的AI導播系統，並實際至正式桌球賽事現場進行場域驗證，未來也可依此架構，開發適用於各種球賽之AI導播系統。

參考文獻

[1] AW-UE150 4K 60p Professional PTZ Camera: https://na.panasonic.com/us/audio-video-solutions/broadcast-cinema-pro-video/professional-ptz-cameras/aw-ue150-4k-60p-professional-ptz-camera
[2] FairMOT Link : https://github.com/ifzhang/FairMOT
[3] Centernet Link : https://github.com/xingyizhou/CenterNet
[4] PID控制器-維基百科: https://zh.wikipedia.org/wiki/PID%E6%8E%A7%E5%88%B6%E5%99%A8
[5] David Harel, “Statecharts: a visual formalism for complex systems,” Science of Computer Programming, Volume 8, Issue 3, June 1987, pp.231-274
[6] https://www.redhat.com/en/topics/api/what-is-a-rest-api, What is a REST API?
[7] https://www.websocket.org/aboutwebsocket.html, About HTML5 WebSocket
[8] https://tools.ietf.org/html/rfc6762, Multicast DNS
[9] https://www.ibm.com/support/knowledgecenter/en/SSB2MG_4.6.0/com.ibm.ips.doc/concepts/gx_gv_zero_configuration.htm, What is zero configuration networking?
[10] https://www.websocket.org/quantum.html, HTML5 WebSocket: A Quantum Leap in Scalability for the Web