更多騰訊海量技術文章，請關注云+社區：https://cloud.tencent.com/developer

作者：云

進入2018年最火的新鮮事物無疑就是“直播答題”了，動輒上百萬的獎金更是吸引了大量用戶的參與。一場直播動輒

幾百萬的獎金，每人可以分到幾十元甚至百萬元，越來越多的人希望用自己的智商賺點零花錢。直播答題有多火？

多個直播平臺服務器多次遭到宕機。實際上，幾百萬人一同在線的確會帶給服務器不小的壓力，更何況是新上線的

App，他們或許還沒有想到自己會火得這么快。

近期很多直播答題app出現了個人賬號上顯示獎金額數不對、在線用戶無法進入游戲、技術故障導致游戲被迫臨時

取消等情況。某視頻平臺還出現了系統將正確答案判定錯誤的情況，導致百萬人被迫中止游戲。隔幾天就來一次的

技術故障除了說明App準備不足外，也從側面反映了這類游戲的火爆程度。為了讓眾多公司及開發者盡快趕上風口浪尖，騰訊云直播團隊也是第一時間上線了“在線知識競技解決方案”。

效果體驗

iOS平臺（ipa）：https://ww平臺(apk) ：http://dldir1.qq.com/hudongzhibo/xiaozhibo/LiteAVDemoSmart4.1.QARoom.apk

Obs Studio 定制版本（exe）：http://dldir1.qq.com/hudongzhibo/xiaozhibo/obsdistributequestion.zip

在線答題室

創建房間即可體驗主持人一端的效果；進入房間即可體驗觀眾端的效果。

iPhone 平臺的 Demo 采用了企業簽名方式，請先到“設置通用設備管理”里，添加信任證書。

Demo 僅作演示之用，用來展示騰訊云的技術能力，不代表最終產品形態，接入請仔細閱讀文檔。

體驗方式二：Obs Studio

這種體驗方式是直接使用騰訊云改造的 Obs Studio 進行推流：

• 我們在“工具”菜單欄里面加了一個“題目分發”按鈕，可以直接將題目打入直播流中，題目可以預先編輯在 ini 文件中。

• 使用 iOS 或者 Android 端的演示App，選擇 答題播放器 功能，就可以體驗觀眾端題目收取的效果了。

• OBS Studio 的使用方法，詳見 騰訊云定制版 Obs Studio 說明書（https://cloud.tencent.com/document/product/454/14129）。

SDK下載

下載地址：https://cloud.tencent.com/document/product/454/13863#SDK

我們的優勢

• 精準的“音題畫”同步

  騰訊云 SDK 和云端均支持在直播流中插入 題目 或 時間同步信令，可以實現聲音、畫面和題目彈出的完美同步。

• 超低的觀眾端延遲差

  騰訊云 SDK 的 極速播放模式 所支持的延遲修正技術，可以讓觀眾與觀眾之間延遲差在 1s 以內，從而讓觀眾的答題同步性得到保證。

• 支持微信小程序接入

  騰訊云 SDK 已經默認打包在微信版本中，并以 <liveplayer> 標簽的形式對外提供，設置 mode 為 live 模式，并將 mincache 和 maxcache 都設置為 1，即可實現非常低延遲的播放效果。

方案解讀

方案一：題目透傳方案

原理描述

• 消息發送（Obs）：如果你是在演播室使用 Obs 推流，可以直接使用騰訊云改造的 Obs Studio 替換現有的 Obs 軟件，我們在“工具”菜單欄里面加了一個“題目分發”按鈕，可以直接將題目打入直播流中，題目可以預先編輯在 ini 文件中。

• 消息發送（APP）：如果想要簡單使用 App 進行推流，可以使用騰訊云終端 SDK 的 TXLivePusher 的 sendMessage 方法，該方案能將一段buffer塞到RTMP流中（buffer的最大長度限制為10K）。

  // iOS 示例代碼 [answerPusher sendMessage:[mesg dataUsingEncoding:NSUTF8StringEncoding]];

  //Android 示例代碼 mTXLivePusher.sendMessage(questionInfo.getBytes("UTF8"));

• 消息接收：利用騰訊云 SDK 的 TXLivePlayer 的 onPlayEvent（PLAYEVTGETMESSAGE ： 2012）功能，可以在播放器播放到指定畫面的時候，同步地將 MESSAGE 通知給您的 APP，從而將題目同步地擴散到海量的觀眾端。

消息接收的接入方案可以參考我們的接入文檔（iOS平臺 | Android平臺）

方案二：NTP時間同步方案

原理描述

1. 騰訊云會每隔 1s 在您的直播流中實時插入經過 NTP 校時的國際標準時間戳。

2. 演播室的導播員根據主持人的出題節奏，在合適的時間控制發題，發題系統會在每次下發的題目中帶上當時的國際標準時間。

3. SDK 在播放這種打入時間戳的視頻流的時候，會定時通知您的 APP 當前 SDK 所播放的畫面是在什么時間錄制下來的（因為導播臺到云端一般都會有一個固定的延遲，需要您提前做一個誤差校調）。

4. 您的 APP 可以根據 SDK 的時間通知（即當前畫面是什么時間錄制的），按需顯示指定的題目即可。

總結一下：方案二跟方案一的最大區別就在于題目的擴散方式，方案二的核心思路是讓題目先通過IM通道快速送達觀眾端APP，在觀眾端先緩存下來，等待播放器通知了預期的 NTP 時間戳之后，再把題目顯示出來。

方案三：小程序解決方案

方案一和方案二都可以實現“音話題”完美同步，但是相比于這種體驗上的小優化，APP的擴散能力則是更加重要的。小程序恰恰提供給了APP可以病毒式傳播的能力。

騰訊云 SDK 已經默認打包在微信版本中，并以 <liveplayer> 標簽的形式對外提供，如果：

• 采用 flv 播放地址

• 設置 mode 為 live 模式

• 將 mincache 和 maxcache 都設置為 1

• 推流端 gop 為 1

那么就可以實現非常理想的播放延遲，并能夠讓各觀眾之間的延遲誤差在1s以內，雖然無法做到“音話題”分毫不差（在微信打包視頻云 SDK 的時候，在線答題模式還沒有興起，所以不支持在音視頻流中夾帶消息），但也能達到幾乎可以媲美APP的體驗效果。

剩下的事情，就是通過小程序的 websocket 通道，或者我們的 webim 解決方案，向小程序發題就可以了。

接入攻略（方案一）

步驟一：開通騰訊云直播服務

聯系我們開通騰訊云 直播服務，如果您時間比較急，可以 400 客服電話我們加急審核。

步驟二：獲取推流URL

想要簡單獲取一個推流URL，可以參考文檔：快速獲得地址。想要了解推流地址和直播間ID的關系，可以參考文檔：后臺自動拼裝。想要了解如果保護自己的推流地址不被盜用，可以參考文檔：防盜鏈簽名。

步驟三：獲取播放URL

播放URL和推流URL是一一映射的，映射規則參考下面的圖示您就能明白了：

請務必使用 FLV 格式的播放地址，RTMP在高并發場景下容易出現卡頓問題。

步驟四：配置推流端

如果您是使用APP進行推流，直接參考文檔（iOS | Android）。

如果您是使用Obs推流，請注意以下幾個重要設置項：

I幀間隔（GOP）

一般演播臺的接入方式有兩種：OBS Studio 推流或者編碼盒推流，這兩種推流工具均有比較成熟的設置接口。建議將 GOP（也叫關鍵幀間隔）設置為 1s ，這樣可以讓觀眾端的延遲差異非常小。

x264 的 gop 設置對編碼效率的影響不是很大，但對延遲的影響非常大：gop越大，服務器緩存越多。由于 SDK 的延遲修正需要一個修正時間，如果 gop 太大，對于剛進入的觀眾會有很大的影響 。

如下是Obs Studio 設置關鍵幀間隔的圖示：

編碼參數

步驟五：對接播放器

1. 下載文檔第二部分中列出的 SDK 版本。

2. 參考接入文檔（iOS | Android）完成播放器的接入。兩個平臺全部完成，大概需要 0.5 天的工作量。

3. 修改默認配置由于 SDK 的默認配置為普通直播場景，所以需要修改配置，操作方法如下：

請務必使用 FLV 格式的播放地址，RTMP在高并發場景下容易出現卡頓問題。

步驟六：題目的擴散

• 如果是用APP發題，只需要參考TXLivePusher 的 sendMessage 調用方法即可，參考文檔見 （iOS | Android）。

• 如果是用我們的定制版 Obs Studio 發題，那么可以使用本地ini文件提前把題目編輯好，由導播員在合適的時間將題目擴散出去。

可靠性評估

有些客戶可能會擔心：音視頻通道本身不太穩定，那么萬一卡了或者視頻數據丟了，會不會導致觀眾端看不到題目。

• 首先，直播的音視頻數據丟幀是確定的按照gop為單位來丟幀的，如果gop=1，那么每次會丟1s的音視頻數據

• 其次，以騰訊云目前的節點部署情況來看，視頻卡頓90%以上都以由于觀眾端網速不足引起的，這種情況下其他的網絡通訊也不會很流暢。

所以，解決這個問題的辦法就是每秒鐘（gop設置為1s的前提條件下）發送一次題目消息，相同的題號在觀眾端剔重，這樣就可以避免偶爾的音視頻卡頓對題目到達可靠性的影響。

步驟七：接收題目消息

在我們的推流 APP Demo 以及定制版本的 Obs Studio 中，我們以 json 格式將題目組織成一段buffer，并將其夾在音視頻流中送出去。

獲取到這個buffer以后，您就可以將其解析出來，并完成對應的 UI 展示。如果你需要調整json格式以支持更多的定制型，請修改源碼或者聯系我們。

• TXLivePlayConfig 中的 enableMessage 開關置為 YES。

• TXLivePlayer 通過 TXLivePlayListener 監聽消息，消息編號：PLAYEVTGETMESSAGE （2012）

步驟八：開發答題系統

由于騰訊云 PAAS 的定位，所以對于跟客戶業務綁定比較緊密的答題和支付系統，我們就不涉及了，需要您來參與開發。

這里普遍采用的方案是：將客戶的答案以 HTTP(S) 請求方式匯總到答題服務器上，只是實現過程需要注意解決瞬間高并發的請求壓力。

有客戶可能會問，IM系統是否適合用來答題，這里目前看是不適合的，因為 IM 系統的主要能力在于消息擴散，而答題的主要目標是信息的收攏。

步驟九：答題結果顯示

一般題目出來一段時間以后，就會進入閉題狀態。這時，答題系統會將結果進行統計匯總，并將匯總結果下發給觀眾。

如果是用我們的定制版 Obs Studio 擴散結果，搭一個簡單的服務器，并提供一個 http 接口，然后按照我們約定的 json 格式跟 Obs 進行題目、答案以及人數的通訊。從而實現題目和答案的分發。

這部分協議由于文檔篇幅限制，暫時不放在文檔中詳細列出，有需要的話請 400 電話聯系我們。

接入攻略（方案二）

步驟一：開通騰訊云直播服務

同方案一，不再贅述。

步驟二：獲取推流URL & 加注NTP時間戳

參考方案一，與方案一不同之處在于，推流 URL 需要額外增加一個參數：

加注NTP時間戳

在推流 URL 之后添加參數 &txAddTimestamp=1 參數，服務器會每隔1s向您的直播流中打入一個帶有國際標準時間（誤差在 100ms 以內）的 SEI 時間戳。如果您使用我們的播放器播放此視頻流，那么就會每隔一秒鐘收到一次代表當前畫面 NTP 時間的消息通知。

步驟三：獲取播放URL

同方案一，不再贅述。

步驟四：配置推流端

同方案一，不再贅述。

步驟五：對接播放器

參考方案一，與方案一不同之處在于，此時獲取的message不再是一個json，而是一個8字節的64位時間戳。

long timeStamp = byteArrayToInt(param.getByteArray(TXLiveConstants.EVTGETMSG));/**
* 將8字節的byte數組轉成一個long值
*/public static long byteArrayToInt(byte[] byteArray) {
byte[] a = new byte[8];
int i = a.length  1, j = byteArray.length  1;
for (; i >= 0; i, j) {// 從b的尾部(即int值的低位)開始copy數據
if (j >= 0)
a[i] = byteArray[j];
else
a[i] = 0;// 如果b.length不足4,則將高位補0
}
// 注意此處和byte數組轉換成int的區別在于，下面的轉換中要將先將數組中的元素轉換成long型再做移位操作，
// 若直接做位移操作將得不到正確結果，因為Java默認操作數字時，若不加聲明會將數字作為int型來對待，此處必須注意。
long v0 = (long) (a[0] & 0xff) << 56;// &0xff將byte值無差異轉成int,避免Java自動類型提升后,會保留高位的符號位
long v1 = (long) (a[1] & 0xff) << 48;
long v2 = (long) (a[2] & 0xff) << 40;
long v3 = (long) (a[3] & 0xff) << 32;
long v4 = (long) (a[4] & 0xff) << 24;
long v5 = (long) (a[5] & 0xff) << 16;
long v6 = (long) (a[6] & 0xff) << 8;
long v7 = (long) (a[7] & 0xff);
return v0 + v1 + v2 + v3 + v4 + v5 + v6 + v7;}

步驟六：題目的擴散

如果您使用自己的 IM 系統下發題目，請忽略這一部分，如果想使用騰訊云 IM 服務發題，請對接如下幾步：

• 1. 開通 IM 通訊服務

  開通騰訊云 云通信 服務。

• 2. 配置 IM 通訊服務

  按照文檔進行初始化配置，集成模式請務必選擇獨立模式。

• 3. 使用 REST API 創建一個 BChatRoom 用于發題

  騰訊云 IM 的 REST API 是專門提供給服務端接入用的，創建群組這個操作一般是由您的服務器觸發，所以適合使用 REST API 方案進行接入。BChatRoom 這種房間類型非常適合用來發題，因為它原本就是用來做系統通知的，所以消息達到率高，消息可靠性好。

  創建群組使用 v4/groupopenhttpsvc/creategroup 可以實現，測試方法見 SDK 開發包中的 IM后臺RESTAPI使用方法.pdf 步驟3。

• 4. 使用 REST API 創建一個 AVChatRoom 用于彈幕

  AVChatRoom 這種房間類型非常適合用來做聊天室的彈幕消息，有比較嚴格的臟字過濾和頻率限制邏輯，專門為大型聊天室場景優化。

  創建群組使用 v4/groupopenhttpsvc/creategroup 可以實現，測試方法見 SDK 開發包中的 IM后臺RESTAPI使用方法.pdf 步驟4。AVChatroom中默認的頻率控制為/s，如果您需要調整限制請聯系我們，因為消息越多，帶寬費用越高。

• 5. 使用 REST API 在 BChatRoom 里發送題目廣播

  消息發送可以使用 v4/groupopenhttpsvc/sendgroupmsg ，測試方法見 SDK 開發包中的 IM后臺RESTAPI使用方法.pdf 步驟5。

• 6. 如何實時獲取在線人數？

  REST API 是不支持客戶端調用的，但即使是后臺調用，騰訊云 REST API 的 后臺調用頻率限制也只有 100次/秒， 所以要實時獲取在線人數，就需要先由您的業務后臺通過 REST API 低頻的獲取到在線人數，再通過消息通道，將在線人數下發到客戶端。1）由您的業務服務器通過 v4/groupopenhttpsvc/getgroupinfo 獲得群的在線人數。

2）之后，由您的業務服務器通過 v4/groupopenhttpsvc/sendgroupmsg，定時將人數通過群消息下發給客戶端。定時頻率可以設定為 35s 一次。

特別注意：REST API 不支持客戶端調用，在客戶端調用會引發私鑰泄漏，進而導致您的云服務被惡意盜用和扣費。

步驟七：題目接收&彈幕收發

客戶端使用 IM SDK 完成消息的接收和彈幕消息的收發，這里可以按照如下步驟對接

• 1. 集成精簡版 IMSDK

  精簡版 IMSDK 位于 SDK開發包 中，zip包中的 “接入指引IMSDK.pdf” 有詳細的說明。

• 2.參考源碼完成對接

  SDK開發包中有一個叫做 AnswerPlayIMCenter 的源碼文件，封裝了對于 IMSDK 的簡單調用，相當于對于接入文檔的代碼示例，您可以參考一下，如下是這個類的成員函數說明：

• 3. 題目的顯示時機

  onRecvIssueMessage 收到的題目不要立刻顯示出來，要等來自播放器的 GETMESSAGE 回調，如果回調的時間 >= 題目的 NTP 國際時間，就可以把指定的題目顯示出來了。

• 4. UserSig怎么算？

  UserSig 是 loginIMUser 時需要的一個重要信息，它的作用等同于登錄QQ用的密碼，只是這個密碼由您的服務器為您的用戶簽發；這里使用的密碼簽發方案是基于 RSA 非對稱加密實現的，所以安全性非常高。UserSig 一般是由您的服務器簽發的，簽發方案可以參考： TLS 后臺 API ，不過為了能夠能讓您快速調試起來，我們也提供了一個Windows 的簽發小工具，您可以在后臺同學加入項目之前就可以先把終端邏輯調試起來。注意：小工具里的公私鑰都只能用來測試，您可千萬別當真的用了。

步驟八：開發答題系統

由于騰訊云 PAAS 的定位，所以對于跟客戶業務綁定比較緊密的答題和支付系統，我們就不涉及了，需要您來參與開發。

這里普遍采用的方案是：將客戶的答案以 HTTP(S) 請求方式匯總到答題服務器上，只是實現過程需要注意解決瞬間高并發的請求壓力。

有客戶可能會問，IM系統是否適合用來答題，這里目前看是不適合的，因為 IM 系統的主要能力在于消息擴散，而答題的主要目標是信息的收攏。

步驟九：答題結果顯示

一般題目出來一段時間以后，就會進入閉題狀態。這時，答題系統會將結果進行統計匯總，并將匯總結果下發給觀眾，結果下發可以繼續使用 步驟六 中的題目擴散通道。