????阿里妹導讀：如果你在追劇時喜歡看彈幕、發(fā)彈幕，那你一定知道有些劇里彈幕甚至比劇情還要精彩，比如上過熱搜的出自《東宮》的那一句“談戀愛嗎?滅你全族的那種”。正是由于這些神一般的網(wǎng)友頻頻曝出精句，讓某些劇集精彩程度翻了幾倍，甚至有大量網(wǎng)友來追劇是被彈幕吸引來的。今天，阿里文娛高級開發(fā)工程師 神滅介紹一種彈幕新玩法，讓彈幕的可玩性更高。

喜歡用優(yōu)酷看視頻發(fā)彈幕的同學應該已經(jīng)發(fā)現(xiàn)，最新版本上很多劇都上線了全新的基于AI人臉識別的跟隨彈幕，以往的普通彈幕或高級彈幕都是在播放器頂端自右向左以跑馬燈式的效果展示，而這種跟隨彈幕是以氣泡樣式掛在人物頭像旁邊，隨著人物移動而移動。這種跟隨彈幕可玩性更高，有才網(wǎng)友可發(fā)揮余地更大，下面就列舉幾個例子。

結合人物動作的玩法： 

??

 結合人物所處場景的玩法：

??

 自編自導人物對話：

??

  ??

 從幾個視頻demo中可以看出，相比普通彈幕，這種跟隨彈幕是以一種類似劇中人物的內(nèi)心OS的方式展示出來的，與視頻無割離感，更有趣更新穎更精彩，有更多玩法。

本文主要講訴一下跟隨彈幕是如何展示的，從構架圖開始講解實現(xiàn)流程;再由開發(fā)過程中遇到的棘手問題，分享技術策略;最后分享未來規(guī)劃。

一、跟隨彈幕架構圖

 ??

 整個流程自下而上，分成算法側、服務端、客戶端三層：

首先，算法側按每秒25幀的頻率進行視頻抽幀，對每一幀進行人臉識別，配合人臉跟蹤和平滑處理，生成每一幀的人臉元數(shù)據(jù);

其次，服務端將多個幀的人臉元數(shù)據(jù)通過降噪、防抖、合并后組合成一組組的人臉組數(shù)據(jù)，將該數(shù)據(jù)與跟隨彈幕數(shù)據(jù)一起下發(fā)給客戶端;

最后，客戶端在互動SDK中將每組人臉數(shù)據(jù)生成一個腳本，腳本中完成彈幕跟隨該人臉軌跡的移動而移動。

下面著重介紹下每個模塊或子模塊完成的任務：

1.算法側

1) 視頻抽幀模塊：將視頻流按每秒25幀(可配置)的頻率抽幀。抽幀頻率越高，人臉移動軌跡越平滑，但后面人臉識別算法耗時也隨之增加;

2) 模型訓練模塊：提供多張多角度劇中出現(xiàn)的人物圖像，給模型訓練模塊來訓練，生成對應人臉庫，再配合已訓練完成的明星庫，這兩個庫可以大大提高人臉檢測的準確度;

3) 人臉檢測：識別每一幀圖像中的人臉，并給出坐標;

4) 人臉跟蹤：為方便服務端生成人臉的運動軌跡，需要把連續(xù)幾幀中的相同人臉標記出來;

5) 平滑處理：由于每幀中識別出的人臉坐標有一定的偏移量，所以整段人臉軌跡中會出現(xiàn)抖動現(xiàn)象，平滑處理就是通過微調(diào)每幀人臉坐標讓整個人臉移動軌跡更平滑。

2.服務端

1) 降噪：算法側不關心每一幀上到底哪張人臉重要或不重要，所以會有大量的路人臉是出現(xiàn)一秒不到就消失的，這種無意義的噪點需要直接過濾掉，即降噪處理;

2) 防抖：如果算法側平滑處理未達到要求，人臉在運動過程中還是有抖動，服務端可以對元數(shù)據(jù)進行二次加工，讓人臉移動更平滑;

3) 合并：算法側吐出的都是每一幀的元數(shù)據(jù)，但客戶端關心的是一張人臉由出現(xiàn)到消失的整個軌跡過程，服務端會把元數(shù)據(jù)合并成一組組人臉的軌跡數(shù)據(jù)，即人臉組數(shù)據(jù);

4) 氣泡彈幕數(shù)據(jù)：跟隨彈幕的數(shù)據(jù)，每條彈幕都對應著一張人臉，也指定了彈幕開始展示的時該。

3.客戶端

1) 互動SDK模塊：加載各種互動腳本，每個腳本都是一個小的互動，比如電影評分、百科tips、雙流酷看等。利用了互動SDK的基礎能力，這里把每張人臉由出現(xiàn)到消失的整個過程當做一個小的互動腳本;

2) 人臉腳本：人臉腳本中包含著該張人臉的軌跡坐標和對應該張人臉的彈幕氣泡數(shù)據(jù)，腳本中有個定時器在輪詢，查找著當前時刻對應人臉的坐標，如果該時刻有跟隨彈幕數(shù)據(jù)則把該數(shù)據(jù)展示在人臉旁邊，繼續(xù)輪詢即達到了彈幕氣泡跟隨人臉移動的效果。

二、為什么不通過客戶端直接識別人臉?

1. 實時觀看對于時間要求太高

對于客戶端來說，最終需要知道的是一張張人臉由出現(xiàn)到消失整個軌跡過程，如果客戶端做識別，目前只能識別到某一幀中人臉數(shù)據(jù)，追蹤、平滑處理、防抖、過濾、合并，這整個過程下來耗時太大，根本無法滿足用戶實時觀看的需求;

2. 端側識別準確度達不到要求

先前做彈幕穿人時，iOS端接入過AliNN提供的SDK，人臉檢測還是偶而出現(xiàn)未檢測到的情況，如果人臉檢測準確度上不能達到要求，必須自己做補幀處理，這個補幀處理很難做到實時;

3. 端側識別影響用戶體驗

端側識別時手機cup消耗增大，即耗電量會增大，同時可能也影響到播放器卡頓率。

三、棘手的問題

1.在即將切鏡頭時發(fā)跟隨彈幕，如何停留的問題

用戶發(fā)彈幕的時刻恰好在人臉馬上消失的時刻(比如馬上要切鏡頭)，這時由于人臉會馬上消失，而其它人臉會馬上出來，問題來了，如果為了保證用戶能看到自己發(fā)的彈幕，那這條跟隨彈幕就需要強制在屏幕上停留幾秒，但就因為這幾秒鐘導致切鏡頭后這條跟隨彈幕很尷尬。測試同學反饋說彈幕在切鏡頭后很奇怪，給人一種“天空飄來一句話”的感覺。

對這個問題，最終我們的解決辦法是切鏡頭前一刻發(fā)的跟隨彈幕，在切鏡頭后直接跑漸隱效果，這樣即保證了用戶能看清自己的彈幕又保證不會尷尬地掛在下一個鏡頭的人臉上。視頻效果如下： 

??

 ??

 2.大劇熱綜頻繁剪輯導致人臉數(shù)據(jù)時間軸錯亂的問題

一個視頻特別是綜藝上線后，會時不時地多次剪輯。一旦剪輯后，人臉數(shù)據(jù)和進度條時間會錯位，運營同學可能會給出一個大概時間比如在一分二十秒位置剪掉十秒這樣的數(shù)據(jù)，但人臉數(shù)據(jù)必須與進度條時間在毫秒級單位上對應，否則會出現(xiàn)明顯延遲或超前。如果重跑數(shù)據(jù)，可能需要幾個小時下線掉該功能，如果要復用數(shù)據(jù)就必須知道精確的毫秒值，然后剪切部分之后的人臉及彈幕數(shù)據(jù)全部做偏移處理，所以問題就是如何獲取精確的剪切時長。

按照如下方式，只需要跑新視頻剪切點前后一小段人臉數(shù)據(jù)，即可計算出剪切的毫秒級時間，然后將原視頻中在剪切點后的人臉數(shù)據(jù)及彈幕數(shù)據(jù)全部偏移對應時間即解決了數(shù)據(jù)錯位問題。

 ??

 四、未來展望

劇中的人臉數(shù)據(jù)如果只應用在跟隨彈幕中就大材小用了，下一步我們準備把帶有人臉數(shù)據(jù)和人體數(shù)據(jù)的腳本做為基本腳本，后面除了跟隨彈幕腳本，還會有彈幕穿人腳本等等。后續(xù)客戶端這部分架構可能會調(diào)整，見下圖。方便大家通過外部注入等方式，構建自己想要的腳本。 ??

所以當你有了創(chuàng)新點子，也需要使用到人臉人體數(shù)據(jù)時，可以繼承自基本腳本拿到數(shù)據(jù)后直接定制自己想要的功能，借助成熟的優(yōu)化過的人臉人體數(shù)據(jù)，快速地完成demo。

比如YY一個場景，由于某些原因，需要給明星A所出現(xiàn)的鏡頭打上馬賽克，或下掉明星A參演的電影。下掉電影肯定不能接受，畢竟花了大價錢買版權;靠人工對大量鏡頭重新剪輯又不現(xiàn)實，這就到了考驗各視頻APP技術能力的時候了。我們借助互動SDK提供的能力，通過已經(jīng)下發(fā)的人臉I(yè)D判斷出是明星A時給下發(fā)的人臉框打上馬賽克，問題就解決了。