本發(fā)明屬于流媒體推流和收流領(lǐng)域，尤其涉及一種推流方法及裝置。

背景技術(shù)：

目前，流媒體廣泛的應(yīng)用在數(shù)字電視技術(shù)和網(wǎng)絡(luò)技術(shù)中。以網(wǎng)絡(luò)直播為例，直播用戶開啟直播后，直接將直播數(shù)據(jù)推流到與直播地址對應(yīng)的服務(wù)器上，使得觀看直播的用戶想要觀看此直播時，只需要找到此直播，點擊播放，即可立即從服務(wù)器獲取直播內(nèi)容并觀看直播，其中，直播內(nèi)容一邊播放一邊下載，而不需要將直播內(nèi)容全部從服務(wù)器下載完成后，才能點擊播放以觀看直播。極大地提高了用戶的體驗。

但是，現(xiàn)有技術(shù)中只要直播用戶開啟直播后，即使沒有用戶觀看直播，也將直播數(shù)據(jù)推流到服務(wù)器中，占用了網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)資源的浪費。

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

有鑒于此，本發(fā)明的目的在于提供一種推流方法及裝置，用于節(jié)省網(wǎng)絡(luò)帶寬，避免造成網(wǎng)絡(luò)資源浪費的問題產(chǎn)生。

技術(shù)方案如下：

本發(fā)明提供一種推流方法，包括：

接收到服務(wù)器發(fā)送的開始請求后，向輸入源發(fā)送推流請求；

接收所述輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)；

將所述數(shù)據(jù)推流到所述服務(wù)器。

優(yōu)選地，所述接收所述輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)，包括：

接收到所述輸入源發(fā)送的收流通知后，接收所述輸入源推流的數(shù)據(jù)；其中，所述收流通知在所述輸入源接收到所述推流請求并獲取數(shù)據(jù)后發(fā)送。

優(yōu)選地，所述將所述數(shù)據(jù)推流到所述服務(wù)器之后，還包括：

接收所述服務(wù)器發(fā)送的停止請求；

向所述輸入源發(fā)送停止推流請求；

停止收流。

優(yōu)選地，所述向所述輸入源發(fā)送停止推流請求之后，還包括：

接收所述輸入源響應(yīng)所述停止推流請求后返回的狀態(tài)信息；

判斷所述狀態(tài)信息是否為成功響應(yīng)所述停止推流請求；

若所述狀態(tài)信息為沒有成功響應(yīng)所述停止推流請求，則返回執(zhí)行向所述輸入源發(fā)送停止推流請求。

優(yōu)選地，所述接收到所述服務(wù)器發(fā)送的開始請求后之前，還包括：

根據(jù)推流地址，判斷是否等待所述服務(wù)器發(fā)送的開始請求；

若等待所述服務(wù)器發(fā)送的開始請求，則接收到所述服務(wù)器發(fā)送的開始請求后，向所述輸入源發(fā)送推流請求。

本發(fā)明還提供一種推流裝置，包括：

第一發(fā)送單元，用于接收到服務(wù)器發(fā)送的開始請求后，向輸入源發(fā)送推流請求；

第一接收單元，用于接收所述輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)；

推流單元，用于將所述數(shù)據(jù)推流到所述服務(wù)器。

優(yōu)選地，所述第一接收單元包括：

數(shù)據(jù)接收單元，用于接收到所述輸入源發(fā)送的收流通知后，接收所述輸入源推流的數(shù)據(jù)；其中，所述收流通知在所述輸入源接收到所述推流請求并獲取數(shù)據(jù)后發(fā)送。

優(yōu)選地，所述推流裝置還包括：

第二接收單元，用于接收所述服務(wù)器發(fā)送的停止請求；

第二發(fā)送單元，用于向所述輸入源發(fā)送停止推流請求；

停止收流單元，用于停止收流。

優(yōu)選地，所述推流裝置還包括：

第三接收單元，用于接收所述輸入源響應(yīng)所述停止推流請求后返回的狀態(tài)信息；

第一判斷單元，用于判斷所述狀態(tài)信息是否為成功響應(yīng)所述停止推流請求；

若所述狀態(tài)信息為沒有成功響應(yīng)所述停止推流請求，則調(diào)用所述第二發(fā)送單元。

優(yōu)選地，所述推流裝置還包括：

第二判斷單元，用于根據(jù)推流地址，判斷是否等待所述服務(wù)器發(fā)送的開始請求；

若等待所述服務(wù)器發(fā)送的開始請求，則調(diào)用所述第一發(fā)送單元。

與現(xiàn)有技術(shù)相比，本發(fā)明提供的上述技術(shù)方案具有如下優(yōu)點：

從上述技術(shù)方案可知，本申請?zhí)峁┮环N推流方法及裝置，只有在接收到服務(wù)器發(fā)送的開始請求后，才向輸入源發(fā)送推流請求，接收輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)，并將所述數(shù)據(jù)推流到所述服務(wù)器。而在沒接收到服務(wù)器發(fā)送的開始請求時，即沒有用戶需要從服務(wù)器獲取數(shù)據(jù)時，不會通過輸入源獲取數(shù)據(jù)，并且不會將數(shù)據(jù)推流到服務(wù)器中，進而避免了占用網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)資源浪費的問題產(chǎn)生。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本發(fā)明實施例提供的一種推流方法的流程圖；

圖2是本發(fā)明實施例提供的另一種推流方法的流程圖；

圖3是本發(fā)明實施例提供的一種推流裝置的結(jié)構(gòu)示意圖；

圖4是本發(fā)明實施例提供的另一種推流裝置的結(jié)構(gòu)示意圖。

具體實施方式

為使本發(fā)明實施例的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

本發(fā)明公開了一種推流方法，所述推流方法可以應(yīng)用在流媒體設(shè)備中，參見圖1，該實施例包括以下步驟：

s101、接收到服務(wù)器發(fā)送的開始請求后，向輸入源發(fā)送推流請求；

以網(wǎng)絡(luò)直播為例進行說明，為了實現(xiàn)直播，需要在輸入源內(nèi)設(shè)置直播輸出地址，所述直播輸出地址用于將輸入源獲取到的直播數(shù)據(jù)通過推流端推流到服務(wù)器中，且需要在服務(wù)器內(nèi)設(shè)置與直播對應(yīng)的直播頻道和輸入地址。其中，直播頻道生成后，建立一個直播地址，此直播地址具體可以是一個網(wǎng)址。

通過在輸入源內(nèi)設(shè)置的輸出地址和在服務(wù)器內(nèi)設(shè)置的輸入地址，實現(xiàn)了將輸入源獲取到的直播數(shù)據(jù)傳輸?shù)椒?wù)器的目的。其中，輸入地址和輸出地址可以是相同的地址，也可以是不同的地址但具有唯一對應(yīng)關(guān)系。

在實際應(yīng)用中，由于觀看直播的用戶不同，因此輸入源獲取到的直播數(shù)據(jù)需要能夠支持多個不同用戶的獲取，即需要將一個數(shù)據(jù)能夠發(fā)送至多個不同的目的地址?；诖?，本實施例中可以基于udp協(xié)議的組播通信方式。

udp組播中，組播報文的目的地址使用d類ip地址，d類ip地址不能出現(xiàn)在ip報文的源ip地址字段。單播數(shù)據(jù)傳輸過程中，一個數(shù)據(jù)包傳輸?shù)穆窂绞菑脑吹刂仿酚傻侥康牡刂?，利用“逐跳”的原理在ip網(wǎng)絡(luò)中傳輸。

然而在ip組播環(huán)中，數(shù)據(jù)包的目的地址不是一個，而是一組，形成組地址。所有的信息接收者都加入到一個組內(nèi)，并且一旦加入之后，流向組地址的數(shù)據(jù)立即開始向接收者傳輸，組中的所有成員都能接收到數(shù)據(jù)包。組播組中的成員是動態(tài)的，成員主機可以在任何時刻加入和離開組播組。

用同一個ip多播地址接收多播數(shù)據(jù)包的所有主機構(gòu)成了一個主機組，也稱為多播組。一個多播組的成員是隨時變動的，一臺主機可以隨時加入或離開多播組，多播組成員的數(shù)目和所在的地理位置也不受限制，一臺主機也可以屬于幾個多播組。此外，不屬于某一個多播組的主機也可以向該多播組發(fā)送數(shù)據(jù)包。

基于udp協(xié)議的組播通信方式，可以實現(xiàn)將直播用戶生成的數(shù)據(jù)包，發(fā)送至多個不同的想要觀看直播的用戶。且觀看直播的用戶可以隨時加入或者離開。

在輸入源內(nèi)設(shè)置的直播輸出地址和在服務(wù)器內(nèi)設(shè)置的輸入地址，都可以是udp地址。

可以理解的是，本實施中還可以基于其他的協(xié)議，當協(xié)議不同的時，輸入地址和輸出地址根據(jù)協(xié)議進行對應(yīng)的修改。

觀看直播的用戶，在自身的客戶端通過瀏覽器可以選擇需要觀看的直播頻道，此直播頻道與服務(wù)器內(nèi)設(shè)置的直播頻道是相同的。當用戶點擊想要觀看的直播頻道后，向服務(wù)器發(fā)送開始請求。其中，開始請求中攜帶直播頻道標識。

服務(wù)器接收到開始請求后，解析此開始請求，獲取與此開始請求對應(yīng)的直播頻道標識，并查找到與此直播頻道對應(yīng)的輸入地址。通過此輸入地址，服務(wù)器將開始請求發(fā)送至與輸入地址對應(yīng)的推流端，推流端接收到服務(wù)器發(fā)送的開始請求后，向與輸入地址對應(yīng)的輸出地址所在的輸入源發(fā)送推流請求。

s102、接收所述輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)；

輸入源在接收到推流端發(fā)送的推流請求后，獲取直播數(shù)據(jù)。

獲取到直播數(shù)據(jù)后，通過輸出地址輸出直播數(shù)據(jù)；

推流端接收從所述輸出地址輸出的直播數(shù)據(jù)。

可選地，在一個實施方式中，本步驟包括：

接收到所述輸入源發(fā)送的收流通知后，接收所述輸入源推流的數(shù)據(jù)；其中，所述收流通知在所述輸入源接收到所述推流請求并獲取數(shù)據(jù)后發(fā)送。

收流通知是輸入源在接收到推流請求并已經(jīng)獲取到直播數(shù)據(jù)后，發(fā)送給推流端，用于告知推流端從輸入源收流。

s103、將所述數(shù)據(jù)推流到所述服務(wù)器。

其中，推流端在接收到輸入源推流的數(shù)據(jù)后，將數(shù)據(jù)推流到服務(wù)器中。

推流端將接收到的數(shù)據(jù)，推流到與直播頻道對應(yīng)的服務(wù)器中。以使得觀看直播的用戶，點擊直播頻道后可以從與直播頻道對應(yīng)的服務(wù)器中獲取相應(yīng)的數(shù)據(jù)。

從上述技術(shù)方案可知，本實施例公開的推流方法，并不需要對現(xiàn)有的流媒體設(shè)備進行任何硬件上的改進，而僅僅是在現(xiàn)有的流媒體設(shè)備的基礎(chǔ)上進行軟件上的改進，即可實現(xiàn)只有在接收到服務(wù)器發(fā)送的開始請求后，才向輸入源發(fā)送推流請求，接收輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)，并將所述數(shù)據(jù)推流到所述服務(wù)器。而在沒接收到服務(wù)器發(fā)送的開始請求時，即沒有用戶需要從服務(wù)器獲取數(shù)據(jù)時，不會通過輸入源獲取數(shù)據(jù)，并且不會將數(shù)據(jù)推流到服務(wù)器中，進而避免了占用網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)資源浪費的問題產(chǎn)生。

本發(fā)明公開了另一種推流方法，參見圖2，該實施例包括以下步驟：

s201、根據(jù)推流地址，判斷是否等待服務(wù)器發(fā)送的開始請求；

若等待服務(wù)器發(fā)送的開始請求，則執(zhí)行s202；

若不等待服務(wù)器發(fā)送的開始請求，則當直播用戶開始直播后，推流端直接將從輸入源獲取到的直播數(shù)據(jù)，推流到服務(wù)器。

以網(wǎng)絡(luò)直播為例進行說明，在服務(wù)器內(nèi)設(shè)置直播頻道和與直播頻道對應(yīng)的輸入地址，輸入地址即推流地址。

針對不同的直播頻道，可以分別設(shè)置不同的播放屬性，例如可以設(shè)置為支持點播屬性和不支持點播屬性。若設(shè)置為支持點播屬性，需要滿足用戶在點播時能夠播放完整內(nèi)容，因此服務(wù)器內(nèi)應(yīng)該存儲有完整的點播內(nèi)容，進而當直播用戶開始直播后，就需要將輸入源獲取到的直播數(shù)據(jù)，通過推流端推流到服務(wù)器。

具體的，根據(jù)推流地址，判斷與此推流地址對應(yīng)的直播頻道設(shè)置的播放屬性，進而實現(xiàn)判斷是否等待服務(wù)器發(fā)送的開始請求。

若播放屬性為支持點播，則不等待服務(wù)器發(fā)送的開始請求；在直播用戶啟動直播后，則直接將直播數(shù)據(jù)推流到與直播地址對應(yīng)的服務(wù)器上，確保存儲直播的完整內(nèi)容，進而用戶隨時點播此內(nèi)容時，都可以觀看完整的內(nèi)容。若播放屬性為不支持點播，則等待服務(wù)器發(fā)送的開始請求。

s202、接收到服務(wù)器發(fā)送的開始請求后，向輸入源發(fā)送推流請求；

s203、接收所述輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)；

s204、將所述數(shù)據(jù)推流到所述服務(wù)器；

本實施例中步驟s202-s204的具體實現(xiàn)與圖1所述的實施例中步驟s101-s103相似，此處不在贅述。

s205、接收所述服務(wù)器發(fā)送的停止請求；

推流端接收服務(wù)器發(fā)送的請求可以包括開始請求和停止請求。并且，請求是在用戶在客戶端通過瀏覽器進行相應(yīng)的操作后產(chǎn)生的。

推流端在接收到不同的請求后，執(zhí)行不同的動作。本實施例中并不限定接收服務(wù)器發(fā)送的請求的順序，也就是說，本實施例中步驟s205并不一定是在執(zhí)行完接收服務(wù)器發(fā)送的開始請求之后執(zhí)行，即不一定是在步驟s204后再執(zhí)行步驟s205。

s206、向所述輸入源發(fā)送停止推流請求；

當觀看直播的用戶需要離開客戶端，點擊暫停播放直播的按鈕后，或關(guān)閉顯示直播的界面后，向服務(wù)器發(fā)送停止請求。

停止請求中可以攜帶直播頻道標識，當服務(wù)器接收到停止請求后，解析此停止請求，獲取與此停止請求對應(yīng)的直播頻道標識，并查找到與此直播頻道對應(yīng)的輸入地址。

通過此輸入地址，將停止請求發(fā)送至與輸入地址對應(yīng)的推流端，推流端接收到服務(wù)器發(fā)送的停止請求后，向與輸入地址對應(yīng)的輸出地址所在的輸入源發(fā)送停止推流請求。

s207、接收所述輸入源響應(yīng)所述停止推流請求后返回的狀態(tài)信息；

輸入源接收到推流端發(fā)送的停止推流請求后，停止向輸出地址輸出數(shù)據(jù)。為了避免輸入源不能正常響應(yīng)推流端發(fā)送的停止推流請求，導(dǎo)致輸入源接收到停止推流請求后，仍然向輸出地址輸出數(shù)據(jù)，造成資源浪費。輸入源在響應(yīng)停止推流請求后，向推流端返回狀態(tài)信息。

s208、判斷所述狀態(tài)信息是否為成功響應(yīng)所述停止推流請求；

若所述狀態(tài)信息為沒有成功響應(yīng)所述停止推流請求，則返回執(zhí)行s206；

若所述狀態(tài)信息為成功響應(yīng)所述停止推流請求，則執(zhí)行s209；

狀態(tài)信息用于標識輸入源是否成功響應(yīng)停止推流請求，執(zhí)行了停止推流這一動作，則返回的狀態(tài)信息是成功響應(yīng)所述停止推流請求，沒有執(zhí)行停止推流這一動作，則返回的狀態(tài)信息是沒有成功響應(yīng)所述停止推流請求。

當狀態(tài)信息為沒有成功響應(yīng)所述停止推流請求，即沒有停止推流，則再次返回執(zhí)行向輸入源發(fā)送停止推流請求步驟及其后續(xù)步驟。

在具體實施時，針對服務(wù)器發(fā)送的同一個停止請求，推流端重復(fù)向輸入源發(fā)送一定次數(shù)的停止推流請求后，判斷所述狀態(tài)信息仍然是不成功，則不再向輸入源發(fā)送停止推流請求，直接停止收流。避免出現(xiàn)推流端一直向輸入源發(fā)送停止推流請求的情況發(fā)生。

s209、停止收流。

本實施例中推流端在接收到輸入源返回的狀態(tài)信息為成功響應(yīng)所述停止推流請求后，才停止收流。但是，在實際應(yīng)用中，可以在接收到服務(wù)器發(fā)送的停止請求后，就停止收流。然后再執(zhí)行向輸入源發(fā)送停止推流請求及其后續(xù)步驟。

本實施例中并不限定執(zhí)行向輸入源發(fā)送停止推流請求和執(zhí)行停止收流的先后順序。

從上述技術(shù)方案可知，本實施例公開的推流方法中，建立推流地址后，根據(jù)所述推流地址，判斷是否等待服務(wù)器發(fā)送的開始請求，若等待服務(wù)器發(fā)送的開始請求，則在接收到服務(wù)器發(fā)送的開始請求后，才向輸入源發(fā)送推流請求，接收輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)，并將所述數(shù)據(jù)推流到所述服務(wù)器。而在沒接收到服務(wù)器發(fā)送的開始請求時，即沒有用戶需要從服務(wù)器獲取數(shù)據(jù)時，不會通過輸入源獲取數(shù)據(jù)，并且不會將數(shù)據(jù)推流到服務(wù)器中，實現(xiàn)了按需推流的目的，進而避免了占用網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)資源浪費的問題產(chǎn)生。若不等待服務(wù)器發(fā)送的開始請求，則直接將直播數(shù)據(jù)推流到與直播地址對應(yīng)的服務(wù)器上。本實施例中在可以實現(xiàn)按需推流的基礎(chǔ)上，還可以實現(xiàn)根據(jù)用戶需求選擇是否按需推流的目的，滿足了用戶的需求。

對應(yīng)上述推流方法，本發(fā)明還提供了一種推流裝置，所述推流裝置應(yīng)用在所述推流端，所述推流裝置的結(jié)構(gòu)示意圖請參閱圖3所示，本實施例中推流裝置包括：

第一發(fā)送單元301、第一接收單元302和推流單元303；

第一發(fā)送單元301，用于接收到服務(wù)器發(fā)送的開始請求后，向輸入源發(fā)送推流請求；

可選地，第一發(fā)送單元301包括數(shù)據(jù)接收單元，用于接收到輸入源發(fā)送的收流通知后，接收所述輸入源推流的數(shù)據(jù)，其中，所述收流通知在所述輸入源接收到所述推流請求并獲取數(shù)據(jù)后發(fā)送。

第一接收單元302，用于接收輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)；

推流單元303，用于將所述數(shù)據(jù)推流到所述服務(wù)器。

從上述技術(shù)方案可知，本實施例中公開的推流裝置，第一發(fā)送單元只有在接收到服務(wù)器發(fā)送的開始請求后，才向輸入源發(fā)送推流請求，第一接收單元接收輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)，推流單元將所述數(shù)據(jù)推流到所述服務(wù)器。而在沒接收到服務(wù)器發(fā)送的開始請求時，即沒有用戶需要從服務(wù)器獲取數(shù)據(jù)時，不會通過輸入源獲取數(shù)據(jù)，并且不會將數(shù)據(jù)推流到服務(wù)器中，進而避免了占用網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)資源浪費的問題產(chǎn)生。

本發(fā)明實施例還提供了另一種推流裝置，其結(jié)構(gòu)示意圖請參閱圖4所示，本實施例中推流裝置包括：

第一發(fā)送單元401、第一接收單元402、推流單元403、第二接收單元404、第二發(fā)送單元405、停止收流單元406、第三接收單元407、第一判斷單元408和第二判斷單元409；

其中，第一發(fā)送單元401、第一接收單元402和推流單元403與圖3所示的推流裝置中的第一發(fā)送單元301、第一接收單元302和推流單元303結(jié)構(gòu)相同，此處不再贅述。

本實施例中的推流裝置，相較于圖3所示的推流裝置，區(qū)別在于本實施例中推流裝置還包括：

第二接收單元404、第二發(fā)送單元405、停止收流單元406、第三接收單元407、第一判斷單元408和第二判斷單元409；

第二接收單元404，用于接收服務(wù)器發(fā)送的停止請求；

第二發(fā)送單元405，用于向輸入源發(fā)送停止推流請求；

當觀看直播的用戶需要離開客戶端，點擊暫停播放直播的按鈕后，或關(guān)閉顯示直播的界面后，都會向服務(wù)器發(fā)送停止請求。

停止請求中可以攜帶直播頻道標識，當服務(wù)器接收到停止請求后，解析此停止請求，獲取與此停止請求對應(yīng)的直播頻道標識，并查找到與此直播頻道對應(yīng)的輸入地址。

通過此輸入地址，將停止請求發(fā)送至與輸入地址對應(yīng)的推流端，推流端接收到服務(wù)器發(fā)送的停止請求后，向與輸入地址對應(yīng)的輸出地址所在的輸入源發(fā)送停止推流請求。

停止收流單元406，用于停止收流。

第三接收單元407，用于接收所述輸入源響應(yīng)所述停止推流請求后返回的狀態(tài)信息；

第一判斷單元408，用于判斷所述狀態(tài)信息是否為成功；

若所述狀態(tài)信息為不成功，則調(diào)用第二發(fā)送單元405。

通過判斷所述狀態(tài)信息是否為成功，可以避免輸入源在接收到停止推流請求后，不能正常停止推流的問題產(chǎn)生。

第二判斷單元409，用于根據(jù)推流地址，判斷是否等待服務(wù)器發(fā)送的開始請求；

針對不同的直播頻道，可以分別設(shè)置不同的播放屬性，例如可以設(shè)置為支持點播屬性和不支持點播屬性。

設(shè)置為支持點播屬性后，需要滿足用戶在點播時能夠播放完整內(nèi)容，因此服務(wù)器內(nèi)應(yīng)該存儲有完整的點播內(nèi)容。進而當直播用戶開始直播后，就需要將輸入源獲取到的直播數(shù)據(jù)，通過推流端推流到服務(wù)器。

建立推流地址后，第二判斷單元409根據(jù)推流地址，判斷與此推流地址對應(yīng)的直播頻道設(shè)置的播放屬性，進而實現(xiàn)判斷是否等待服務(wù)器發(fā)送的開始請求。

若播放屬性為支持點播，則不等待服務(wù)器發(fā)送的開始請求；

在直播用戶啟動直播后，則直接將直播數(shù)據(jù)推流到與直播地址對應(yīng)的服務(wù)器上，確保存儲直播的完整內(nèi)容。進而用戶隨時點播此內(nèi)容時，都可以觀看完整的內(nèi)容。若播放屬性為不支持點播，則等待服務(wù)器發(fā)送的開始請求。

若等待服務(wù)器發(fā)送的開始請求，則調(diào)用第一發(fā)送單元401。

若等待服務(wù)器發(fā)送的開始請求，則調(diào)用第一發(fā)送單元401，以實現(xiàn)只有當用戶需要時才推流。

從上述技術(shù)方案可知，本實施例中公開的推流裝置，第二判斷單元根據(jù)推流地址，判斷是否等待服務(wù)器發(fā)送的開始請求，若等待服務(wù)器發(fā)送的開始請求，則第一發(fā)送單元在接收到服務(wù)器發(fā)送的開始請求后，才向輸入源發(fā)送推流請求，第一接收單元接收輸入源響應(yīng)所述推流請求后推流的數(shù)據(jù)，推流單元將所述數(shù)據(jù)推流到所述服務(wù)器。而在沒接收到服務(wù)器發(fā)送的開始請求時，即沒有用戶需要從服務(wù)器獲取數(shù)據(jù)時，不會通過輸入源獲取數(shù)據(jù)，并且不會將數(shù)據(jù)推流到服務(wù)器中，實現(xiàn)了按需推流的目的，進而避免了占用網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)資源浪費的問題產(chǎn)生。若不等待服務(wù)器發(fā)送的開始請求，則直接將直播數(shù)據(jù)推流到與直播地址對應(yīng)的服務(wù)器上。本實施例中在可以實現(xiàn)按需推流的基礎(chǔ)上，還可以實現(xiàn)根據(jù)用戶需求選擇是否按需推流的目的，滿足了用戶的需求。

本說明書中各個實施例采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似部分互相參見即可。對于實施例提供的裝置而言，由于其與實施例提供的方法相對應(yīng)，所以描述的比較簡單，相關(guān)之處參見方法部分說明即可。

需要說明的是，在本文中，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

對所公開的實施例的上述說明，使本領(lǐng)域技術(shù)人員能夠?qū)崿F(xiàn)或使用本發(fā)明。對這些實施例的多種修改對本領(lǐng)域技術(shù)人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本發(fā)明的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本發(fā)明將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。

以上所述僅是本發(fā)明的優(yōu)選實施方式，應(yīng)當指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應(yīng)視為本發(fā)明的保護范圍。