如果你在追劇時喜歡看彈幕、發彈幕，那你一定知道有些劇裏彈幕甚至比劇情還要精彩，比如上過熱搜的出自《東宮》的那一句“談戀愛嗎？滅你全族的那種”。正是由於這些神一般的網友頻頻曝出精句，讓某些劇集精彩程度翻了幾倍，甚至有大量網友來追劇是被彈幕吸引來的。
喜歡用優酷看視頻發彈幕的同學應該已經發現，最新版本上很多劇都上線了全新的基於 AI 人臉識別的跟隨彈幕，以往的普通彈幕或高級彈幕都是在播放器頂端自右向左以跑馬燈式的效果展示，而這種跟隨彈幕是以氣泡樣式掛在人物頭像旁邊，隨着人物移動而移動。這種跟隨彈幕可玩性更高，有才網友可發揮餘地更大，下面就列舉幾個例子。
結合人物動作的玩法：
結合人物所處場景的玩法：
自編自導人物對話：
從幾個視頻 demo 中可以看出，相比普通彈幕，這種跟隨彈幕是以一種類似劇中人物的內心 OS 的方式展示出來的，與視頻無割離感，更有趣更新穎更精彩，有更多玩法。
本文主要講訴一下跟隨彈幕是如何展示的，從構架圖開始講解實現流程；再由開發過程中遇到的棘手問題，分享技術策略；最後分享未來規劃。
一、跟隨彈幕架構圖
整個流程自下而上，分成算法側、服務端、客戶端三層：
首先，算法側按每秒 25 幀的頻率進行視頻抽幀，對每一幀進行人臉識別，配合人臉跟蹤和平滑處理，生成每一幀的人臉元數據；
其次，服務端將多個幀的人臉元數據通過降噪、防抖、合併後組合成一組組的人臉組數據，將該數據與跟隨彈幕數據一起下發給客戶端；
最後，客戶端在互動 SDK 中將每組人臉數據生成一個腳本，腳本中完成彈幕跟隨該人臉軌跡的移動而移動。
下面着重介紹下每個模塊或子模塊完成的任務：
- 算法側
1）視頻抽幀模塊：將視頻流按每秒 25 幀（可配置）的頻率抽幀。抽幀頻率越高，人臉移動軌跡越平滑，但後面人臉識別算法耗時也隨之增加；
2）模型訓練模塊：提供多張多角度劇中出現的人物圖像，給模型訓練模塊來訓練，生成對應人臉庫，再配合已訓練完成的明星庫，這兩個庫可以大大提高人臉檢測的準確度；
3）人臉檢測：識別每一幀圖像中的人臉，並給出座標；
4）人臉跟蹤：爲方便服務端生成人臉的運動軌跡，需要把連續幾幀中的相同人臉標記出來；
5）平滑處理：由於每幀中識別出的人臉座標有一定的偏移量，所以整段人臉軌跡中會出現抖動現象，平滑處理就是通過微調每幀人臉座標讓整個人臉移動軌跡更平滑；
- 服務端
1）降噪：算法側不關心每一幀上到底哪張人臉重要或不重要，所以會有大量的路人臉是出現一秒不到就消失的，這種無意義的噪點需要直接過濾掉，即降噪處理；
2）防抖：如果算法側平滑處理未達到要求，人臉在運動過程中還是有抖動，服務端可以對元數據進行二次加工，讓人臉移動更平滑；
3）合併：算法側吐出的都是每一幀的元數據，但客戶端關心的是一張人臉由出現到消失的整個軌跡過程，服務端會把元數據合併成一組組人臉的軌跡數據，即人臉組數據；
4）氣泡彈幕數據：跟隨彈幕的數據，每條彈幕都對應着一張人臉，也指定了彈幕開始展示的時刻。
- 客戶端
1）互動 SDK 模塊：加載各種互動腳本，每個腳本都是一個小的互動，比如電影評分、百科 tips、雙流酷看等。利用了互動 SDK 的基礎能力，這裏把每張人臉由出現到消失的整個過程當做一個小的互動腳本；
2）人臉腳本：人臉腳本中包含着該張人臉的軌跡座標和對應該張人臉的彈幕氣泡數據，腳本中有個定時器在輪詢，查找着當前時刻對應人臉的座標，如果該時刻有跟隨彈幕數據則把該數據展示在人臉旁邊，繼續輪詢即達到了彈幕氣泡跟隨人臉移動的效果。
二、爲什麼不通過客戶端直接識別人臉？
- 實時觀看對於時間要求太高。
對於客戶端來說，最終需要知道的是一張張人臉由出現到消失整個軌跡過程，如果客戶端做識別，目前只能識別到某一幀中人臉數據，追蹤、平滑處理、防抖、過濾、合併，這整個過程下來耗時太大，根本無法滿足用戶實時觀看的需求。
- 端側識別準確度達不到要求。
先前做彈幕穿人時，iOS 端接入過 AliNN 提供的 SDK，人臉檢測還是偶而出現未檢測到的情況，如果人臉檢測準確度上不能達到要求，必須自己做補幀處理，這個補幀處理很難做到實時。
- 端側識別影響用戶體驗。
端側識別時手機 cup 消耗增大，即耗電量會增大，同時可能也影響到播放器卡頓率。
三、棘手的問題
- 在即將切鏡頭時發跟隨彈幕，如何停留的問題
用戶發彈幕的時刻恰好在人臉馬上消失的時刻（比如馬上要切鏡頭），這時由於人臉會馬上消失，而其它人臉會馬上出來，問題來了，如果爲了保證用戶能看到自己發的彈幕，那這條跟隨彈幕就需要強制在屏幕上停留幾秒，但就因爲這幾秒鐘導致切鏡頭後這條跟隨彈幕很尷尬。測試同學反饋說彈幕在切鏡頭後很奇怪，給人一種“天空飄來一句話”的感覺。
對這個問題，最終我們的解決辦法是切鏡頭前一刻發的跟隨彈幕，在切鏡頭後直接跑漸隱效果，這樣即保證了用戶能看清自己的彈幕又保證不會尷尬地掛在下一個鏡頭的人臉上。視頻效果如下：
- 大劇熱綜頻繁剪輯導致人臉數據時間軸錯亂的問題
我們知道一個視頻特別是綜藝上線後，會時不時地多次剪輯，一旦剪輯後，人臉數據和進度條時間會錯位，運營同學可能會給出一個大概時間比如在一分二十秒位置剪掉十秒這樣的數據，但人臉數據必須與進度條時間在毫秒級單位上對應，否則會出現明顯延遲或超前。如果重跑數據，可能需要幾個小時下線掉該功能（不能接受），如果要複用數據就必須知道精確的毫秒值，然後剪切部分之後的人臉及彈幕數據全部做偏移處理，所以問題就是如何獲取精確的剪切時長。
按照如下方式，只需要跑新視頻剪切點前後一小段人臉數據，即可計算出剪切的毫秒級時間，然後將原視頻中在剪切點後的人臉數據及彈幕數據全部偏移對應時間即解決了數據錯位問題。
四、未來展望
劇中的人臉數據如果只應用在跟隨彈幕中就大材小用了，下一步我們準備把帶有人臉數據和人體數據的腳本做爲基本腳本，後面除了跟隨彈幕腳本，還會有彈幕穿人腳本等等。後續客戶端這部分架構可能會調整，見下圖。方便大家通過外部注入等方式，構建自己想要的腳本。
所以當你有了創新點子，也需要使用到人臉人體數據時，可以繼承自基本腳本拿到數據後直接定製自己想要的功能，藉助成熟的優化過的人臉人體數據，快速地完成 demo。
比如 YY 一個場景，由於某些原因，需要給明星 A 所出現的鏡頭打上馬賽克，或下掉明星 A 參演的電影。下掉電影肯定不能接受，畢竟花了大價錢買版權；靠人工對大量鏡頭重新剪輯又不現實，這就到了考驗各視頻 APP 技術能力的時候了。我們藉助互動 SDK 提供的能力，通過已經下發的人臉 ID 判斷出是明星 A 時給下發的人臉框打上馬賽克，問題就解決了。
作者 | 阿里文娛高級開發工程師 神滅