更多騰訊海量技術文章， 請關注雲+社區：https://cloud.tencent.com/developer
作者：騰訊視頻雲
進入2018年最火的新鮮事物無疑就是“直播答題”了， 動輒上百萬的獎金更是吸引了大量用戶的參與。 一場直播動輒
幾百萬的獎金， 每人可以分到幾十元甚至百萬元， 越來越多的人希望用自己的智商賺點零花錢。 直播答題有多火？
多個直播平臺伺服器多次遭到宕機。 實際上， 幾百萬人一同線上的確會帶給伺服器不小的壓力， 更何況是新上線的
App， 他們或許還沒有想到自己會火得這麼快。
近期很多直播答題app出現了個人帳號上顯示獎金額數不對、線上用戶無法進入遊戲、技術故障導致遊戲被迫臨時
取消等情況。 某視頻平臺還出現了系統將正確答案判定錯誤的情況， 導致百萬人被迫中止遊戲。 隔幾天就來一次的
技術故障除了說明App準備不足外， 也從側面反映了這類遊戲的火爆程度。 為了讓眾多公司及開發者儘快趕上風口浪尖， 騰訊雲直播團隊也是第一時間上線了“線上知識競技解決方案”。
效果體驗iOS平臺（ipa）：https://www.pgyer.com/liteAV
Android平臺(apk) ：http://dldir1.qq.com/hudongzhibo/xiaozhibo/LiteAVDemo_Smart_4.1.QARoom.apk
Obs Studio 定制版本（exe）：http://dldir1.qq.com/hudongzhibo/xiaozhibo/obs_distribute_question.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 的 極速播放模式 所支援的延遲修正技術，
支援微信小程式接入
騰訊雲 SDK 已經默認打包在微信版本中，
並以
方案一：題目透傳方案
原理描述
消息發送（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("UTF-8"));
消息接收：利用騰訊雲 SDK 的 TXLivePlayer 的 onPlayEvent（PLAY_EVT_GET_MESSAGE ： 2012）功能， 可以在播放機播放到指定畫面的時候， 同步地將 MESSAGE 通知給您的 APP， 從而將題目同步地擴散到海量的觀眾端。
消息接收的接入方案可以參考我們的接入文檔（iOS平臺 | Android平臺）
方案二：NTP時間同步方案
原理描述
騰訊雲會每隔 1s 在您的直播流中即時插入經過 NTP 校時的國際標準時間戳記。
演播室的導播員根據主持人的出題節奏，在合適的時間控制發題，發題系統會在每次下發的題目中帶上當時的國際標準時間。
SDK 在播放這種打入時間戳記的視頻流的時候，會定時通知您的 APP 當前 SDK 所播放的畫面是在什麼時間錄製下來的（因為導播台到雲端一般都會有一個固定的延遲，需要您提前做一個誤差校調）。
您的 APP 可以根據 SDK 的時間通知（即當前畫面是什麼時間錄製的），按需顯示指定的題目即可。
總結一下：方案二跟方案一的最大區別就在於題目的擴散方式，方案二的核心思路是讓題目先通過IM通道快速送達觀眾端APP，在觀眾端先緩存下來，等待播放機通知了預期的 NTP 時間戳記之後，再把題目顯示出來。
方案三：小程式解決方案
方案一和方案二都可以實現“音-話-題”完美同步，但是相比於這種體驗上的小優化，APP的擴散能力則是更加重要的。小程式恰恰提供給了APP可以病毒式傳播的能力。
騰訊雲 SDK 已經默認打包在微信版本中，並以
採用 flv 播放位址
設置 mode 為 live 模式
將 min-cache 和 max-cache 都設置為 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 設置關鍵幀間隔的圖示：
編碼參數
推薦推薦配置
解析度
視頻位元速率
幀率
聲道數
取樣速率
音訊位元速率
優先畫質
540x960
1000kbps
25
1
48k
72kbps
優先成本
360x640
600kbps
20
1
48k
72kbps
步驟五：對接播放機
下載文檔第二部分中列出的 SDK 版本。
參考接入文檔（iOS | Android）完成播放機的接入。兩個平臺全部完成，大概需要 0.5 天的工作量。
修改預設配置由於 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 監聽消息，消息編號：PLAY_EVT_GET_MESSAGE （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.EVT_GET_MSG));/*** 將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];elsea[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/group_open_http_svc/create_group 可以實現，測試方法見 SDK 開發包中的 IM後臺RESTAPI使用方法.pdf - 步驟3。
4. 使用 REST API 創建一個 AVChatRoom 用於彈幕
AVChatRoom 這種房間類型非常適合用來做聊天室的彈幕消息，有比較嚴格的髒字過濾和頻率限制邏輯，專門為大型聊天室場景優化。
創建群組使用 v4/group_open_http_svc/create_group 可以實現，測試方法見 SDK 開發包中的 IM後臺RESTAPI使用方法.pdf - 步驟4。AVChatroom中預設的頻率控制為40條/s，如果您需要調整限制請聯繫我們，因為消息越多，頻寬費用越高。
5. 使用 REST API 在 BChatRoom 裡發送題目廣播
消息發送可以使用 v4/group_open_http_svc/send_group_msg ，測試方法見 SDK 開發包中的 IM後臺RESTAPI使用方法.pdf - 步驟5。
6. 如何即時獲取線上人數？
REST API 是不支援用戶端調用的，但即使是後臺調用，騰訊雲 REST API 的 後臺調用頻率限制也只有 100次/秒， 所以要即時獲取線上人數，就需要先由您的業務後臺通過 REST API 低頻的獲取到線上人數，再通過消息通道，將線上人數下發到用戶端。1）由您的業務伺服器通過 v4/group_open_http_svc/get_group_info 獲得群的線上人數。
2）之後，由您的業務伺服器通過 v4/group_open_http_svc/send_group_msg，定時將人數通過群消息下發給用戶端。定時頻率可以設定為 3-5s 一次。
特別注意：REST API 不支援用戶端調用，在用戶端調用會引發私密金鑰洩漏，進而導致您的雲服務被惡意盜用和扣費。
步驟七：題目接收&彈幕收發
用戶端使用 IM SDK 完成消息的接收和彈幕消息的收發，這裡可以按照如下步驟對接
1. 集成精簡版 IMSDK
精簡版 IMSDK 位於 SDK開發包 中，zip包中的 “接入指引-IMSDK.pdf” 有詳細的說明。
2.參考源碼完成對接
SDK開發包中有一個叫做 AnswerPlayIMCenter 的源碼檔，封裝了對於 IMSDK 的簡單調用，相當於對於接入文檔的代碼示例，您可以參考一下，如下是這個類的成員函數說明：
成員函數
作用
initIMCenter
用於初始化，需要填寫您在騰訊雲的 IM 服務相關資訊。
loginIMUser
用於登錄，您可以把 imSDK 當成一個無介面的 QQ，用QQ收發消息肯定要登錄，只是將QQ號和登錄密碼換成了您的Userid和您的伺服器簽發的UserSig。
joinIMGroup
用於加入在步驟六中由您的後臺伺服器通過 REST API 創建的 BChatRoom 和 AVChatRoom。
sendChatMessage
用來發送彈幕評論消息
onRecvChatMessage
用於接收來自 AVChatRoom 的彈幕消息，注意做一下渲染的頻率限制，不要收到一條彈幕消息就刷一次螢幕，手機性能可能扛不住，很多客戶都是在這裡疏忽了，因為測試期間消息不多不易發現。
onRecvIssueMessage
用於接收來自 BChatRoom 的題目消息，按照方案二的設計，每道題目裡面都有它應該顯示的 NTP 國際時間。
3. 題目的顯示時機
onRecvIssueMessage 收到的題目不要立刻顯示出來，要等來自播放機的 GET_MESSAGE 回檔，如果回檔的時間 >= 題目的 NTP 國際時間，就可以把指定的題目顯示出來了。
4. UserSig怎麼算？
UserSig 是 loginIMUser 時需要的一個重要資訊，它的作用等同於登錄QQ用的密碼，只是這個密碼由您的伺服器為您的用戶簽發；這裡使用的密碼簽發方案是基於 RSA 非對稱加密實現的，所以安全性非常高。UserSig 一般是由您的伺服器簽發的，簽發方案可以參考： TLS 後臺 API ，不過為了能夠能讓您快速調試起來，我們也提供了一個Windows 的簽發小工具，您可以在後臺同學加入項目之前就可以先把終端邏輯調試起來。注意：小工具裡的公私密金鑰都只能用來測試，您可千萬別當真的用了。
步驟八：開發答題系統
由於騰訊雲 PAAS 的定位，所以對於跟客戶業務綁定比較緊密的答題和支付系統，我們就不涉及了，需要您來參與開發。
這裡普遍採用的方案是：將客 戶的答案以 HTTP(S) 請求方式匯總到答題伺服器上，只是實現過程需要注意解決瞬間高併發的請求壓力。
有客戶可能會問，IM系統是否適合用來答題，這裡目前看是不適合的，因為 IM 系統的主要能力在於消息擴散，而答題的主要目標是資訊的收攏。
步驟九：答題結果顯示
一般題目出來一段時間以後，就會進入閉題狀態。這時，答題系統會將結果進行統計匯總，並將匯總結果下發給觀眾，結果下發可以繼續使用 步驟六 中的題目擴散通道。
原理描述
騰訊雲會每隔 1s 在您的直播流中即時插入經過 NTP 校時的國際標準時間戳記。
演播室的導播員根據主持人的出題節奏，在合適的時間控制發題，發題系統會在每次下發的題目中帶上當時的國際標準時間。
SDK 在播放這種打入時間戳記的視頻流的時候，會定時通知您的 APP 當前 SDK 所播放的畫面是在什麼時間錄製下來的（因為導播台到雲端一般都會有一個固定的延遲，需要您提前做一個誤差校調）。
您的 APP 可以根據 SDK 的時間通知（即當前畫面是什麼時間錄製的），按需顯示指定的題目即可。
總結一下：方案二跟方案一的最大區別就在於題目的擴散方式，方案二的核心思路是讓題目先通過IM通道快速送達觀眾端APP，在觀眾端先緩存下來，等待播放機通知了預期的 NTP 時間戳記之後，再把題目顯示出來。
方案三：小程式解決方案
方案一和方案二都可以實現“音-話-題”完美同步，但是相比於這種體驗上的小優化，APP的擴散能力則是更加重要的。小程式恰恰提供給了APP可以病毒式傳播的能力。
騰訊雲 SDK 已經默認打包在微信版本中，並以
採用 flv 播放位址
設置 mode 為 live 模式
將 min-cache 和 max-cache 都設置為 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 設置關鍵幀間隔的圖示：
編碼參數
推薦推薦配置
解析度
視頻位元速率
幀率
聲道數
取樣速率
音訊位元速率
優先畫質
540x960
1000kbps
25
1
48k
72kbps
優先成本
360x640
600kbps
20
1
48k
72kbps
步驟五：對接播放機
下載文檔第二部分中列出的 SDK 版本。
參考接入文檔（iOS | Android）完成播放機的接入。兩個平臺全部完成，大概需要 0.5 天的工作量。
修改預設配置由於 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 監聽消息，消息編號：PLAY_EVT_GET_MESSAGE （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.EVT_GET_MSG));/*** 將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];elsea[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/group_open_http_svc/create_group 可以實現，測試方法見 SDK 開發包中的 IM後臺RESTAPI使用方法.pdf - 步驟3。
4. 使用 REST API 創建一個 AVChatRoom 用於彈幕
AVChatRoom 這種房間類型非常適合用來做聊天室的彈幕消息，有比較嚴格的髒字過濾和頻率限制邏輯，專門為大型聊天室場景優化。
創建群組使用 v4/group_open_http_svc/create_group 可以實現，測試方法見 SDK 開發包中的 IM後臺RESTAPI使用方法.pdf - 步驟4。AVChatroom中預設的頻率控制為40條/s，如果您需要調整限制請聯繫我們，因為消息越多，頻寬費用越高。
5. 使用 REST API 在 BChatRoom 裡發送題目廣播
消息發送可以使用 v4/group_open_http_svc/send_group_msg ，測試方法見 SDK 開發包中的 IM後臺RESTAPI使用方法.pdf - 步驟5。
6. 如何即時獲取線上人數？
REST API 是不支援用戶端調用的，但即使是後臺調用，騰訊雲 REST API 的 後臺調用頻率限制也只有 100次/秒， 所以要即時獲取線上人數，就需要先由您的業務後臺通過 REST API 低頻的獲取到線上人數，再通過消息通道，將線上人數下發到用戶端。1）由您的業務伺服器通過 v4/group_open_http_svc/get_group_info 獲得群的線上人數。
2）之後，由您的業務伺服器通過 v4/group_open_http_svc/send_group_msg，定時將人數通過群消息下發給用戶端。定時頻率可以設定為 3-5s 一次。
特別注意：REST API 不支援用戶端調用，在用戶端調用會引發私密金鑰洩漏，進而導致您的雲服務被惡意盜用和扣費。
步驟七：題目接收&彈幕收發
用戶端使用 IM SDK 完成消息的接收和彈幕消息的收發，這裡可以按照如下步驟對接
1. 集成精簡版 IMSDK
精簡版 IMSDK 位於 SDK開發包 中，zip包中的 “接入指引-IMSDK.pdf” 有詳細的說明。
2.參考源碼完成對接
SDK開發包中有一個叫做 AnswerPlayIMCenter 的源碼檔，封裝了對於 IMSDK 的簡單調用，相當於對於接入文檔的代碼示例，您可以參考一下，如下是這個類的成員函數說明：
成員函數
作用
initIMCenter
用於初始化，需要填寫您在騰訊雲的 IM 服務相關資訊。
loginIMUser
用於登錄，您可以把 imSDK 當成一個無介面的 QQ，用QQ收發消息肯定要登錄，只是將QQ號和登錄密碼換成了您的Userid和您的伺服器簽發的UserSig。
joinIMGroup
用於加入在步驟六中由您的後臺伺服器通過 REST API 創建的 BChatRoom 和 AVChatRoom。
sendChatMessage
用來發送彈幕評論消息
onRecvChatMessage
用於接收來自 AVChatRoom 的彈幕消息，注意做一下渲染的頻率限制，不要收到一條彈幕消息就刷一次螢幕，手機性能可能扛不住，很多客戶都是在這裡疏忽了，因為測試期間消息不多不易發現。
onRecvIssueMessage
用於接收來自 BChatRoom 的題目消息，按照方案二的設計，每道題目裡面都有它應該顯示的 NTP 國際時間。
3. 題目的顯示時機
onRecvIssueMessage 收到的題目不要立刻顯示出來，要等來自播放機的 GET_MESSAGE 回檔，如果回檔的時間 >= 題目的 NTP 國際時間，就可以把指定的題目顯示出來了。
4. UserSig怎麼算？
UserSig 是 loginIMUser 時需要的一個重要資訊，它的作用等同於登錄QQ用的密碼，只是這個密碼由您的伺服器為您的用戶簽發；這裡使用的密碼簽發方案是基於 RSA 非對稱加密實現的，所以安全性非常高。UserSig 一般是由您的伺服器簽發的，簽發方案可以參考： TLS 後臺 API ，不過為了能夠能讓您快速調試起來，我們也提供了一個Windows 的簽發小工具，您可以在後臺同學加入項目之前就可以先把終端邏輯調試起來。注意：小工具裡的公私密金鑰都只能用來測試，您可千萬別當真的用了。
步驟八：開發答題系統
由於騰訊雲 PAAS 的定位，所以對於跟客戶業務綁定比較緊密的答題和支付系統，我們就不涉及了，需要您來參與開發。
這裡普遍採用的方案是：將客 戶的答案以 HTTP(S) 請求方式匯總到答題伺服器上，只是實現過程需要注意解決瞬間高併發的請求壓力。
有客戶可能會問，IM系統是否適合用來答題，這裡目前看是不適合的，因為 IM 系統的主要能力在於消息擴散，而答題的主要目標是資訊的收攏。
步驟九：答題結果顯示
一般題目出來一段時間以後，就會進入閉題狀態。這時，答題系統會將結果進行統計匯總，並將匯總結果下發給觀眾，結果下發可以繼續使用 步驟六 中的題目擴散通道。