本發(fā)明屬于視頻監(jiān)控技術(shù)領(lǐng)域，涉及一種視頻處理裝置及方法，特別是涉及一種流媒體適配器及適配方法。

背景技術(shù)：

隨著安防高科技的發(fā)展，視頻監(jiān)控已經(jīng)成為各行業(yè)單位和家庭對(duì)重要場(chǎng)所進(jìn)行實(shí)時(shí)監(jiān)視控制或遠(yuǎn)程交互的物理基礎(chǔ)。當(dāng)前互聯(lián)網(wǎng)時(shí)代已經(jīng)深入人心，移動(dòng)設(shè)備對(duì)于人們的日常生活來(lái)說(shuō)已經(jīng)是必不可少的工具。人們可通過(guò)它獲得視頻圖像或聲音信息，能夠?qū)ν话l(fā)性異常事件的發(fā)生過(guò)程進(jìn)行及時(shí)的監(jiān)視和記憶，甚至能夠及時(shí)進(jìn)行現(xiàn)場(chǎng)對(duì)講，遠(yuǎn)程指導(dǎo)或監(jiān)督控制，并在事后調(diào)用存儲(chǔ)錄像進(jìn)行跟蹤，還原事發(fā)當(dāng)時(shí)的情景。視頻監(jiān)控系統(tǒng)通常是由采集、傳輸、控制、顯示、存儲(chǔ)等五個(gè)部分組成。其中實(shí)現(xiàn)采集過(guò)程的設(shè)備主要為具有攝像頭的裝置，如槍機(jī)、球機(jī)、手機(jī)自帶的攝像機(jī)等等。音視頻主要可以通過(guò)有線IP、無(wú)線WIFI、3/4G數(shù)據(jù)通信信道進(jìn)行傳輸。在監(jiān)控系統(tǒng)中，攝像頭通常是安裝在云臺(tái)上的，故操作人員可以通過(guò)主機(jī)發(fā)出控制指令，對(duì)云臺(tái)的上、下、左、右的動(dòng)作進(jìn)行控制以及對(duì)鏡頭的焦距進(jìn)行調(diào)節(jié)，同時(shí)還可以在多路攝像機(jī)及云臺(tái)之間進(jìn)行切換控制。音視頻存儲(chǔ)對(duì)于監(jiān)控系統(tǒng)來(lái)說(shuō)是不可或缺的部分，誰(shuí)也不能保證事件發(fā)生過(guò)程中我們能夠及時(shí)預(yù)覽觀察到。因而事后調(diào)用存儲(chǔ)錄像進(jìn)行跟蹤，對(duì)還原事發(fā)當(dāng)時(shí)的情景進(jìn)行分析和判斷，是十分重要的。

視頻監(jiān)控顯示的功能已經(jīng)不再局限于普通PC機(jī)上了，移動(dòng)終端也可以進(jìn)行監(jiān)控顯示，如手機(jī)等設(shè)備亦可以進(jìn)行監(jiān)控。但是基于現(xiàn)在手機(jī)的配置能力來(lái)說(shuō)，預(yù)覽一路1080P的視頻解碼就已經(jīng)有些吃不消了，手機(jī)會(huì)出現(xiàn)卡頓現(xiàn)象。并且現(xiàn)階段的3/4G網(wǎng)絡(luò)亦不能達(dá)到實(shí)時(shí)預(yù)覽監(jiān)控視頻的帶寬要求。因此，如何解決現(xiàn)階段移動(dòng)網(wǎng)絡(luò)傳輸帶寬限制手機(jī)移動(dòng)端同時(shí)顯示多路高分辨率的監(jiān)控視頻，是本發(fā)明所要解決的技術(shù)問(wèn)題。

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

鑒于以上所述現(xiàn)有技術(shù)的缺點(diǎn)，本發(fā)明的目的在于提供一種流媒體適配器及適配方法，用于解決現(xiàn)有移動(dòng)端因視頻解碼能力和網(wǎng)絡(luò)傳輸帶寬受限導(dǎo)致不能同時(shí)預(yù)覽和回放多路高分辨率的監(jiān)控視頻的問(wèn)題。

為實(shí)現(xiàn)上述目的及其他相關(guān)目的，本發(fā)明提供一種流媒體適配器，所述流媒體適配器包 括：視頻輸入模塊，接收監(jiān)控所需路數(shù)的音視頻數(shù)字信息；視頻解碼模塊，與所述視頻輸入模塊相連，將所述監(jiān)控所需路數(shù)的音視頻數(shù)字信息解碼成對(duì)應(yīng)路數(shù)的YUV數(shù)據(jù)；多畫(huà)面合成模塊，與所述視頻解碼模塊相連，將所述監(jiān)控所需路數(shù)的YUV數(shù)據(jù)按照監(jiān)控需求進(jìn)行碼流、圖像質(zhì)量?jī)?yōu)化并將優(yōu)化后的各路YUV數(shù)據(jù)合并處理，生成具有監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)；視頻編碼模塊，與所述多畫(huà)面合成模塊相連，將所述監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)編碼成可通過(guò)網(wǎng)絡(luò)傳輸?shù)囊宦芬粢曨l數(shù)字信號(hào)。

可選地，所述多畫(huà)面合成模塊包括：合成模板，將所述監(jiān)控所需路數(shù)的YUV數(shù)據(jù)合成具有與監(jiān)控所需路數(shù)數(shù)目相同的畫(huà)面的一路YUV數(shù)據(jù)；合成質(zhì)量控制單元，與所述合成模板相連，根據(jù)所述監(jiān)控需求反映的監(jiān)控終端的帶寬狀況控制所述一路YUV數(shù)據(jù)的圖像合成質(zhì)量及傳輸碼流值。

可選地，所述視頻輸入模塊包括ONVIF客戶端、GB/T28181服務(wù)器、平臺(tái)對(duì)接SDK、或/和設(shè)備網(wǎng)絡(luò)SDK。

可選地，所述視頻解碼模塊包括公有解碼模塊、或/和私有解碼模塊；所述公有解碼模塊包括H264解碼模塊、H265解碼模塊、或MPEG解碼模塊。

可選地，所述多畫(huà)面合成模塊還用于接收監(jiān)控終端發(fā)送的所述監(jiān)控需求；所述監(jiān)控需求包括所述監(jiān)控終端需要監(jiān)控的視頻路數(shù)和所述監(jiān)控終端的網(wǎng)絡(luò)帶寬。

本發(fā)明還提供一種流媒體適配方法，所述流媒體適配方法包括：接收監(jiān)控所需路數(shù)的音視頻數(shù)字信息；將所述監(jiān)控所需路數(shù)的音視頻數(shù)字信息解碼成對(duì)應(yīng)路數(shù)的YUV數(shù)據(jù)；將所述監(jiān)控所需路數(shù)的YUV數(shù)據(jù)按照監(jiān)控需求進(jìn)行碼流、圖像質(zhì)量?jī)?yōu)化并將優(yōu)化后的各路YUV數(shù)據(jù)合并處理，生成具有監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)；將所述監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)編碼成可通過(guò)網(wǎng)絡(luò)傳輸?shù)囊宦芬粢曨l數(shù)字信號(hào)。

可選地，所述流媒體適配方法還包括：根據(jù)所述監(jiān)控需求反映的監(jiān)控終端的帶寬狀況控制所述一路YUV數(shù)據(jù)的圖像合成質(zhì)量及傳輸碼流值。

可選地，所述流媒體適配方法還包括：通過(guò)ONVIF客戶端、或/和GB/T28181服務(wù)器接入監(jiān)控所需的音視頻數(shù)字信息；或/和通過(guò)二次開(kāi)發(fā)的平臺(tái)對(duì)接SDK、或/和設(shè)備網(wǎng)絡(luò)SDK接入監(jiān)控所需的音視頻數(shù)字信息。

可選地，所述流媒體適配方法還包括：對(duì)于基于標(biāo)準(zhǔn)協(xié)議的音視頻數(shù)字信息，采用開(kāi)源視頻編解碼庫(kù)進(jìn)行解碼；對(duì)于基于私有協(xié)議的音視頻數(shù)字信息，采用對(duì)應(yīng)廠商提供的對(duì)應(yīng)設(shè)備類(lèi)型的解碼庫(kù)進(jìn)行解碼。

可選地，所述監(jiān)控需求包括監(jiān)控終端需要監(jiān)控的視頻路數(shù)和所述監(jiān)控終端的網(wǎng)絡(luò)帶寬。

如上所述，本發(fā)明所述的流媒體適配器及適配方法，具有以下有益效果：

采用本發(fā)明可以使各類(lèi)型的視頻監(jiān)控設(shè)備均可接入到監(jiān)控系統(tǒng)，并且無(wú)需擔(dān)心手機(jī)終端的解碼能力；在多畫(huà)面監(jiān)控時(shí)，也不用擔(dān)心由于手機(jī)終端的解碼能力不夠而導(dǎo)致手機(jī)終端卡死或觀看視頻卡頓的問(wèn)題。此外，在網(wǎng)絡(luò)帶寬緊張的時(shí)候，也可以令手機(jī)終端進(jìn)行多畫(huà)面的視頻監(jiān)控。

附圖說(shuō)明

圖1為本發(fā)明實(shí)施例所述的流媒體適配器的一種實(shí)現(xiàn)結(jié)構(gòu)示意圖。

圖2為本發(fā)明實(shí)施例所述的多畫(huà)面合成模塊的一種實(shí)現(xiàn)結(jié)構(gòu)示意圖。

圖3a至圖3c為多畫(huà)面圖像的一種顯示示意圖。

圖4為本發(fā)明實(shí)施例所述的流媒體適配方法的一種實(shí)現(xiàn)流程示意圖。

元件標(biāo)號(hào)說(shuō)明

100 流媒體適配器

110 視頻輸入模塊

120 視頻解碼模塊

130 多畫(huà)面合成模塊

131 合成模板

132 合成質(zhì)量控制單元

140 視頻編碼模塊

S41～S44 步驟

具體實(shí)施方式

以下通過(guò)特定的具體實(shí)例說(shuō)明本發(fā)明的實(shí)施方式，本領(lǐng)域技術(shù)人員可由本說(shuō)明書(shū)所揭露的內(nèi)容輕易地了解本發(fā)明的其他優(yōu)點(diǎn)與功效。本發(fā)明還可以通過(guò)另外不同的具體實(shí)施方式加以實(shí)施或應(yīng)用，本說(shuō)明書(shū)中的各項(xiàng)細(xì)節(jié)也可以基于不同觀點(diǎn)與應(yīng)用，在沒(méi)有背離本發(fā)明的精神下進(jìn)行各種修飾或改變。

請(qǐng)參閱附圖。需要說(shuō)明的是，本實(shí)施例中所提供的圖示僅以示意方式說(shuō)明本發(fā)明的基本構(gòu)想，遂圖式中僅顯示與本發(fā)明中有關(guān)的組件而非按照實(shí)際實(shí)施時(shí)的組件數(shù)目、形狀及尺寸繪制，其實(shí)際實(shí)施時(shí)各組件的型態(tài)、數(shù)量及比例可為一種隨意的改變，且其組件布局型態(tài)也可能更為復(fù)雜。

下面結(jié)合實(shí)施例和附圖對(duì)本發(fā)明進(jìn)行詳細(xì)說(shuō)明。

實(shí)施例

本實(shí)施例提供一種流媒體適配器，如圖1所示，所述流媒體適配器100包括：視頻輸入模塊110，視頻解碼模塊120，多畫(huà)面合成模塊130，視頻編碼模塊140。

所述視頻輸入模塊110接收監(jiān)控所需路數(shù)的音視頻數(shù)字信息。所述視頻輸入模塊110是一種能夠接收基于不同協(xié)議的數(shù)字視頻輸入的設(shè)備的統(tǒng)稱(chēng)，其接收的多路輸入數(shù)字視頻情況包括：1、通過(guò)標(biāo)準(zhǔn)協(xié)議，如ONVIF\GB28181等標(biāo)準(zhǔn)協(xié)議，接入前端監(jiān)控設(shè)備，前端監(jiān)控設(shè)備采集到的音視頻數(shù)字信息通過(guò)IP網(wǎng)絡(luò)(TCP或UDP)進(jìn)行傳輸。2、通過(guò)設(shè)備廠商提供的設(shè)備網(wǎng)絡(luò)SDK開(kāi)發(fā)包，進(jìn)行二次開(kāi)發(fā)，即可將對(duì)應(yīng)的廠商的視頻監(jiān)控設(shè)備進(jìn)行對(duì)接。

進(jìn)一步，所述視頻輸入模塊110包括ONVIF客戶端、GB/T28181服務(wù)器、平臺(tái)對(duì)接SDK(Software Development Kit，軟件開(kāi)發(fā)工具包)、或/和設(shè)備網(wǎng)絡(luò)SDK。所述前端視頻接入模塊(即所述視頻輸入模塊)也可以采用協(xié)議類(lèi)的接入方式：如ONVIF協(xié)議，那么接收端需要用ONVIF客戶端進(jìn)行接入，前端設(shè)備相當(dāng)于服務(wù)端；如GB/T28181協(xié)議，那么接收端需要用服務(wù)器進(jìn)行接入，前端設(shè)備相當(dāng)于客戶端。所述前端視頻接入模塊(即所述視頻輸入模塊)也可以采用平臺(tái)對(duì)接SDK和設(shè)備網(wǎng)絡(luò)SDK的接入方式，則需要設(shè)備廠商提供一整套SDK資料，包括DEMO程序進(jìn)行調(diào)試用，在接收端進(jìn)行SDK的二次開(kāi)發(fā)。即所述前端視頻接入模塊可以通過(guò)ONVIF/GB/T28181/平臺(tái)、SDK/設(shè)備網(wǎng)絡(luò)SDK等方式將視頻數(shù)字信號(hào)送至視頻解碼模塊120，并通過(guò)獲知手機(jī)終端的預(yù)覽數(shù)和網(wǎng)絡(luò)帶寬，通過(guò)多畫(huà)面合成模塊130合成一路YUV視頻數(shù)據(jù)，然后通過(guò)視頻編碼模塊140編碼成數(shù)字信號(hào)，最后通過(guò)TCP/UDP網(wǎng)絡(luò)傳輸?shù)绞謾C(jī)終端。

所述視頻解碼模塊120與所述視頻輸入模塊110相連，將所述監(jiān)控所需路數(shù)的音視頻數(shù)字信息解碼成對(duì)應(yīng)路數(shù)的YUV數(shù)據(jù)。

進(jìn)一步，所述視頻解碼模塊120包括公有解碼模塊、或/和私有解碼模塊；所述公有解碼模塊包括H264解碼模塊、H265解碼模塊、或MPEG解碼模塊。對(duì)于標(biāo)準(zhǔn)視頻流(即公有視頻流)接入時(shí)，所述視頻解碼模塊可以采用ffmpeg等開(kāi)源視頻編解碼庫(kù)進(jìn)行解碼。該開(kāi)源庫(kù)能支持一系列主流的編碼格式，適用范圍很廣。除了傳統(tǒng)的軟解之外，所述視頻解碼模塊也可以采用硬解的方式實(shí)現(xiàn)。對(duì)于私有視頻流接入時(shí)，所述視頻解碼模塊則需設(shè)備廠商提供對(duì)應(yīng)設(shè)備類(lèi)型的解碼庫(kù)進(jìn)行解碼。作為多畫(huà)面合成的前提，所述視頻解碼模塊需要將多路經(jīng)過(guò)編碼的數(shù)字信息輸入(即多路音視頻數(shù)字信息)解碼成原始的YUV數(shù)據(jù)。對(duì)于如H264\H265\MPEG或把標(biāo)準(zhǔn)編碼協(xié)議進(jìn)行改進(jìn)的私有編碼方式，所述視頻解碼模塊可以分為兩種情況：A、公有解碼模塊，即對(duì)標(biāo)準(zhǔn)的編碼格式的數(shù)字信息采用開(kāi)源的解碼庫(kù)，如ffmpeg 等，進(jìn)行軟解亦或硬解。B、私有解碼模塊，即對(duì)于私有的編碼格式的數(shù)字信息就只能通過(guò)設(shè)備廠家提供對(duì)應(yīng)的解碼庫(kù)進(jìn)行解碼。

所述多畫(huà)面合成模塊130與所述視頻解碼模塊120相連，將所述監(jiān)控所需路數(shù)的YUV數(shù)據(jù)按照監(jiān)控需求進(jìn)行碼流、圖像質(zhì)量?jī)?yōu)化并將優(yōu)化后的各路YUV數(shù)據(jù)合并處理，生成具有監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)。所述多畫(huà)面合成模塊130還用于接收監(jiān)控終端發(fā)送的所述監(jiān)控需求；所述監(jiān)控需求包括所述監(jiān)控終端需要監(jiān)控的視頻路數(shù)和所述監(jiān)控終端的網(wǎng)絡(luò)帶寬。合成后的一路視頻數(shù)據(jù)，所述多畫(huà)面合成模塊130通過(guò)檢測(cè)手機(jī)移動(dòng)終端所在的實(shí)際的網(wǎng)絡(luò)帶寬情況，在多畫(huà)面合成時(shí)，可以利用降低碼率、圖像質(zhì)量等方式進(jìn)行自適應(yīng)傳輸合成后的一路視頻數(shù)據(jù)所需的帶寬，即所述多畫(huà)面合成模塊130可以輸出額定帶寬的視頻數(shù)據(jù)。

進(jìn)一步，如圖2所示，所述多畫(huà)面合成模塊130包括：合成模板131，合成質(zhì)量控制單元132。所述合成模板131將所述監(jiān)控所需路數(shù)的YUV數(shù)據(jù)合成具有與監(jiān)控所需路數(shù)數(shù)目相同的畫(huà)面的一路YUV數(shù)據(jù)。所述合成質(zhì)量控制單元132與所述合成模板131相連，根據(jù)所述監(jiān)控需求反映的監(jiān)控終端的帶寬狀況控制所述一路YUV數(shù)據(jù)的圖像合成質(zhì)量及傳輸碼流值。所述合成模板131是根據(jù)通過(guò)TCP/UDP網(wǎng)絡(luò)交互獲知手機(jī)終端的預(yù)覽路數(shù)進(jìn)行確定的。預(yù)覽幾路監(jiān)控視頻就合成幾畫(huà)面的一路視頻。合成質(zhì)量控制單元132也是通過(guò)TCP/UDP網(wǎng)絡(luò)交互獲知手機(jī)終端所在網(wǎng)絡(luò)的帶寬狀況，如果帶寬充裕，則合成的圖像質(zhì)量選擇高些，碼流值大些。反之，網(wǎng)絡(luò)帶寬很擁擠時(shí)，則降低合成的圖像質(zhì)量和視頻碼流值。

所述多畫(huà)面合成模塊130對(duì)視頻解碼后得到的YUV數(shù)據(jù)進(jìn)行按監(jiān)控需求進(jìn)行碼流、圖像質(zhì)量?jī)?yōu)化并將優(yōu)化后的各路YUV數(shù)據(jù)合并處理，二次編碼的格式可以選用標(biāo)準(zhǔn)化的編碼協(xié)議，二次編碼的過(guò)程也可選軟編亦或硬編。而多畫(huà)面的合成模板131則按實(shí)際監(jiān)控需求進(jìn)行適配，如，在監(jiān)控兩路實(shí)時(shí)視頻時(shí)，則合并成平行的兩畫(huà)面的一路圖像，如圖3a所示；而在監(jiān)控三路實(shí)時(shí)視頻時(shí)，則合并成三畫(huà)面的一路圖像，如圖3b所示；在監(jiān)控四路實(shí)時(shí)視頻時(shí)，則合并成四畫(huà)面的一路圖像，如圖3c所示；依此類(lèi)推。

所述視頻編碼模塊140與所述多畫(huà)面合成模塊130相連，將所述監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)編碼成可通過(guò)網(wǎng)絡(luò)傳輸?shù)囊宦芬粢曨l數(shù)字信號(hào)。所述視頻編碼模塊140是一種視頻YUV數(shù)據(jù)編碼模塊，其可以采用軟編碼方式實(shí)現(xiàn)，如主要用ffmpeg等開(kāi)源視頻編解碼庫(kù)即可；也可以采用硬編碼方式實(shí)現(xiàn)，如：可用OPENCV調(diào)用GPU進(jìn)行硬編的方式。

采用本發(fā)明所述的流媒體適配器，可以使各類(lèi)型的視頻監(jiān)控設(shè)備均可接入到監(jiān)控系統(tǒng)，并且無(wú)需擔(dān)心手機(jī)終端的解碼能力；在多畫(huà)面監(jiān)控時(shí)，也不用擔(dān)心由于手機(jī)終端的解碼能力 不夠而導(dǎo)致手機(jī)終端卡死或觀看視頻卡頓的問(wèn)題。此外，在網(wǎng)絡(luò)帶寬緊張的時(shí)候，也可以令手機(jī)終端進(jìn)行多畫(huà)面的視頻監(jiān)控。

本實(shí)施例還提供一種流媒體適配方法，該方法可以由本發(fā)明所述的流媒體適配器實(shí)現(xiàn)，但本發(fā)明所述流媒體適配方法的實(shí)現(xiàn)裝置的保護(hù)范圍不限于本發(fā)明所述的流媒體適配器的結(jié)構(gòu)，凡是本領(lǐng)域技術(shù)人員根據(jù)本發(fā)明的原理實(shí)現(xiàn)的方案都包括在本發(fā)明的保護(hù)范圍內(nèi)。

如圖4所示，所述流媒體適配方法包括：

S41，接收監(jiān)控所需路數(shù)的音視頻數(shù)字信息。

進(jìn)一步，通過(guò)ONVIF客戶端、或/和GB/T28181服務(wù)器接入監(jiān)控所需的音視頻數(shù)字信息；或/和通過(guò)二次開(kāi)發(fā)的平臺(tái)對(duì)接SDK、或/和設(shè)備網(wǎng)絡(luò)SDK接入監(jiān)控所需的音視頻數(shù)字信息。接收的多路輸入數(shù)字視頻情況包括：1、通過(guò)標(biāo)準(zhǔn)協(xié)議，如ONVIF\GB28181等標(biāo)準(zhǔn)協(xié)議，接入前端監(jiān)控設(shè)備，前端監(jiān)控設(shè)備采集到的音視頻數(shù)字信息通過(guò)IP網(wǎng)絡(luò)(TCP或UDP)進(jìn)行傳輸。2、通過(guò)設(shè)備廠商提供的設(shè)備網(wǎng)絡(luò)SDK開(kāi)發(fā)包，進(jìn)行二次開(kāi)發(fā)，即可將對(duì)應(yīng)的廠商的視頻監(jiān)控設(shè)備進(jìn)行對(duì)接。即：步驟S41可以采用協(xié)議類(lèi)的接入方式：如ONVIF協(xié)議，那么接收端需要用ONVIF客戶端進(jìn)行接入，前端設(shè)備相當(dāng)于服務(wù)端；如GB/T28181協(xié)議，那么接收端需要用服務(wù)器進(jìn)行接入，前端設(shè)備相當(dāng)于客戶端。步驟S41也可以采用平臺(tái)SDK和設(shè)備網(wǎng)絡(luò)SDK的接入方式，則需要設(shè)備廠商提供一整套SDK資料，包括DEMO程序進(jìn)行調(diào)試用，在接收端進(jìn)行SDK的二次開(kāi)發(fā)。即所述步驟S41可以通過(guò)ONVIF/GB/T28181/平臺(tái)、SDK/設(shè)備網(wǎng)絡(luò)SDK等方式接收視頻數(shù)字信號(hào)然后進(jìn)行視頻解碼，并通過(guò)獲知手機(jī)終端的預(yù)覽數(shù)和網(wǎng)絡(luò)帶寬，將解碼后的多路YUV視頻數(shù)據(jù)合成一路YUV視頻數(shù)據(jù)，然后再編碼成數(shù)字信號(hào)，最后通過(guò)TCP/UDP網(wǎng)絡(luò)傳輸?shù)绞謾C(jī)終端。

S42，將所述監(jiān)控所需路數(shù)的音視頻數(shù)字信息解碼成對(duì)應(yīng)路數(shù)的YUV數(shù)據(jù)。

進(jìn)一步，對(duì)于基于標(biāo)準(zhǔn)協(xié)議的音視頻數(shù)字信息，采用開(kāi)源視頻編解碼庫(kù)進(jìn)行解碼；對(duì)于基于私有協(xié)議的音視頻數(shù)字信息，采用對(duì)應(yīng)廠商提供的對(duì)應(yīng)設(shè)備類(lèi)型的解碼庫(kù)進(jìn)行解碼。對(duì)于標(biāo)準(zhǔn)視頻流(即公有視頻流)接入時(shí)，可以采用ffmpeg等開(kāi)源視頻編解碼庫(kù)進(jìn)行解碼。該開(kāi)源庫(kù)能支持一系列主流的編碼格式，適用范圍很廣。除了傳統(tǒng)的軟解之外，也可以采用硬解的方式實(shí)現(xiàn)。對(duì)于私有視頻流接入時(shí)，則需設(shè)備廠商提供對(duì)應(yīng)設(shè)備類(lèi)型的解碼庫(kù)進(jìn)行解碼。作為多畫(huà)面合成的前提，需要將多路經(jīng)過(guò)編碼的數(shù)字信息輸入(即多路音視頻數(shù)字信息)解碼成原始的YUV數(shù)據(jù)。對(duì)于如H264\H265\MPEG或把標(biāo)準(zhǔn)編碼協(xié)議進(jìn)行改進(jìn)的私有編碼方式，可以分為兩種情況：A、公有解碼，即對(duì)標(biāo)準(zhǔn)的編碼格式的數(shù)字信息采用開(kāi)源的解碼庫(kù)，如 ffmpeg等，進(jìn)行軟解亦或硬解。B、私有解碼，即對(duì)于私有的編碼格式的數(shù)字信息就只能通過(guò)設(shè)備廠家提供對(duì)應(yīng)的解碼庫(kù)進(jìn)行解碼。

S43，將所述監(jiān)控所需路數(shù)的YUV數(shù)據(jù)按照監(jiān)控需求進(jìn)行碼流、圖像質(zhì)量?jī)?yōu)化并將優(yōu)化后的各路YUV數(shù)據(jù)合并處理，生成具有監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)；根據(jù)所述監(jiān)控需求反映的監(jiān)控終端的帶寬狀況控制所述一路YUV數(shù)據(jù)的圖像合成質(zhì)量及傳輸碼流值。所述監(jiān)控需求包括監(jiān)控終端需要監(jiān)控的視頻路數(shù)和所述監(jiān)控終端的網(wǎng)絡(luò)帶寬。

通過(guò)檢測(cè)手機(jī)移動(dòng)終端所在的實(shí)際的網(wǎng)絡(luò)帶寬情況，在多畫(huà)面合成時(shí)，可以利用降低碼率、圖像質(zhì)量等方式進(jìn)行自適應(yīng)傳輸合成后的一路視頻數(shù)據(jù)所需的帶寬，即可以輸出額定帶寬的視頻數(shù)據(jù)。所述步驟S43可以根據(jù)通過(guò)TCP/UDP網(wǎng)絡(luò)交互獲知手機(jī)終端的預(yù)覽路數(shù)進(jìn)行確定的。預(yù)覽幾路監(jiān)控視頻就合成幾畫(huà)面的一路視頻。也是通過(guò)TCP/UDP網(wǎng)絡(luò)交互獲知手機(jī)終端所在網(wǎng)絡(luò)的帶寬狀況，如果帶寬充裕，則合成的圖像質(zhì)量選擇高些，碼流值大些。反之，網(wǎng)絡(luò)帶寬很擁擠時(shí)，則降低合成的圖像質(zhì)量和視頻碼流值。

所述步驟S43對(duì)視頻解碼后得到的YUV數(shù)據(jù)進(jìn)行按監(jiān)控需求進(jìn)行碼流、圖像質(zhì)量?jī)?yōu)化并將優(yōu)化后的各路YUV數(shù)據(jù)合并處理，二次編碼的格式可以選用標(biāo)準(zhǔn)化的編碼協(xié)議，二次編碼的過(guò)程也可選軟編亦或硬編。而且可以按實(shí)際監(jiān)控需求進(jìn)行適配，如，在監(jiān)控兩路實(shí)時(shí)視頻時(shí)，則合并成平行的兩畫(huà)面的一路圖像，如圖3a所示；而在監(jiān)控三路實(shí)時(shí)視頻時(shí)，則合并成三畫(huà)面的一路圖像，如圖3b所示；在監(jiān)控四路實(shí)時(shí)視頻時(shí)，則合并成四畫(huà)面的一路圖像，如圖3c所示；依此類(lèi)推。

S44，將所述監(jiān)控所需路數(shù)畫(huà)面的一路YUV數(shù)據(jù)編碼成可通過(guò)網(wǎng)絡(luò)傳輸?shù)囊宦芬粢曨l數(shù)字信號(hào)。所述步驟S44可以采用軟編碼方式實(shí)現(xiàn)，如主要用ffmpeg等開(kāi)源視頻編解碼庫(kù)即可；也可以采用硬編碼方式實(shí)現(xiàn)，如：可用OPENCV調(diào)用GPU進(jìn)行硬編的方式。

本發(fā)明的目的在于提供一種多路輸入數(shù)字視頻多畫(huà)面合成、輸出額定帶寬的流媒體適配方案，用于解決現(xiàn)有技術(shù)中利用移動(dòng)手機(jī)終端進(jìn)行多路同時(shí)預(yù)覽和回放監(jiān)控視頻時(shí)存在的所需視頻解碼能力和網(wǎng)絡(luò)傳輸帶寬受限的問(wèn)題。采用本發(fā)明所述的流媒體適配器及方法，可以使各類(lèi)型的視頻監(jiān)控設(shè)備均可接入到監(jiān)控系統(tǒng)，并且無(wú)需擔(dān)心手機(jī)終端的解碼能力；在多畫(huà)面監(jiān)控時(shí)，也不用擔(dān)心由于手機(jī)終端的解碼能力不夠而導(dǎo)致手機(jī)終端卡死或觀看視頻卡頓的問(wèn)題。此外，在網(wǎng)絡(luò)帶寬緊張的時(shí)候，也可以令手機(jī)終端進(jìn)行多畫(huà)面的視頻監(jiān)控。

本發(fā)明可以在手機(jī)移動(dòng)終端監(jiān)控多路視頻時(shí)，通過(guò)視頻合成方式，將多路視頻數(shù)據(jù)合成一路再傳輸給手機(jī)移動(dòng)終端上進(jìn)行解碼預(yù)覽，而且不會(huì)再受終端硬件能力的限制導(dǎo)致不能同時(shí)監(jiān)控多路視頻。同時(shí)，在合成視頻時(shí)進(jìn)行降帶寬的處理，達(dá)到了手機(jī)終端所在網(wǎng)絡(luò)環(huán)境的 帶寬傳輸要求。

綜上所述，本發(fā)明有效克服了現(xiàn)有技術(shù)中的種種缺點(diǎn)而具高度產(chǎn)業(yè)利用價(jià)值。

上述實(shí)施例僅例示性說(shuō)明本發(fā)明的原理及其功效，而非用于限制本發(fā)明。任何熟悉此技術(shù)的人士皆可在不違背本發(fā)明的精神及范疇下，對(duì)上述實(shí)施例進(jìn)行修飾或改變。因此，舉凡所屬技術(shù)領(lǐng)域中具有通常知識(shí)者在未脫離本發(fā)明所揭示的精神與技術(shù)思想下所完成的一切等效修飾或改變，仍應(yīng)由本發(fā)明的權(quán)利要求所涵蓋。