本發(fā)明涉及發(fā)送彈幕技術(shù)，更具體地，涉及一種推送彈幕的方法和系統(tǒng)。

背景技術(shù)：

彈幕是一種在觀看視頻時，以字幕形式呈現(xiàn)的評論與視頻同在一個畫面中的現(xiàn)象，在視頻中大量飄過的評論如密集的炮彈一樣，故得名彈幕。彈幕會隨著視頻的播放在視頻畫面上實時呈現(xiàn)，這樣觀看者在觀看視頻時，能夠通過彈幕看到其他觀看者和自己對當(dāng)前播放的視頻內(nèi)容的評論，每一條彈幕都有自己的生成時刻。

在視頻的播放過程中，各用戶通過終端輸入彈幕信息，并由服務(wù)器獲取，然后服務(wù)器將各用戶對該視頻發(fā)表的彈幕信息添加至視頻中進行顯示。

現(xiàn)有技術(shù)的推送彈幕方法，當(dāng)用戶打開直播網(wǎng)頁時，終端向服務(wù)器發(fā)送彈幕獲取請求，該彈幕獲取請求包括的是視頻標(biāo)識和播放時間點，服務(wù)器查詢與該視頻標(biāo)識對應(yīng)，且與播放時間點對應(yīng)的彈幕反饋給終端。這樣就存在幾個問題：

1、播放時間點對應(yīng)的彈幕數(shù)量較少，導(dǎo)致直播網(wǎng)頁上顯示的彈幕數(shù)量較少，顯得直播間十分冷清。

2、播放時間點對應(yīng)的彈幕數(shù)量較多，導(dǎo)致服務(wù)器需要推送的彈幕數(shù)量太大，加重了服務(wù)器的負(fù)擔(dān)。

對于第二個問題，現(xiàn)有技術(shù)采用了設(shè)置彈幕數(shù)量閾值的方法，簡而言之，就是假設(shè)播放時間點對應(yīng)的彈幕數(shù)量有1000個，設(shè)置彈幕數(shù)量的閾值為800個，那么服務(wù)器向終端推送800個彈幕，剩余的200的彈幕不再推送，這樣雖然減輕了服務(wù)器的負(fù)擔(dān)，但用戶并沒有觀看到那200條彈幕，既浪費了彈幕，也導(dǎo)致用戶可能錯過重要的彈幕。

技術(shù)實現(xiàn)要素：

本發(fā)明提供一種克服上述問題或者至少部分地解決上述問題的推送彈幕的方法和系統(tǒng)。

根據(jù)本發(fā)明的一個方面，提供一種推送彈幕的方法，包括：

s1、接收終端發(fā)送的彈幕獲取請求，所述彈幕獲取請求包括終端上一次顯示的最后一條彈幕的生成時刻；以及

s2、根據(jù)所述彈幕獲取請求，向終端發(fā)送所述生成時刻之后的彈幕。

優(yōu)選地，所述步驟s1之前還包括：

s0、接收所述終端在加載直播頁面后第一次發(fā)送的彈幕獲取請求，并記錄接收時刻，向所述終端發(fā)送所述接收時刻之前一段時間的彈幕。

優(yōu)選地，彈幕獲取請求還包括終端本次計劃顯示的彈幕條數(shù)；

其中，所述步驟s0中向所述終端發(fā)送所述接收時刻之前一段時間的彈幕，進一步包括：

基于所述彈幕條數(shù)和所述接收時刻，獲取第一次要發(fā)送的彈幕；以及

向終端發(fā)送所述第一次要發(fā)送的彈幕。

優(yōu)選地，所述步驟s2向終端發(fā)送所述生成時刻之后的彈幕，進一步包括：

基于所述彈幕條數(shù)和所述生成時刻，獲取本次要發(fā)送的彈幕；以及

向終端發(fā)送所述本次要發(fā)送的彈幕。

優(yōu)選地，彈幕獲取請求還包括直播頁面的標(biāo)識信息；

其中，所述步驟s0中記錄接收時刻之前還包括：

根據(jù)所述直播頁面的標(biāo)識信息，識別所述直播頁面合法且正在直播。

優(yōu)選地，基于所述彈幕條數(shù)和所述接收時刻，獲取第一次要發(fā)送的彈幕，進一步包括：

按照彈幕的生成時刻相對于所述接收時刻由遠(yuǎn)至近的順序，選取在所述接收時刻之前一段時間內(nèi)生成的、與所述彈幕條數(shù)相等條數(shù)的彈幕。

優(yōu)選地，所述基于所述彈幕條數(shù)和所述生成時刻，獲取本次要發(fā)送的彈幕，進一步包括：

按照彈幕的生成時刻相對于所述生成時刻由近至遠(yuǎn)的順序，選取在所述生成時刻之后生成的、與所述彈幕條數(shù)相等條數(shù)的彈幕。

優(yōu)選地，所述步驟s1中接收終端發(fā)送的彈幕獲取請求，進一步包括：定期接收所述終端發(fā)送的彈幕獲取請求。

根據(jù)本發(fā)明的另一個方面，還提供一種推送彈幕的系統(tǒng)，包括：

接收請求裝置，用于接收終端發(fā)送的彈幕獲取請求，所述彈幕獲取請求包括終端上一次顯示的最后一條彈幕的生成時刻；以及

發(fā)送彈幕裝置，用于根據(jù)所述彈幕獲取請求，向終端發(fā)送所述生成時刻之后的彈幕。

優(yōu)選地，所述系統(tǒng)還包括：

首次發(fā)送彈幕裝置，用于接收所述終端在加載直播頁面后第一次發(fā)送的彈幕獲取請求，并記錄接收時刻，向所述終端發(fā)送所述接收時刻之后的彈幕。

本申請?zhí)岢隽艘环N推送彈幕的方法和系統(tǒng)，根據(jù)終端發(fā)送的終端上一次最后顯示的彈幕的生成時刻，向終端發(fā)送在所述生成時刻后的彈幕，不同于現(xiàn)有技術(shù)中向終端發(fā)送播放時間點的彈幕，從而避免了在彈幕較多時用戶錯過部分彈幕的問題。

附圖說明

圖1為本發(fā)明實施例的一種推送彈幕的方法的流程圖；

圖2為本發(fā)明實施例的另一種推送彈幕的方法的流程圖；

圖3為本發(fā)明第三個實施例的推送彈幕的方法的流程圖；

圖4為本發(fā)明實施例的一種推送彈幕的系統(tǒng)的結(jié)構(gòu)框圖；

圖5為本發(fā)明實施例的另一種推送彈幕的系統(tǒng)的結(jié)構(gòu)框圖。

具體實施方式

下面結(jié)合附圖和實施例，對本發(fā)明的具體實施方式作進一步詳細(xì)描述。以下實施例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。

為了克服現(xiàn)有技術(shù)中在彈幕數(shù)量過大時，服務(wù)器處于自身負(fù)荷考慮只能將部分彈幕推送至終端，導(dǎo)致的用戶無法觀看全部彈幕的問題，本發(fā)明提供了一種推送彈幕的方法和系統(tǒng)。

圖1示出了本發(fā)明實施例的一種推送彈幕的方法流程圖，包括：

s1、接收終端發(fā)送的彈幕獲取請求，所述彈幕獲取請求包括終端上一次顯示的最后一條彈幕的生成時刻；以及

s2、根據(jù)所述彈幕獲取請求，向終端發(fā)送所述生成時刻之后的彈幕。

例如，終端上一次顯示的最后一條彈幕的生成時刻是10點10分，那么像終端發(fā)送的彈幕即為10點10分后生成的彈幕，根據(jù)終端發(fā)送的終端上一次最后顯示的彈幕的生成時刻，向終端發(fā)送在所述生成時刻后的彈幕，不同于現(xiàn)有技術(shù)中向終端發(fā)送播放時間點的彈幕，從而避免了在彈幕較多時用戶錯過部分彈幕的問題。

一般情況下，直播節(jié)目的彈幕并不會太多，因此當(dāng)用戶剛進入直播界面時，看到的彈幕也不會太多，就會給用戶帶來直播節(jié)目冷清，沒有人氣的感覺，因此，為了解決這個問題，圖2示出了本發(fā)明實施例的另一種推送彈幕的方法的流程圖，如圖可知，本方法包括：

s0、接收所述終端在加載直播頁面后第一次發(fā)送的彈幕獲取請求，并記錄接收時刻，向所述終端發(fā)送所述接收時刻之前一段時間的彈幕；

s1、接收終端發(fā)送的彈幕獲取請求，所述彈幕獲取請求包括終端上一次顯示的最后一條彈幕的生成時刻；以及

s2、根據(jù)所述彈幕獲取請求，向終端發(fā)送所述生成時刻之后的彈幕。在本實施例中，當(dāng)終端第一次發(fā)送彈幕獲取請求時，由于此時并不存在上一次顯示的彈幕，因此，根據(jù)接收到彈幕獲取請求的時間，例如接收時間為10點10分，選取接收時刻之前一段時間的彈幕，比如可以選擇10點5分至10點10分這一時間段的彈幕發(fā)送給終端，因此用戶看到的彈幕是過去一個時間段的彈幕，顯然這樣看到的彈幕數(shù)量要比實時推送的彈幕數(shù)量更多，用戶也會感覺到直播間很活躍，增強用戶的使用粘度。

在一個可選實施例中，彈幕獲取請求還包括終端本次計劃顯示的彈幕條數(shù)；

其中，所述步驟s0中向所述終端發(fā)送所述接收時刻之前一段時間的彈幕，進一步包括：基于所述彈幕條數(shù)和所述接收時刻，獲取第一次要發(fā)送的彈幕；向終端發(fā)送所述第一次要發(fā)送的彈幕。

通過綜合考慮彈幕條數(shù)和接收時刻兩個因素來獲取第一次要發(fā)送的彈幕，能夠更靈活地控制彈幕的數(shù)量，保證第一次要發(fā)送的彈幕的數(shù)量不超過服務(wù)器的負(fù)荷。

同理，在一個可選實施例中，所述步驟s2向終端發(fā)送所述生成時刻之后的彈幕，進一步包括：基于所述彈幕條數(shù)和所述生成時刻，獲取本次要發(fā)送的彈幕；向終端發(fā)送所述本次要發(fā)送的彈幕。

在一個可選實施例中，彈幕條數(shù)并不是由終端發(fā)送的，而是根據(jù)時間段內(nèi)的總彈幕數(shù)生成的，例如，服務(wù)器中10點10分至10點11分的彈幕數(shù)量共有1000條，但10點11分至10點12分的彈幕數(shù)量只有200條，終端每30秒發(fā)送一次彈幕獲取請求，也即每30秒接收一次彈幕，那么可以將推送的彈幕數(shù)量設(shè)為較低值，例如200條，使原本2分鐘就播放完的彈幕延長至3分鐘播放完，延長了彈幕的展示時間，使用戶感覺直播更加熱鬧。當(dāng)然，即使仍由終端向服務(wù)器發(fā)送彈幕數(shù)量，也可以達(dá)到上述的效果，但是由于終端并不清楚服務(wù)器存儲的不同時間的彈幕數(shù)量，只能選取經(jīng)驗值或猜測的彈幕數(shù)量，而采用服務(wù)器根據(jù)不同時間段的總彈幕數(shù)量動態(tài)調(diào)整推送的彈幕數(shù)量，顯然更利于用戶接收到活躍度更長的彈幕。

在一個事實例中，彈幕獲取請求還包括直播頁面的標(biāo)識信息；

其中，所述步驟s0中記錄接收時刻，之前還包括：

根據(jù)所述直播頁面的標(biāo)識信息，識別所述直播頁面合法且正在直播。如果識別直播頁面不合法或沒在直播，則向終端返回錯誤報告，提醒終端當(dāng)前直播頁面不合法或者沒在直播。

在一個可選實施例中，基于所述彈幕條數(shù)和所述接收時刻，獲取第一次要發(fā)送的彈幕，進一步包括：

按照彈幕的生成時刻相對于所述接收時刻由遠(yuǎn)至近的順序，選取在所述接收時刻之前一段時間內(nèi)生成的與所述彈幕條數(shù)相等條數(shù)的彈幕。

在一個可選實施例中，所述基于所述彈幕條數(shù)和所述生成時刻，獲取本次要發(fā)送的彈幕，進一步包括：

按照彈幕的生成時刻相對于所述生成時刻由近至遠(yuǎn)的順序，選取在所述生成時刻之后生成的、與所述彈幕條數(shù)相等條數(shù)的彈幕。例如，終端上一次顯示的最后一條彈幕的生成時刻是10點10分0秒，則選取在10點10分0秒之后生成的彈幕，同時按照時間上由近至遠(yuǎn)的順序選擇，依次選取10點10分1秒，10點10分2秒、…直到選取的彈幕數(shù)量滿足彈幕獲取請求中的彈幕數(shù)量。

在一個可選實施例中，如果彈幕獲取請求中的彈幕數(shù)量大于服務(wù)器中保存的可推送的彈幕數(shù)量，則按照可推送的彈幕數(shù)量進行推送，例如，彈幕獲取請求中的彈幕數(shù)量為100條，但服務(wù)器中保存的可推送的彈幕數(shù)量只有80條，那么就向終端推送80條彈幕。

在一個可選實施例中，所述步驟s1中接收終端發(fā)送的彈幕獲取請求，進一步包括：定期接收所述終端發(fā)送的彈幕獲取請求。這樣設(shè)置的好處在于不會對服務(wù)器造成突然的負(fù)荷，有利于服務(wù)器的安全。

為了更好地闡述本發(fā)明的設(shè)計思路，下面結(jié)合具體實施例進行描述，圖3示出了本發(fā)明第三個實施例的流程示意圖，如圖可知，包括：

步驟1、進入直播頁面，終端每隔5秒請求服務(wù)器的彈幕接口，請求參數(shù)包括：roomid(直播頁面的標(biāo)識信息)、count(彈幕條數(shù))以及pagecontext(終端上一次顯示的最后一條彈幕的生成時刻)；

步驟2、根據(jù)參數(shù)roomid判斷房間是否存在，防止惡意請求彈幕接口，如果不存在，則通過json的方式返回“房間不存在”給終端，若存在，則進行步驟3；

步驟3、根據(jù)參數(shù)roomid判斷房間是否開播，防止惡意請求彈幕接口，如果房間沒有播，則通過json的方式返回“房間未開播”給終端，若存在，則進行步驟4；

步驟4、判斷參數(shù)page_context是否存在，若不存在，則進行步驟5，若存在，則跳轉(zhuǎn)至步驟6；

步驟5、向終端以json的方式推送5分鐘之前的彈幕，隨后結(jié)束本次推送過程；

步驟6、查詢參數(shù)page_context攜帶的終端上一次最后顯示的彈幕的生成時刻，向終端以json方式推送生成時刻之后的彈幕，隨后結(jié)束本次推送過程。

具體地，步驟1包括：在getdanmu方法中，異步去請求服務(wù)器的彈幕接口getdanmulist，請求參數(shù)roomid(房間id)、count(一次取彈幕條數(shù))、page_context。

具體地，步驟2包括：根據(jù)參數(shù)roomid去服務(wù)器緩存數(shù)據(jù)庫中查詢房間信息，如果房間信息不存在則說明用戶請求的roomid是非法的，這樣有效的防止惡意請求彈幕接口。如果房間信息不存在，則通過json的方式返回”房間不存在”給終端。

具體地，步驟3包括：根據(jù)參數(shù)roomid去服務(wù)器緩存數(shù)據(jù)庫中查詢房間的開播狀態(tài)，如果房間是未開播的，則不需要返回給用戶彈幕列表，這樣有效的防止惡意請求彈幕接口。如果房間沒有開播，則通過json的方式返回”房間未開播”給終端。

具體地，步驟5包括：根據(jù)彈幕獲取請求的接收時間找到今天的彈幕數(shù)據(jù)庫，根據(jù)roomid去今天的彈幕數(shù)據(jù)庫中找到對應(yīng)的房間彈幕集合，最后取出大于5分鐘前的時間戳的count條彈幕數(shù)據(jù)，然后通過json方式返回彈幕數(shù)據(jù)給終端。

具體地，步驟6包括：。根據(jù)當(dāng)前時間戳找到今天的彈幕數(shù)據(jù)庫，根據(jù)roomid去今天的彈幕數(shù)據(jù)庫中找到對應(yīng)的房間彈幕集合，最后取出大于page_context之后的時間戳的count條彈幕數(shù)據(jù)，然后通過json方式返回彈幕數(shù)據(jù)給終端。

因為是html5形式的終端發(fā)出的請求，該請求消化本地資源，占用服務(wù)器資源低，避免了用websocket增加服務(wù)器資源的問題。

同時，保護針對移動端html5獲取彈幕通過js+php后端技術(shù)，開發(fā)周期短、開發(fā)效率高，如果用websocket開發(fā)開發(fā)周期很長。

圖4示出了本發(fā)明實施例提供的一種推送彈幕的系統(tǒng)的結(jié)構(gòu)框圖，包括：

接收請求裝置，用于接收終端發(fā)送的彈幕獲取請求，所述彈幕獲取請求包括終端上一次最后顯示的彈幕的生成時刻；以及

發(fā)送彈幕裝置，用于根據(jù)所述彈幕獲取請求，向終端發(fā)送所述生成時刻之后的彈幕。

圖5示出了本發(fā)明實施例的另一種推送彈幕的系統(tǒng)的結(jié)構(gòu)框圖，除了接收請求裝置和發(fā)到彈幕裝置之外，還包括：

首次發(fā)送彈幕裝置，用于接收所述終端在加載直播頁面后第一次發(fā)送的彈幕獲取請求，并記錄接收時刻，向所述終端發(fā)送所述接收時刻之后的彈幕。

在一個可選實施例中，彈幕獲取請求還包括終端本次顯示的彈幕條數(shù)；

首次發(fā)生彈幕裝置還用于：基于所述彈幕條數(shù)和所述接收時刻，獲取第一次要發(fā)送的彈幕；以及

向終端發(fā)送所述第一次要發(fā)送的彈幕。

同理，發(fā)送彈幕裝置還用于：基于所述彈幕條數(shù)和所述生成時刻，獲取本次要發(fā)送的彈幕；以及

向終端發(fā)送所述本次要發(fā)送的彈幕。

在一個可選實施例中，彈幕獲取請求還包括直播頁面的標(biāo)識信息；

首次發(fā)生彈幕裝置還用于：根據(jù)所述直播頁面的標(biāo)識信息，識別所述直播頁面合法且正在直播。

在一個可選實施例中，首次發(fā)生彈幕裝置具體用于：按照彈幕的生成時刻相對于所述接收時刻由遠(yuǎn)至近的順序，選取在所述接收時刻之前一段時間內(nèi)生成的與所述彈幕條數(shù)相等條數(shù)的彈幕。

在一個可選實施例中，發(fā)送彈幕裝置具體用于：按照彈幕的生成時刻相對于所述生成時刻由近至遠(yuǎn)的順序，選取在所述生成時刻之后生成的與所述彈幕條數(shù)相等條數(shù)的彈幕。

最后，本申請的方法僅為較佳的實施方案，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。