專利名稱：基于http協(xié)議的直播流推流方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及HTTP報(bào)文傳輸技術(shù)，尤其涉及流媒體直播中使用HTTP協(xié)議的媒體傳輸技術(shù)。
背景技術(shù)：
在流媒體直播領(lǐng)域,直播流的推送目前主要使用RTMP協(xié)議(Real Time MessagingProtocol，實(shí)時(shí)消息傳送協(xié)議)或者RTMP的加密版本RTMPE協(xié)議。這兩個協(xié)議都?xì)wAdobe公司所有，其中RTMP協(xié)議只公開了一個初級版本，RTMPE協(xié)議未公開。使用RTMP協(xié)議進(jìn)行直播流推送的原理如下:1.編碼器首先與流媒體服務(wù)器進(jìn)行RTMP握手。2.編碼器與服務(wù)器通過connect命令建立一個邏輯連接。3.編碼器通過createStream命令創(chuàng)建一個流。4.編碼器在創(chuàng)建的流發(fā)送publish命令進(jìn)行推流。5.編碼器用RTMP的消息格式推送視頻和音頻數(shù)據(jù)，直到推流結(jié)束。使用該方法進(jìn)行直播推流，有以下幾個缺點(diǎn):(I)使用RTMP協(xié)議本身具有版權(quán)問題。(2)RTMP協(xié)議實(shí)現(xiàn)復(fù)雜，如果不使用Adobe公司提供的開發(fā)工具，推流器開發(fā)難度很大。如果使用Adobe公司提供的開發(fā)工具，開發(fā)出的推流程序需要運(yùn)行在Flash Player上，對運(yùn)行環(huán)境有特殊要求，不支持Flash Player的設(shè)備便無法用Adobe提供的工具經(jīng)行開發(fā)。(3)支持RTMP推流的流媒體服務(wù)器一般使用FMS (Flash Media Server)或者Wowza0大多是商用的，使用費(fèi)用昂貴，且定制功能的開發(fā)比較困難。自己開發(fā)服務(wù)器難度大，且涉及版權(quán)問題。(4) RTMP協(xié)議使用非通用端口，如1935.服務(wù)端前端的防火墻需要專門配置相關(guān)端口。

發(fā)明內(nèi)容
本發(fā)明的目的在于解決上述問題，提供了一種基于HTTP協(xié)議的直播流推流方法和系統(tǒng)，不會有RTMP協(xié)議的版權(quán)限制，不受Flash Player這種虛擬機(jī)運(yùn)行環(huán)境的限制，且開源服務(wù)器資源豐富，運(yùn)營時(shí)不必再經(jīng)行特殊端口的配置。本發(fā)明的技術(shù)方案為:本發(fā)明揭示了一種基于HTTP協(xié)議的直播流推流方法，包括推流器推送直播流的過程和流媒體服務(wù)器接收直播流的過程，其中:推流器推送直播流的過程如下:推流器連接流媒體服務(wù)器的推流端口 ；發(fā)送HTTP請求，其中HTTP請求中的URI為流名；讀取封裝成分段格式的直播流并將其設(shè)置在HTTP請求中發(fā)送；
待HTTP請求發(fā)送完畢后，根據(jù)所使用的HTTP的類型進(jìn)行處理；待直播流結(jié)束后停止推送；流媒體服務(wù)器接收直播流的過程如下:流媒體服務(wù)器監(jiān)聽服務(wù)端口 ；讀取HTTP請求，從URI中解析出流名；從HTTP請求中讀取分段格式的直播流；分析并處理直播流的每個分段，如果是非數(shù)據(jù)分段則直接處理，否則處理數(shù)據(jù)類型的分段，并將媒體數(shù)據(jù)加入到URI對應(yīng)的直播流中；在當(dāng)前HTTP請求發(fā)送完畢后根據(jù)HTTP的類型進(jìn)行處理。根據(jù)本發(fā)明的基于HTTP協(xié)議的直播流推流方法的一實(shí)施例，在推流器推送直播流的過程中，根據(jù)所使用的HTTP的類型進(jìn)行處理包括:若HTTP的類型是1.0或者1.1且非保持連接的情況，則斷開HTTP連接，從當(dāng)前的分段開始重新執(zhí)行推流器連接流媒體服務(wù)器的步驟；若HTTP的類型是1.1且保持連接的情況，則可以插入控制信息，然后從當(dāng)前的分段開始重新發(fā)送HTTP請求。根據(jù)本發(fā)明的基于HTTP協(xié)議的直播流推流方法的一實(shí)施例，在流媒體服務(wù)器接收直播流的過程中，根據(jù)HTTP的類型進(jìn)行處理包括:若HTTP的類型是1.0或者1.1且非保持連接的情況，則關(guān)閉HTTP的連接，等待重新推入；若HTTP的類型是1.1且保持連接的情況，則繼續(xù)讀取數(shù)據(jù)，返回HTTP推流請求的讀取步驟。根據(jù)本發(fā)明的基于HTTP協(xié)議的直播流推流方法的一實(shí)施例，在發(fā)送HTTP請求的過程中根據(jù)需要在數(shù)據(jù)類型的分段格式的直播流中插入控制類型的分段，以控制是否需要斷開當(dāng)前的HTTP連接來重新推流。本發(fā)明還揭示了一種基于HTTP協(xié)議的直播流推流系統(tǒng)，包括推流器和流媒體服務(wù)器兩個裝置，其中:推流器包括:連接模塊，推流器連接流媒體服務(wù)器的推流端口 ；請求發(fā)送模塊，發(fā)送HTTP請求，其中HTTP請求中的URI為流名；直播流發(fā)送模塊，讀取封裝成分段格式的直播流并將其設(shè)置在HTTP請求中發(fā)送；發(fā)送完成處理模塊，待HTTP請求發(fā)送完畢后，根據(jù)所使用的HTTP的類型進(jìn)行處理； 推送停止模塊，待直播流結(jié)束后停止推送；流媒體服務(wù)器包括:監(jiān)聽模塊，流媒體服務(wù)器監(jiān)聽服務(wù)端口 ；解析模塊，讀取HTTP請求，從URI中解析出流名；直播流讀取模塊，從HTTP請求中讀取分段格式的直播流；直播流處理模塊，分析并處理直播流的每個分段，如果是非數(shù)據(jù)分段則直接處理，否則處理數(shù)據(jù)類型的分段，并將媒體數(shù)據(jù)加入到URI對應(yīng)的直播流中；
接收完成處理模塊，在當(dāng)前HTTP請求發(fā)送完畢后根據(jù)HTTP的類型進(jìn)行處理。根據(jù)本發(fā)明的基于HTTP協(xié)議的直播流推流系統(tǒng)的一實(shí)施例，發(fā)送完成處理模塊進(jìn)一步包括:第一發(fā)送完成處理單元，若HTTP的類型是1.0或者1.1且非保持連接的情況，則斷開HTTP連接，從當(dāng)前的分段開始重新執(zhí)行連接模塊；第二發(fā)送完成處理單元，若HTTP的類型是1.1且保持連接的情況，則重新執(zhí)行請求發(fā)送模塊。根據(jù)本發(fā)明的基于HTTP協(xié)議的直播流推流系統(tǒng)的一實(shí)施例，接收完成處理模塊進(jìn)一步包括:第一接收完成處理單元，若HTTP的類型是1.0或者1.1且非保持連接的情況，則關(guān)閉HTTP的連接，等待重新推入；第二接收完成處理單元，若HTTP的類型是1.1且保持連接的情況，則繼續(xù)接收數(shù)據(jù)，返回執(zhí)行解析模塊。根據(jù)本發(fā)明的基于HTTP協(xié)議的直播流推流系統(tǒng)的一實(shí)施例，請求發(fā)送模塊還包括:控制單元，在發(fā)送HTTP請求的過程中根據(jù)需要在數(shù)據(jù)類型的分段格式的直播流中插入控制類型的分段，以控制是否需要斷開當(dāng)前的HTTP連接來重新推流。本發(fā)明對比現(xiàn)有技術(shù)有如下的有益效果:本發(fā)明的方案是使用HTTP協(xié)議經(jīng)行直播推流，這樣不再會有RTMP協(xié)議的版權(quán)限制。由于HTTP協(xié)議簡單，任何設(shè)備上都可以輕松實(shí)現(xiàn)，且開源的各種庫也很多，因此推流器開發(fā)容易，且不受Flash Player這種虛擬機(jī)運(yùn)行環(huán)境限制。HTTP協(xié)議的開源服務(wù)器資源豐富，不需要花昂貴的價(jià)錢使用FMS或者Wowza等支持RTMP協(xié)議的服務(wù)器，可控范圍大，定制功能的開發(fā)非常容易。HTTP協(xié)議使用80端口。一般的防火墻該端口都是開放的，所以不必再經(jīng)行特殊端口的配置，運(yùn)營方便。


圖1示出了本發(fā)明的基于HTTP協(xié)議的直播流推流方法的較佳實(shí)施例中的推流器端的流程圖。圖2示出了本發(fā)明的基于HTTP協(xié)議的直播流推流方法的較佳實(shí)施例中的流媒體服務(wù)器的流程圖。圖3示出了本發(fā)明的基于HTTP協(xié)議的直播流推流系統(tǒng)的較佳實(shí)施例的原理圖。
具體實(shí)施例方式下面結(jié)合附圖和實(shí)施例對本發(fā)明作進(jìn)一步的描述?；贖TTP協(xié)議的肓播流推流方法的實(shí)施例本實(shí)施例的基于HTTP協(xié)議的直播流推流方法包括推流器推送直播流的過程和流媒體服務(wù)器接收直播流的過程。圖1示出了推流器端的流程，圖2示出了流媒體服務(wù)器的流程。推流器推送直播流的過程如下:步驟SlOO:推流器連接流媒體服務(wù)器的推流端口(端口 80)，建立TCP連接。
步驟SlOl:發(fā)送HTTP請求(HTTP Request Header)。其中HTTP請求的命令為POST, URI為流名，Content-Length設(shè)置為一個合理值。在一次HTTP POST過程中，當(dāng)出現(xiàn)錯誤或者需要新的HTTP請求繼續(xù)推送時(shí)，重新建立新的TCP連接，發(fā)送POST Request來完成流的續(xù)接。步驟S102:讀取編碼器封裝成的分段格式(Segment)的直播流。編碼器編出的流媒體數(shù)據(jù)(音頻和視頻數(shù)據(jù))按照時(shí)間戳封裝成一系列的單元組，每個單元組包括自己的時(shí)間戳、數(shù)據(jù)長度和數(shù)據(jù)類型，這樣的一個單元組也稱為分段(Segment)。當(dāng)分段中任何一個域的值超過最大值時(shí)，該域重置。每次建立新的連接進(jìn)行推送時(shí)，分段的直播流的時(shí)間戳需要重置。步驟S103:判斷是否使用了控制信息。若使用了控制信息則進(jìn)入步驟S104，若未使用控制信息則進(jìn)入步驟S106。在發(fā)送HTTP請求的過程中可以根據(jù)需要在數(shù)據(jù)類型的分段格式的媒體流中插入控制類型的分段，來進(jìn)行續(xù)傳或者其它用途。步驟S104:判斷是否需要重新推流，若需要重新推流則進(jìn)入步驟S105，若不需要重新推流則進(jìn)入步驟S107。當(dāng)一個分段的時(shí)間戳歸零的時(shí)候，插入控制信息使得流可以續(xù)傳，或者斷開原來的HTTP POST Request的TCP連接，重新建立新的TCP連接發(fā)送POST Request來進(jìn)行流的續(xù)傳。步驟S105:斷開連接從本分段開始重發(fā)，并返回步驟S100。步驟S106:插入控制信息。亦即，在數(shù)據(jù)類型的分段格式的直播流中插入控制類型的分段，以控制是否需要斷開當(dāng)前的HTTP連接來重新推流。步驟S107:通過HTTP請求發(fā)送分段格式(Segment)數(shù)據(jù)。亦即，將分段格式的直播流放在HTTP請求的本體(Body)中發(fā)送。亦即，使用HTTP的POST方法將打包成分段格式的流媒體數(shù)據(jù)推送到流媒體服務(wù)器。步驟S108:判斷HTTP請求是否發(fā)送完畢，若發(fā)送完畢則進(jìn)入步驟S109，若未發(fā)送完畢則進(jìn)入步驟SI 10。步驟S109:判斷HTTP請求的類型是否為1.1且保持連接(ke印-alive)，若是則在當(dāng)前TCP連接繼續(xù)推流，也即從當(dāng)前分段開始重新執(zhí)行步驟SlOl，否則(HTTP類型是1.0，或者類型是1.1且非保持連接)斷開該HTTP連接并從當(dāng)前分段開始重新執(zhí)行步驟S105。步驟SllO:判斷直播流是否結(jié)束，若結(jié)束則整個推流器推送直播流的過程結(jié)束，若未結(jié)束則返回步驟S102。流媒體服務(wù)器的過程如下。步驟S200:流媒體服務(wù)器監(jiān)聽服務(wù)端口，接收推流器的請求，并建立TCP連接。步驟S201:讀取HTTP請求，從URI中解析出流名。步驟S202:判斷連接是否斷開，若斷開則流程結(jié)束，若未斷開則進(jìn)入步驟S203。步驟S203:從HTTP請求的Body中讀取分段格式的直播流，該直播流可能有媒體數(shù)據(jù)或者控制信息。在獲取到分段格式的直播流后，需要處理每個分段的數(shù)據(jù)類型、時(shí)間戳等，完成流的延續(xù)性。步驟S204:判斷讀取到的直播流是否是數(shù)據(jù)格式的分段，若是則進(jìn)入步驟S205，否則進(jìn)入步驟S207。步驟S205:對于數(shù)據(jù)類型的分段，處理分段格式的數(shù)據(jù)使其可以無縫拼接。步驟S206:將本分段數(shù)據(jù)加入U(xiǎn)RI對應(yīng)的直播流。步驟S207:直接處理該分段的信息。步驟S208:判斷HTTP請求的本體(Body)是否讀完，若讀完則進(jìn)入步驟S210，否則進(jìn)入步驟S209。步驟S209:繼續(xù)讀取HTTP請求的本體數(shù)據(jù)以獲取下一個分段，然后進(jìn)入步驟S204。步驟S210:判斷HTTP請求的類型是否為1.1且保持連接(ke印-alive)，若是則進(jìn)入步驟S201，否則關(guān)閉HTTP連接等待重新推入，流程結(jié)束?；贖TTP協(xié)議的肓播流推流系統(tǒng)的實(shí)施例圖3示出了本發(fā)明的基于HTTP協(xié)議的直播流推流系統(tǒng)的較佳實(shí)施例的原理。請參見圖3，本實(shí)施例的直播流推流系統(tǒng)包括推流器I和流媒體服務(wù)器2兩個裝置。其中推流器I包括:連接模塊10、請求發(fā)送模塊11、直播流發(fā)送模塊12、發(fā)送完成處理模塊13、推送停止模塊14。流媒體服務(wù)器2包括:監(jiān)聽模塊20、解析模塊21、直播流讀取模塊22、直播流處理模塊23、接收完成處理模塊24。在推流器I的處理過程中，連接模塊10負(fù)責(zé)推流器連接流媒體服務(wù)器的推流端口。即，推流器連接流媒體服務(wù)器的推流端口(端口 80)，建立TCP連接。請求發(fā)送模塊11發(fā)送HTTP請求(HTTP Request Header)，其中HTTP請求的命令為POST，URI為流名，Content-Length設(shè)置為一個合理值。在一次HTTP POST過程中，當(dāng)出現(xiàn)錯誤或者需要新的HTTP請求繼續(xù)推送時(shí)，重新建立新的TCP連接，發(fā)送POST Request來完成流的續(xù)接。請求發(fā)送模塊11還包括控制單元110，在發(fā)送HTTP請求的過程中根據(jù)需要在數(shù)據(jù)類型的分段格式的媒體流中插入控制類型的分段，以控制是否需要斷開當(dāng)前的HTTP連接來重新推流。當(dāng)一個分段的時(shí)間戳歸零的時(shí)候，插入控制信息使得流可以續(xù)傳，或者斷開原來的HTTP POST Request的TCP連接，重新建立新的TCP連接發(fā)送POST Request來進(jìn)行流的續(xù)傳。直播流發(fā)送模塊12讀取編碼器封裝成的分段格式的直播流并將其設(shè)置在HTTP請求中發(fā)送。編碼器編出的流媒體數(shù)據(jù)(音頻和視頻數(shù)據(jù))按照時(shí)間戳封裝成一系列的單元組，每個單元組包括自己的時(shí)間戳、數(shù)據(jù)長度和數(shù)據(jù)類型，這樣的一個單元組也稱為分段(Segment)。當(dāng)分段中任何一個域的值超過最大值時(shí)，該域重置。每次建立新的連接進(jìn)行推送時(shí)，分段的直播流的時(shí)間戳需要重置。發(fā)送完成處理模塊13待HTTP請求發(fā)送完畢后，根據(jù)所使用的HTTP的類型進(jìn)行處理。推送停止模塊14待直播流結(jié)束后停止推送。發(fā)送完成處理模塊13進(jìn)一步包括第一發(fā)送完成處理單元130和第二發(fā)送完成處理單元132。其中第一發(fā)送完成處理單元130完成的處理是:若HTTP的類型是1.0或者1.1且非保持連接的情況，則斷開HTTP連接，從當(dāng)前的分段開始重新執(zhí)行連接模塊。第二發(fā)送完成處理單元132完成的處理是:若HTTP的類型是1.1且保持連接的情況，則重新執(zhí)行請求發(fā)送模塊12。
在流媒體服務(wù)器2的處理過程中，監(jiān)聽模塊20負(fù)責(zé)流媒體服務(wù)器2監(jiān)聽服務(wù)端口。解析模塊21讀取HTTP請求，從URI中解析出流名。直播流讀取模塊22從HTTP請求中讀取分段格式的直播流。在獲取到分段格式的直播流后，需要處理每個分段的數(shù)據(jù)類型、時(shí)間戳等，完成流的延續(xù)性。直播流處理模塊23分析并處理直播流的每個分段，如果是非數(shù)據(jù)分段則直接處理,否則處理數(shù)據(jù)類型的分段,并將媒體數(shù)據(jù)加入到URI對應(yīng)的直播流中。接收完成處理模塊24在當(dāng)前HTTP請求發(fā)送完畢后根據(jù)HTTP的類型進(jìn)行處理。接收完成處理模塊24進(jìn)一步包括第一接收完成處理單元240和第二接收完成處理單元242。其中第一接收完成處理單元240完成的處理是:若HTTP的類型是1.0或者1.1且非保持連接的情況，則關(guān)閉HTTP的連接，等待重新推入。第二接收完成處理單元242完成的處理是:若HTTP的類型是1.1且保持連接的情況，則返回執(zhí)行解析模塊21。上述實(shí)施例是提供給本領(lǐng)域普通技術(shù)人員來實(shí)現(xiàn)和使用本發(fā)明的，本領(lǐng)域普通技術(shù)人員可在不脫離本發(fā)明的發(fā)明思想的情況下，對上述實(shí)施例做出種種修改或變化，因而本發(fā)明的保護(hù)范圍并不被上述實(shí)施例所限，而應(yīng)該是符合權(quán)利要求書所提到的創(chuàng)新性特征的最大范圍。
權(quán)利要求
1.一種基于HTTP協(xié)議的直播流推流方法，包括推流器推送直播流的過程和流媒體服務(wù)器接收直播流的過程，其中: 推流器推送直播流的過程如下: 推流器連接流媒體服務(wù)器的推流端口 ； 發(fā)送HTTP請求，其中HTTP請求中的URI為流名； 讀取封裝好的分段格式的直播流并在HTTP請求中發(fā)送； 待HTTP請求發(fā)送完畢后，根據(jù)所使用的HTTP的類型進(jìn)行處理； 待直播流結(jié)束后停止推送； 流媒體服務(wù)器接收直播流的過程如下: 流媒體服務(wù)器監(jiān)聽服務(wù)端口； 讀取HTTP請求，從URI中解析出流名； 從HTTP請求中讀取分段 格式的直播流； 分析并處理直播流的每個分段，如果是非數(shù)據(jù)分段則直接處理，否則處理數(shù)據(jù)類型的分段，并將媒體數(shù)據(jù)加入到URI對應(yīng)的直播流中； 在當(dāng)前HTTP請求接收完畢后根據(jù)HTTP的類型進(jìn)行處理。
2.根據(jù)權(quán)利要求1所述的基于HTTP協(xié)議的直播流推流方法，其特征在于，在推流器推送直播流的過程中，根據(jù)所使用的HTTP的類型進(jìn)行處理包括: 若HTTP的類型是1.0或者1.1且非保持連接的情況，則斷開HTTP連接，從當(dāng)前的分段開始重新執(zhí)行推流器連接流媒體服務(wù)器的步驟； 若HTTP的類型是1.1且保持連接的情況，則從當(dāng)前的分段開始重新發(fā)送HTTP請求。
3.根據(jù)權(quán)利要求2所述的基于HTTP協(xié)議的直播流推流方法，其特征在于，在流媒體服務(wù)器接收直播流的過程中，根據(jù)HTTP的類型進(jìn)行處理包括: 若HTTP的類型是1.0或者1.1且非保持連接的情況，則關(guān)閉HTTP的連接，等待重新推A ； 若HTTP的類型是1.1且保持連接的情況，則重新進(jìn)入HTTP推流請求的讀取步驟。
4.根據(jù)權(quán)利要求3所述的基于HTTP協(xié)議的直播流推流方法，其特征在于，在發(fā)送HTTP請求的過程中根據(jù)需要在數(shù)據(jù)類型分段的直播流中插入控制類型的分段，以控制是否需要斷開當(dāng)前的HTTP連接來重新推流。
5.一種基于HTTP協(xié)議的直播流推流系統(tǒng)，包括推流器和流媒體服務(wù)器兩個裝置，其中: 推流器包括: 連接模塊，推流器連接流媒體服務(wù)器的推流端口 ； 請求發(fā)送模塊，發(fā)送HTTP請求，其中HTTP請求中的URI為流名； 直播流發(fā)送模塊，讀取封裝好的分段格式的直播流并在HTTP請求中發(fā)送； 發(fā)送完成處理模塊，待HTTP請求發(fā)送完畢后，根據(jù)所使用的HTTP的類型進(jìn)行處理； 推送停止模塊，待直播流結(jié)束后停止推送； 流媒體服務(wù)器包括: 監(jiān)聽模塊，流媒體服務(wù)器監(jiān)聽服務(wù)端口 ； 解析模塊，讀取HTTP請求，從URI中解析出流名；直播流讀取模塊，從HTTP請求中讀取分段格式的直播流； 直播流處理模塊，分析并處理直播流的每個分段，如果是非數(shù)據(jù)分段則直接處理，否則處理數(shù)據(jù)類型的分段,并將媒體數(shù)據(jù)加入到URI對應(yīng)的直播流中； 接收完成處理模塊，在當(dāng)前HTTP請求接收完畢后根據(jù)HTTP的類型進(jìn)行處理。
6.根據(jù)權(quán)利要求5所述的基于HTTP協(xié)議的直播流推流系統(tǒng)，其特征在于，發(fā)送完成處理模塊進(jìn)一步包括: 第一發(fā)送完成處理單元，若HTTP的類型是1.0或者1.1且非保持連接的情況，則斷開HTTP連接，從當(dāng)前的分段開始重新執(zhí)行連接模塊； 第二發(fā)送完成處理單元，若HTTP的類型是1.1且保持連接的情況，則重新執(zhí)行請求發(fā)送模塊。
7.根據(jù)權(quán)利要求6所述的基于HTTP協(xié)議的直播流推流系統(tǒng)，其特征在于，接收完成處理模塊進(jìn)一步包括: 第一接收完成處理單元，若HTTP的類型是1.0或者1.1且非保持連接的情況，則關(guān)閉HTTP的連接，等待重新推入； 第二接收完成處理單元，若HTTP的類型是1.1且保持連接的情況，則返回繼續(xù)接收數(shù)據(jù)執(zhí)行解析模塊。
8.根據(jù)權(quán)利要求7所述的基于HTTP協(xié)議的直播流推流系統(tǒng)，其特征在于，請求發(fā)送模塊還包括: 控制單元，在發(fā)送HTTP請求的過程中根據(jù)需要在數(shù)據(jù)類型分段的直播流中插入控制類型的分段，以控制是否需要斷開當(dāng)前的HTTP連接來重新推流。
全文摘要
本發(fā)明公開了基于HTTP協(xié)議的直播流推流方法和系統(tǒng)，不受RTMP協(xié)議版權(quán)限制和Flash平臺限制，開源服務(wù)器資源豐富。其技術(shù)方案為方法包括推流器推送直播流過程和流媒體服務(wù)器接收直播流過程，其中推流器的過程為推流器連接流媒體服務(wù)器的推流端口；發(fā)送HTTP請求；讀取封裝好的分段格式的直播流并在HTTP請求中發(fā)送；根據(jù)HTTP的類型進(jìn)行處理；最后停止推送。流媒體服務(wù)器的過程為流媒體服務(wù)器監(jiān)聽服務(wù)端口；讀取HTTP請求，解析流名；讀取分段格式的直播流；分析處理每個分段，如果是非數(shù)據(jù)分段則直接處理，否則處理數(shù)據(jù)類型的分段，并將媒體數(shù)據(jù)加入到URI對應(yīng)的直播流中；接收完畢后根據(jù)HTTP類型進(jìn)行處理。
文檔編號H04L29/08GK103179214SQ201310123980
公開日2013年6月26日 申請日期2013年4月10日 優(yōu)先權(quán)日2013年4月10日
發(fā)明者洪珂, 白永光, 郭斌 申請人:網(wǎng)宿科技股份有限公司