監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法及裝置制造方法
【專利摘要】本發(fā)明公開了監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，包括步驟：S1、檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求；S2、當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則執(zhí)行步驟S4，若否，則執(zhí)行步驟S3；S3、創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后執(zhí)行步驟S4；S4、把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后執(zhí)行步驟S5；S5、循環(huán)遍歷視頻流發(fā)送地址列表，通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。本發(fā)明還提供監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置。其有益效果是：實現(xiàn)視頻流一次數(shù)據(jù)處理多地址發(fā)送，降低了處理視頻流數(shù)據(jù)對硬件資源的占用。
【專利說明】監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法及裝置
【技術(shù)領域】
[0001]本發(fā)明涉及安防監(jiān)控領域，尤其涉及一種監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法及裝置。
【背景技術(shù)】
[0002]隨著安防監(jiān)控產(chǎn)品的網(wǎng)絡化、高清化和智能化，監(jiān)控設備負載無疑會愈來愈大，這主要體現(xiàn)在實時視頻流的消耗。當設備處于高負載的工作狀態(tài)時，經(jīng)常會遇到下列情況:設備反應慢，網(wǎng)頁參數(shù)不能正常顯示和設置；實時視頻卡頓，花屏，丟幀或請求不成功；智能分析不能正常進行。然而，由于監(jiān)控設備功能不斷復雜化的發(fā)展，僅靠單純地提升硬件性能來克服上述缺陷來以滿足客戶需求顯然是不現(xiàn)實的。
[0003]考慮到視頻流的資源消耗大，故通過減少視頻流的資源消耗對系統(tǒng)性能提升無疑更加直接和高效。
[0004]流媒體協(xié)議作為流傳輸協(xié)議，廣泛應用于各種監(jiān)控場所。流媒體協(xié)議主要包含三類協(xié)議，即 RTSP 協(xié)議(Real-Time Steaming Potocoal), RTP 協(xié)議(Real-Time TransportPotocoal)和 RTCP協(xié)議(Real-Time Transport Control Potocoal)。RTSP協(xié)議用于信令交互，控制視頻流的請求與斷開，支持TCP IUDP I Http協(xié)議傳輸，RTP協(xié)議用于數(shù)據(jù)傳輸，RTCP協(xié)議用于流量控制。
[0005]由于視頻流的數(shù)據(jù)量大和網(wǎng)絡鏈路的MTU的限制，視頻幀在發(fā)送之前須拆分來滿足MTU的要求，然后經(jīng)RTP協(xié)議承載發(fā)送至目標地址。當多路連接(RTSP overTCP IUDP I Http)請求同一視頻流時，現(xiàn)有的處理方法為:為每路連接分別創(chuàng)建一條發(fā)送線程，線程函數(shù)中分別進行數(shù)據(jù)處理和拆分，然后打包為RTP協(xié)議包發(fā)送至目標地址。由于一路視頻連接線程處理(數(shù)據(jù)處理，拆分及RTP協(xié)議封包)資源消耗大，而多路連接又相互獨立，導致資源消耗隨對同一視頻流請求量的增加而呈線性增長，使系統(tǒng)性能急劇下降。

【發(fā)明內(nèi)容】

[0006]本發(fā)明主要解決的技術(shù)問題是提供一種監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法及裝置，適用于數(shù)據(jù)量大，同時連接的路數(shù)較多的前端監(jiān)控設備，可在現(xiàn)有的硬件條件下流暢地實現(xiàn)多個設備對同一視頻流的請求。
[0007]本發(fā)明采用的一個技術(shù)方案是:提供一種監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，包括步驟:
[0008]S1、檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求；
[0009]S2、當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則執(zhí)行步驟S4，若否，則執(zhí)行步驟S3 ；
[0010]S3、創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后執(zhí)行步驟S4 ；
[0011]S4、把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后執(zhí)行步驟S5 ；[0012]S5、循環(huán)遍歷視頻流發(fā)送地址列表，通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。
[0013]本發(fā)明采用的另一個技術(shù)方案是:提供一種監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置，包括:
[0014]檢測模塊，用于檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求；
[0015]判斷模塊，用于當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則通知地址添加模塊執(zhí)行操作，若否，則通知線程創(chuàng)建模塊執(zhí)行操作；
[0016]線程創(chuàng)建模塊，用于創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后通知地址添加模塊執(zhí)行操作；
[0017]地址添加模塊，用于把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后通知視頻流發(fā)送模塊執(zhí)行操作；
[0018]視頻流發(fā)送模塊，用于循環(huán)遍歷視頻流發(fā)送地址列表并通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。
[0019]本發(fā)明的有益效果是:本發(fā)明通過改變視頻流的連接處理流程，把共性的邏輯處理提取出來，即每路視頻流對應一個發(fā)送線程負責視頻流數(shù)據(jù)的處理并發(fā)送至不同的目標地址，這樣每增加一個對已被請求的視頻流的連接，只是將已處理過的視頻流數(shù)據(jù)多發(fā)送至一個目標地址，資源消耗不會線性增長，視頻流數(shù)據(jù)的處理、拆包在同一個發(fā)送線程中復用，從而實現(xiàn)一次數(shù)據(jù)處理，多連接地址發(fā)送的目的，顯著降低了視頻流數(shù)據(jù)的處理對硬件資源的占用，有利于降低對硬件的要求。
【專利附圖】

【附圖說明】
[0020]圖1是本發(fā)明的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置的一個實施方式的結(jié)構(gòu)框圖；
[0021]圖2是本發(fā)明的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法的一個實施方式的主要執(zhí)行流程圖。
[0022]主要元件符號說明:
[0023]100、分發(fā)裝置；10、檢測模塊；20、判斷模塊；30、線程創(chuàng)建模塊；40、地址添加模塊；50、視頻流發(fā)送模塊。
【具體實施方式】
[0024]為詳細說明本發(fā)明的技術(shù)內(nèi)容、構(gòu)造特征、所實現(xiàn)目的及效果，以下結(jié)合實施方式并配合附圖詳予說明。
[0025]請參閱圖1，本實施方式為一種監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置100，包括:檢測模塊10、判斷模塊20、線程創(chuàng)建模塊30、地址添加模塊40和視頻流發(fā)送模塊50。
[0026]所述檢測模塊10用于檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求。
[0027]所述判斷模塊20用于當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則通知地址添加模塊40執(zhí)行操作，若否，則通知線程創(chuàng)建模塊30執(zhí)行操作。[0028]線程創(chuàng)建模塊30，用于創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后通知地址添加模塊40執(zhí)行操作。
[0029]地址添加模塊40，用于把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后通知視頻流發(fā)送模塊50執(zhí)行操作。
[0030]所述視頻流發(fā)送模塊50用于循環(huán)遍歷視頻流發(fā)送地址列表并通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。
[0031]其中，所述檢測模塊10具體包括:服務創(chuàng)建單元、檢測單元、第一線程創(chuàng)建單元、接收單元、協(xié)議判斷單元和第二線程創(chuàng)建單元。
[0032]所述服務創(chuàng)建單元用于創(chuàng)建以TCP協(xié)議承載的RTSP協(xié)議連接服務。
[0033]所述檢測單元用于檢測是否有客戶端進行RTSP協(xié)議連接請求。
[0034]所述第一線程創(chuàng)建單元用于當檢測到客戶端的RTSP協(xié)議連接請求時，創(chuàng)建第一通信線程執(zhí)行前端監(jiān)控設備與客戶端的RTSP協(xié)議命令交互。
[0035]所述接收單元用于通過第一通信線程接收客戶端發(fā)送的視頻流播放請求和通信參數(shù)，所述通信參數(shù)包括傳輸協(xié)議類型、RTP和RTCP的端口和標識參數(shù)、超時時間參數(shù)。其中，傳輸協(xié)議類型包括m)P、TCP或HTTP ；當傳輸協(xié)議為UDP時標識參數(shù)標識為RTP，端口參數(shù)為RTP的IP地址的端口，當傳輸協(xié)議為TCP或HTTP時標識參數(shù)標識為RTCP，端口參數(shù)為RTCP的IP地址的端口號；超時時間參數(shù)為未收到RTSP的GET_PARAMETER信令或RTCP命令的時間間隔值，在這個時間間隔到達后，RTSP斷開連接。
[0036]所述協(xié)議判斷單元用于判斷視頻流的傳輸協(xié)議類型，若傳輸協(xié)議類型為UDP協(xié)議，則通知第二線程創(chuàng)建單元執(zhí)行操作，若傳輸協(xié)議類型為TCP協(xié)議或HTTP協(xié)議，則通知所述判斷模塊20執(zhí)行操作。
[0037]所述第二線程創(chuàng)建單元用于創(chuàng)建第二通信線程執(zhí)行RTCP協(xié)議的通信，然后通知所述判斷模塊20執(zhí)行操作。
[0038]其中，所述線程創(chuàng)建模塊30具體包括:第三線程創(chuàng)建單元、獲取單元、拆分單元和封裝單元。
[0039]所述第三線程創(chuàng)建單元用于創(chuàng)建發(fā)送線程。
[0040]所述獲取單元用于通過發(fā)送線程獲取視頻流數(shù)據(jù)。
[0041]所述拆分單元用于對所獲取的視頻流數(shù)據(jù)中的視頻幀進行拆分。
[0042]所述封裝單元用于將拆分后的視頻流數(shù)據(jù)采用RTP協(xié)議封裝，生成視頻流數(shù)據(jù)包。
[0043]本分發(fā)裝置100的工作原理為，當前端的視頻采集監(jiān)控設備收到后端的新客戶端的視頻流連接請求時，分發(fā)裝置100會先查看該視頻流是否已被建立發(fā)送線程并處于視頻流數(shù)據(jù)包發(fā)送狀態(tài)，若是，則復用該發(fā)送線程將視頻流數(shù)據(jù)包發(fā)送到該新客戶端；若未連接，則創(chuàng)建新的發(fā)送線程進行數(shù)據(jù)處理后發(fā)送視頻流數(shù)據(jù)包。比起傳統(tǒng)設備的處理方式，使用本裝置后每增加一路對同一視頻流的連接請求，僅增加了 RTSPlRTCP的通信及網(wǎng)絡數(shù)據(jù)發(fā)送的資源消耗，不會增加系統(tǒng)重復處理相同視頻流帶來的負荷，使對視頻流的數(shù)據(jù)處理的效率顯著提高。并且，由于本裝置對同一視頻流的請求只進行一次數(shù)據(jù)處理，在處理數(shù)據(jù)時不必對數(shù)據(jù)緩沖區(qū)進行加鎖，避免多個發(fā)送線程同時處理數(shù)據(jù)時共享數(shù)據(jù)緩沖區(qū)對數(shù)據(jù)緩沖區(qū)的反復加鎖，進一步提高了對視頻流數(shù)據(jù)處理的效率。[0044]以下是采用本裝置的前端槍機和傳統(tǒng)槍機的視頻流發(fā)送性能比對:
[0045]傳統(tǒng)設備通過RTSP over UDP連接三路8M碼流，CPU剩余為0%，后端的客戶端在查看視頻時會出現(xiàn)花屏和丟幀現(xiàn)象；
[0046]帶有本裝置的設備通過RTSP over UDP連接三路8M碼流，CPU的剩余為24%，后端的客戶端在查看視頻時碼流流暢，無卡頓現(xiàn)象。
[0047]請參閱圖2，本實施方式為一種監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，包括步驟:
[0048]S1、檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求；
[0049]S2、當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則執(zhí)行步驟S4，若否，則執(zhí)行步驟S3 ；
[0050]S3、創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后執(zhí)行步驟S4 ；
[0051]S4、把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后執(zhí)行步驟S5 ；
[0052]S5、循環(huán)遍歷視頻流發(fā)送地址列表，通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。
[0053]其中，所述步驟SI具體包括:
[0054]S11、創(chuàng)建以TCP協(xié)議承載的RTSP協(xié)議連接服務；
[0055]S12、檢測是否有客戶端進行RTSP協(xié)議連接請求；
[0056]S13、當檢測到客戶端的RTSP協(xié)議連接請求時，創(chuàng)建第一通信線程執(zhí)行前端監(jiān)控設備與客戶端的RTSP協(xié)議命令交互；
[0057]S13、通過第一通信線程接收客戶端發(fā)送的視頻流播放請求和通信參數(shù)，所述通信參數(shù)包括傳輸協(xié)議類型；
[0058]S14、判斷視頻流的傳輸協(xié)議類型，若傳輸協(xié)議類型為UDP協(xié)議，則執(zhí)行步驟S15，若傳輸協(xié)議類型為TCP協(xié)議或HTTP協(xié)議，則執(zhí)行步驟S2 ；
[0059]S15、創(chuàng)建第二通信線程執(zhí)行RTCP協(xié)議的通信，然后執(zhí)行步驟S2。
[0060]其中，所述步驟S3具體包括:
[0061]S31、創(chuàng)建發(fā)送線程；
[0062]S32、通過發(fā)送線程獲取視頻流數(shù)據(jù)；
[0063]S33、對所獲取的視頻流數(shù)據(jù)中的視頻幀進行拆分；
[0064]S34、將拆分后的視頻流數(shù)據(jù)采用RTP協(xié)議封裝，生成視頻流數(shù)據(jù)包。
[0065]本發(fā)明的有益效果是:本發(fā)明通過改變視頻流的連接處理流程，把共性的邏輯處理提取出來，即每路視頻流對應一個發(fā)送線程負責視頻流數(shù)據(jù)的處理并發(fā)送至不同的目標地址，這樣每增加一個對已被請求的視頻流的連接，只是將已處理過的視頻流數(shù)據(jù)多發(fā)送至一個目標地址，資源消耗不會線性增長，視頻流數(shù)據(jù)的處理、拆包在同一個發(fā)送線程中復用，從而實現(xiàn)一次數(shù)據(jù)處理，多連接地址發(fā)送的目的，顯著降低了視頻流數(shù)據(jù)的處理對硬件資源的占用，有利于降低對硬件的要求。
[0066]以上所述僅為本發(fā)明的實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運用在其他相關(guān)的【技術(shù)領域】，均同理包括在本發(fā)明的專利保護范圍內(nèi)。
【權(quán)利要求】
1.監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，其特征在于，包括步驟: 51、檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求； 52、當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則執(zhí)行步驟S4，若否，則執(zhí)行步驟S3 ； 53、創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后執(zhí)行步驟S4； 54、把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后執(zhí)行步驟S5 ； 55、循環(huán)遍歷視頻流發(fā)送地址列表，通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。
2.根據(jù)權(quán)利要求1所述的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，其特征在于，所述步驟SI具體包括: SI 1、創(chuàng)建以TCP協(xié)議承載的RTSP協(xié)議連接服務； 512、檢測是否有客戶端進行RTSP協(xié)議連接請求； 513、當檢測到客戶端的RTSP協(xié)議連接請求時，創(chuàng)建第一通信線程執(zhí)行前端監(jiān)控設備與客戶端的RTSP協(xié)議命令交互； 513、通過第一通信線程接收客戶端發(fā)送的視頻流播放請求和通信參數(shù)，所述通信參數(shù)包括傳輸協(xié)議類型； 514、判斷視頻流的傳輸協(xié)議類型，若傳輸協(xié)議類型為UDP協(xié)議，則執(zhí)行步驟S15，若傳輸協(xié)議類型為TCP協(xié)議或HTTP協(xié)議，則執(zhí)行步驟S2 ； 515、創(chuàng)建第二通信線程執(zhí)行RTCP協(xié)議的通信，然后執(zhí)行步驟S2。
3.根據(jù)權(quán)利要求2所述的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，其特征在于，所述通信參數(shù)還包括RTP和RTCP的端口和標識參數(shù)、超時時間參數(shù)。
4.根據(jù)權(quán)利要求1所述的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)方法，其特征在于，所述步驟S3具體包括: 531、創(chuàng)建發(fā)送線程； 532、通過發(fā)送線程獲取視頻流數(shù)據(jù)； 533、對所獲取的視頻流數(shù)據(jù)中的視頻幀進行拆分； 534、將拆分后的視頻流數(shù)據(jù)采用RTP協(xié)議封裝，生成視頻流數(shù)據(jù)包。
5.監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置，其特征在于，包括: 檢測模塊，用于檢測是否有來自客戶端的包含客戶端地址的視頻流播放請求； 判斷模塊，用于當檢測到視頻流播放請求時，判斷所請求的視頻流是否已被請求過并且已創(chuàng)建發(fā)送線程，若是，則通知地址添加模塊執(zhí)行操作，若否，則通知線程創(chuàng)建模塊執(zhí)行操作； 線程創(chuàng)建模塊，用于創(chuàng)建發(fā)送線程，通過發(fā)送線程生成視頻流數(shù)據(jù)包，然后通知地址添加模塊執(zhí)行操作； 地址添加模塊，用于把視頻流播放請求中的客戶端地址添加至視頻流發(fā)送地址列表中，然后通知視頻流發(fā)送模塊執(zhí)行操作； 視頻流發(fā)送模塊，用于循環(huán)遍歷視頻流發(fā)送地址列表并通過發(fā)送線程向該列表中的地址發(fā)送視頻流數(shù)據(jù)包。
6.根據(jù)權(quán)利要求5所述的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置，其特征在于，所述檢測模塊具體包括: 服務創(chuàng)建單元，用于創(chuàng)建以TCP協(xié)議承載的RTSP協(xié)議連接服務； 檢測單元，用于檢測是否有客戶端進行RTSP協(xié)議連接請求； 第一線程創(chuàng)建單元，用于當檢測到客戶端的RTSP協(xié)議連接請求時，創(chuàng)建第一通信線程執(zhí)行前端監(jiān)控設備與客戶端的RTSP協(xié)議命令交互； 接收單元，用于通過第一通信線程接收客戶端發(fā)送的視頻流播放請求和通信參數(shù)，所述通信參數(shù)包括傳輸協(xié)議類型； 協(xié)議判斷單元，用于判斷視頻流的傳輸協(xié)議類型，若傳輸協(xié)議類型為UDP協(xié)議，則通知第二線程創(chuàng)建單元執(zhí)行操作，若傳輸協(xié)議類型為TCP協(xié)議或HTTP協(xié)議，則通知所述判斷模塊執(zhí)行操作； 第二線程創(chuàng)建單元，用于創(chuàng)建第二通信線程執(zhí)行RTCP協(xié)議的通信，然后通知所述判斷模塊執(zhí)行操作。
7.根據(jù)權(quán)利要求6所述的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置，其特征在于，所述通信參數(shù)還包括RTP參數(shù)、RTCP端口 /標識參數(shù)和超時時間參數(shù)。
8.根據(jù)權(quán)利要求5所述的監(jiān)控設備的視頻流數(shù)據(jù)分發(fā)裝置，其特征在于，所述線程創(chuàng)建模塊具體包括: 第三線程創(chuàng)建單元，用于創(chuàng)建發(fā)送線程； 獲取單元，用于通過發(fā)送線程獲取視頻流數(shù)據(jù)； 拆分單元，用于對所獲取的視頻流數(shù)據(jù)中的視頻幀進行拆分； 封裝單元，用于將拆分后的視頻流數(shù)據(jù)采用RTP協(xié)議封裝，生成視頻流數(shù)據(jù)包。
【文檔編號】H04N7/18GK103731641SQ201410016460
【公開日】2014年4月16日 申請日期:2014年1月14日 優(yōu)先權(quán)日:2014年1月14日
【發(fā)明者】彭大永 申請人:深圳英飛拓科技股份有限公司