本發(fā)明屬于視頻播放技術領域,具體涉及一種多媒體解封裝方法及裝置。
背景技術:
隨著互聯(lián)網技術和多媒體技術的不斷發(fā)展,機頂盒作為多媒體內容展現(xiàn)的重要渠道之一,越來越廣泛應用于家庭和行業(yè)應用,它通過接收有線電纜、衛(wèi)星天線、寬帶網絡以及地面廣播的模擬信號或數(shù)字信號,將多媒體內容呈現(xiàn)在屏幕上,以滿足人們日益增長的影音娛樂需求。其中,機頂盒最重要的用途就是用于音視頻(歌曲、電影)的播放,例如,數(shù)字電視機頂盒用來接收數(shù)字電視信號播放視頻節(jié)目、數(shù)字視聽場所的播放終端用于播放本地或網絡上的音樂歌曲視頻。
由于版權的原因,大部分多媒體視頻通常都是加密的,目前市面上的機頂盒播放器的解密功能還比較簡單,只能支持一些協(xié)議級別的加密和解密,如HTTPS、RTMPS協(xié)議等等,對于文件的自定義加解密處理必須通過針對相應的加密方式進行二次開發(fā)才能實現(xiàn),但這種方式存在不夠通用的問題,若文件加密方式發(fā)生變化,必須重新進行開發(fā)。
同時,在多媒體技術中,存在多種流媒體傳輸協(xié)議(例如,HTTP、RTP、UDP等)以及多種的視頻封裝格式(例如,MP4、FLV、MPEG、AVI等),傳統(tǒng)的機頂盒播放器都是基于具體的多媒體封裝格式進行定制,開發(fā)針對性強,但是在使用過程中面對眾多的多媒體封裝格式時通用性不夠,當機頂盒在需要支持新的平臺和新的格式時,存在開發(fā)效率不高,交付周期長的問題。
技術實現(xiàn)要素:
本發(fā)明的目的之一在于克服以上缺點,提供一種能對音視頻流進行統(tǒng)一解密的多媒體解封裝方法,減少二次開發(fā)的工作量。
為了解決上述技術問題,本發(fā)明提供了一種多媒體解封裝方法,包括以下步驟:
根據(jù)多媒體流的輸入方式獲得多媒體數(shù)據(jù)封裝包;
判斷所述多媒體數(shù)據(jù)封裝包是否有加密;
若有,則對所述多媒體數(shù)據(jù)封裝包先進行解密,然后再解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù);
若沒有,則直接將所述多媒體數(shù)據(jù)封裝包解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,則對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理。
通過在傳統(tǒng)解封裝處理方式的基礎上增加通用的解密處理步驟,可滿足對不同加密類型的多媒體文件進行統(tǒng)一處理,而不需要針對每種新的加密方式,重新定制開發(fā),簡化了二次開發(fā)步驟,提高了開發(fā)效率。
進一步地,所述的多媒體解封裝方法,還包括以下步驟:
將解封裝后的視頻數(shù)據(jù)和一路以上的音頻數(shù)據(jù)通過時間戳進行同步,然后再重新封裝成通用格式的多媒體流。
本發(fā)明的技術方案通過對不同封裝格式的多媒體流進行解封裝處理,分離出原始的視頻數(shù)據(jù)和音頻數(shù)據(jù),再重新封裝成適合播放器處理的統(tǒng)一的通用封裝格式,降低了播放處理對輸入的多媒體流封裝格式的限制,使得后續(xù)的播放處理過程簡單化,從而帶來兼容性和可靠性的提升。
進一步地,所述輸入的多媒體流的來源為本地文件和/或網絡音視頻流,所述多媒體流解密或解封裝前,需進行預處理,具體為:將各種來源的多媒體流以統(tǒng)一的接口輸出。
本發(fā)明的技術方案,可適用于各種不同表現(xiàn)形式的多媒體流,兼容性高,適用范圍廣;同時,不同來源不同協(xié)議的多媒體用統(tǒng)一的接口輸出后,就可以直接解密或解封裝,而不用再考慮協(xié)議接口等內容,簡化處理步驟。
進一步地,所述的多媒體解封裝方法,采用FFmpeg實現(xiàn)多媒體流以統(tǒng)一的接口輸出,通過FFmpeg中的第一級結構體AVIOContext去除多媒體流中的協(xié)議信息。
進一步地,所述步驟“若有,則對所述多媒體數(shù)據(jù)封裝包先進行解密”具體為:通過FFmpeg中自定義的第二級結構體AVIOContext對第一級結構體AVIOContext解封裝的多媒體流進行解密處理。
進一步地,所述步驟“若沒有,則直接將所述多媒體數(shù)據(jù)封裝包解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,則對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理”具體為:通過FFmpeg中自定義的第二結構體AVInputFormat結構體將第一級結構體AVIOContext去除協(xié)議信息的多媒體流進行解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,再利用AVIOContext的統(tǒng)一接口進行解密處理。
相應地,本發(fā)明還提供了一種多媒體解封裝裝置,其特征在于,包括:
第一處理模塊,用于根據(jù)多媒體流的輸入方式獲得多媒體數(shù)據(jù)封裝包;
第二處理模塊,用于判斷所述多媒體數(shù)據(jù)封裝包是否有加密;
第三處理模塊,用于若有,則對所述多媒體數(shù)據(jù)封裝包先進行解密,然后再解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù);
第四處理模塊,用于若沒有,則直接將所述多媒體數(shù)據(jù)封裝包解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,則對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理。
進一步地,所述的多媒體解封裝裝置,還包括:
第五處理模塊,用于將解封裝后的視頻數(shù)據(jù)和一路以上的音頻數(shù)據(jù)通過時間戳進行同步,然后再重新封裝成通用格式的多媒體流。
進一步地,所述輸入的多媒體流的來源為本地文件和/或網絡音視頻流;在所述第一處理模塊與所述第二處理模塊之間,還包括第六處理模塊,用于將各種來源的多媒體流以統(tǒng)一的接口輸出。
進一步地,所述第六處理模塊將各種來源的多媒體流以統(tǒng)一的接口輸出,具體為:采用FFmpeg實現(xiàn)多媒體流以統(tǒng)一的接口輸出,通過FFmpeg中的第一級結構體AVIOContext去除多媒體流中的協(xié)議信息。
進一步地,所述第三處理模塊中“若有,則對所述多媒體數(shù)據(jù)封裝包先進行解密”,具體為:通過FFmpeg中自定義的第二級結構體AVIOContext對第一級結構體AVIOContext解封裝的多媒體流進行解密處理。
進一步地,所述第四處理模塊中“若沒有,則直接將所述多媒體數(shù)據(jù)封裝包解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,則對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理”具體為:通過FFmpeg中自定義的第二結構體AVInputFormat結構體將第一級結構體AVIOContext去除協(xié)議信息的多媒體流進行解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,再利用AVIOContext的統(tǒng)一接口進行解密處理。
相應地,本發(fā)明還提供了一種多媒體解封裝方法的應用,其特征在于:所述多媒體解封裝方法應用于機頂盒中。
通過將本發(fā)明的多媒體解封裝方法應用于機頂盒中,可以實現(xiàn)將不同封裝格式的多媒體文件重新封裝成機頂盒支持的封裝格式,提高機頂盒的兼容性;同時采用通用的解密處理模塊,無需機頂盒再進行定制開發(fā)。
綜上所述,本發(fā)明技術方案的有益效果有:
1.通過在傳統(tǒng)解封裝處理方式的基礎上增加通用的解密處理步驟,可滿足對不同加密類型的多媒體文件進行統(tǒng)一處理,而不需要針對每種新的加密方式,重新定制開發(fā),簡化了二次開發(fā)步驟,提高了開發(fā)效率。
2.通過對不同封裝格式的多媒體流進行解封裝處理,分離出原始的視頻數(shù)據(jù)和音頻數(shù)據(jù),再重新封裝成適合播放器處理的統(tǒng)一的通用封裝格式,降低了播放處理對輸入的多媒體流封裝格式的限制,使得后續(xù)的播放處理過程簡單化,從而帶來兼容性和可靠性的提升。
3.可適用于各種不同表現(xiàn)形式的多媒體流,兼容性高,適用范圍廣。同時,不同來源不同協(xié)議的多媒體用統(tǒng)一的接口輸出后,就可以直接解密或解封裝,而不用再考慮協(xié)議接口等內容,簡化處理步驟。對多媒體流進行處理后的輸出方式,支持直接播放或保存成文件,滿足不同應用場景的需求,適用方式更靈活。
4.通過將本發(fā)明的多媒體解封裝方法應用于機頂盒中,可以實現(xiàn)將不同封裝格式的多媒體文件重新封裝成機頂盒支持的封裝格式,提高機頂盒的兼容性;同時采用通用的解密處理模塊,無需機頂盒再進行定制開發(fā)。
附圖說明
圖1是本發(fā)明的一種多媒體解封裝方法步驟流程圖。
圖2是本發(fā)明的一種多媒體解封裝裝置結構圖。
具體實施方式
下面將結合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本發(fā)明一部分實施例,而不是全部的實施例?;诒景l(fā)明中的實施例,本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
在計算機領域,多媒體(Multimedia)是指兩種或兩種以上媒體組合而成的媒體形式,常使用的多媒體包括文字、圖片、聲音、動畫和視頻等等,而在數(shù)字視聽業(yè)務場景中,最常見的多媒體形式就是電影視頻,電視節(jié)目,這類多媒體主要由音頻和視頻兩部分內容組成,有的還可以包含字幕內容。通常,每個多媒體中的音頻和視頻都有相應的編碼格式,通俗地講編碼方式是指的為了減小視頻和音頻的體積而采用的壓縮算法,不同的編碼方式都有著各自的特點,但最終的目的都是為了盡可能地減小文件大小便于傳輸,同時能保證較高的視頻畫面質量或音頻效果。例如,常見的H264、Xvid等就是視頻編碼格式,MP3、AAC等就是音頻編碼格式。
將已經編碼壓縮好的視頻和音頻按照一定的格式放到一個文件中,形成一個完整的多媒體文件,這種處理稱之為封裝,而封裝的格式也可以稱為容器,不同的封裝格式對應有不同的文件后綴名,例如,常見的多媒體封裝格式有RM、RMVB、AVI、MKV等等。
將多媒體文件進行播放時,通常的處理過程為:先進行解封裝操作,所謂解封裝操作就是從完整的多媒體文件中分離出編碼壓縮好的視頻和音頻,再按照視頻數(shù)據(jù)和音頻數(shù)據(jù)相應的編碼方式進行解碼播放。在復雜的場景中,由于版權的原因,大部分多媒體視頻通常都是加密的,目前市面上的機頂盒的解密功能還比較簡單,只能支持一些協(xié)議級別的加密和解密,如HTTPS、RTMPS協(xié)議等等,對于自定義加密處理的文件必須通過針對相應的加密方式進行二次開發(fā)才能實現(xiàn),但這種方式存在不夠通用的問題,若文件加密方式發(fā)生變化,必須重新進行開發(fā)。
為解決上述問題,本發(fā)明提出了一種多媒體解封裝方法,如圖1,是本發(fā)明的一種多媒體解封裝方法步驟流程圖,包括以下步驟:
步驟1、根據(jù)多媒體流的輸入方式獲得多媒體數(shù)據(jù)封裝包;
在多媒體應用場景中,多媒體流的輸入方式可以有多種形式:輸入的多媒體流可以為本地存儲的文件,例如,在數(shù)字視聽場所(KTV,酒吧)中,機頂盒播放本地存儲的音樂歌曲視頻文件或電影文件;除此之外,輸入的多媒體流還可以是網絡音視頻流,例如,家庭數(shù)字電視播放電視節(jié)目,在線視頻直播,在線視頻點播(VOD)等均屬于通過機頂盒播放網絡多媒體資源,由于目前存在多種數(shù)據(jù)網絡傳輸協(xié)議(如HTTP,RTMP,RTSP等),所以采用不同傳輸協(xié)議的網絡報文格式也不相同。
除此之外,輸入的多媒體流的組成也有多種形式:可以是同時包含視頻和音頻的文件或流數(shù)據(jù),其中,音頻可以是一個以上,例如,在視頻播放時支持切換國語配音或英文配音的視頻文件,就是由一個視頻和兩個不同語言的音頻封裝而成;還可以是視頻和音頻分別存儲的文件或流數(shù)據(jù),同樣,其中的音頻文件也可以有多個,例如數(shù)字院線電影文件的DCP格式就是將電影的視頻和音頻分別存儲,以支持多語言情況下加載不同的音頻,又如KTV中的歌曲資源,可以由一個視頻文件和兩個音頻文件(用于原伴唱切換)組成。
結合上述分析,由于輸入的多媒體流可以是本地存儲的文件,也可以是網絡上獲取的文件,同時從網絡上獲取多媒體流采用的網絡協(xié)議還可能不同;對于不同網絡協(xié)議傳輸?shù)亩嗝襟w流,解析方式也不盡相同。為降低多媒體流解密或解封裝處理的復雜程度,本發(fā)明技術方案的優(yōu)選實施例中,在所述多媒體流解密或解封裝前,可進行統(tǒng)一的預處理,具體為:將各種來源的多媒體流以統(tǒng)一的接口輸出。通過預處理操作,將不同協(xié)議的多媒體流,處理后得到去除協(xié)議信息的完整多媒體流,使得后續(xù)解密或解封裝操作處理無需再關注協(xié)議相關內容。
為實現(xiàn)網絡傳輸數(shù)據(jù)的可靠性,不論采用何種傳輸協(xié)議,常用的方式都是數(shù)據(jù)發(fā)送方將多媒體原始文件拆成固定大小的數(shù)據(jù)塊,再根據(jù)所采用的協(xié)議對每個數(shù)據(jù)塊進行打包,增加相應的控制信息或命令信息發(fā)送給接收端。多媒體流的接收端根據(jù)協(xié)議接收到網絡傳輸?shù)囊恍蛄袛?shù)據(jù)包后,需要將每個數(shù)據(jù)包中的協(xié)議信息去除,獲取原始的多媒體數(shù)據(jù)塊信息,再按照順序將數(shù)據(jù)塊組合成原始的多媒體流,然后進行后續(xù)處理。在這個處理過程中,本地文件由于無需去除協(xié)議信息,可以被當成一種特殊的協(xié)議與網絡多媒體流采用統(tǒng)一的處理方式。
例如,RTMP(Real Time Messaging Protocol,實時消息傳輸協(xié)議)是一種設計用來進行實時數(shù)據(jù)通信的網絡協(xié)議,主要用來在Flash/AIR平臺和支持RTMP協(xié)議的流媒體/交互服務器之間進行音視頻和數(shù)據(jù)通信,在采用RTMP協(xié)議進行多媒體流數(shù)據(jù)傳輸?shù)膱鼍爸校敯l(fā)送端與接收端通過網絡相互發(fā)送握手指令成功連接后,發(fā)送端將發(fā)送RTMP協(xié)議包給接收端,RTMP協(xié)議包都是按照固定大小的包傳輸,包含一個固定長度的包頭和一個最長為128字節(jié)的包體。當接收端接收到每個協(xié)議包后,先發(fā)送響應消息給發(fā)送端表示已經成功接收,同時對RTMP進行拆包,去除固定長度的包頭,得到包體數(shù)據(jù);再按照包頭信息中順序信息將一序列包體數(shù)據(jù)組成完整的多媒體流數(shù)據(jù)。
在本發(fā)明的技術方案的具體實施例中,采用FFmpeg實現(xiàn)多媒體流以統(tǒng)一的接口輸出,通過FFmpeg中輸入輸出數(shù)據(jù)的第一級結構體AVIOContext去除多媒體流中的協(xié)議信息。具體為:采用FFmpeg(一套可以用來記錄、轉換數(shù)字音頻、視頻,并能將其轉化為流的開源計算機程序)來實現(xiàn)對多媒體流的協(xié)議處理。其中,AVIOContext是FFmpeg管理輸入輸出數(shù)據(jù)的結構體,由它來專門處理協(xié)議相關內容,輸入不同協(xié)議的多媒體流,通過AVIOContext該統(tǒng)一接口輸出去除協(xié)議信息的完整多媒體流。AVIOContext將具體協(xié)議處理部分交給URLProtocol,URLProtocol采用無緩沖的直接讀寫I/O的方式,而AVIOContext實現(xiàn)有緩沖的讀寫。
步驟2、判斷所述多媒體數(shù)據(jù)封裝包是否有加密;
現(xiàn)有多媒體技術中,常見的一種加密方式為,對整個多媒體數(shù)據(jù)封裝包進行加密,未經解密處理的多媒體數(shù)據(jù)封裝包是無法進行后續(xù)的解封裝和播放操作。本步驟用于判斷輸入的多媒體數(shù)據(jù)是否將整個多媒體數(shù)據(jù)封裝包進行了加密。
步驟3、若有,則對所述多媒體數(shù)據(jù)封裝包先進行解密,然后再解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù);
若判斷輸入的多媒體數(shù)據(jù)為整個多媒體數(shù)據(jù)封裝包加密,則先根據(jù)相應的解密算法將多媒體數(shù)據(jù)封裝包進行解密。
例如,某個本地多媒體文件采用了DES算法進行了文件加密,在進行后續(xù)的解封裝操作之前,需要調用DES解密算法將文件進行解密。
在具體的實施例中,本發(fā)明的技術方案通過FFmpeg中輸入輸出數(shù)據(jù)的第二級結構體AVIOContext對第一級結構體AVIOContext解封裝的多媒體流進行解密處理。具體為:采用FFmpeg來實現(xiàn)對多媒體流的解密處理,利用AVFormatContext(它是FFmpeg解封裝功能的結構體)可以自定義AVIOContext的特性,采用兩級AVIOContext來實現(xiàn)統(tǒng)一解密功能。其中,第一級的AVIOContext如前文所述負責對輸入的多媒體源進行協(xié)議相關的預處理,得到去除協(xié)議信息的完整多媒體流,此時的多媒體流信息還是處于加密狀態(tài)的;第二級的AVIOContext專門負責對第一級的AVIOContext輸出的多媒體流進行解密處理,根據(jù)多媒體流的加密信息,采用對應的解密算法進行逐幀解密,輸出解密后的多媒體流。通過增加第二級AVIOContext進行統(tǒng)一解密處理的方式,避免了傳統(tǒng)方式下針對一種新的加密形式都需要定制開發(fā),導致效率低開發(fā)周期長的問題。
在輸入的多媒體流數(shù)據(jù)進行去除協(xié)議和解密處理之后,就可以對多媒體流數(shù)據(jù)進行分離操作,提取出封裝在其中的視頻數(shù)據(jù)和音頻數(shù)據(jù),該步驟只是將封裝在某種具體封裝格式(如flv,mp4,rmvb,avi)中的音視頻分離出來,而不對音視頻原有的編碼方式進行處理,同時,如果輸入的多媒體流包含有多個音頻,也會分離出對應數(shù)量的音頻。在采用FFmpeg進行處理的方式下,可通過對AVFormatContext結構體調用av_read_frame()方法進行解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù)。
例如,在一具體的實施例中,一個采用AVI封裝格式的多媒體流,其中視頻采用H.264編碼方式,音頻采用AAC編碼方式,將該多媒體流進行分離后得到一個H.264編碼方式的視頻和AAC編碼方式的音頻。
步驟4、若沒有,則直接將所述多媒體數(shù)據(jù)封裝包解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,則對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理。
若判斷輸入的多媒體數(shù)據(jù)不是對整個多媒體數(shù)據(jù)封裝包進行了加密,則可以直接對多媒體封裝包數(shù)據(jù)進行分離操作,提取出封裝在其中的視頻數(shù)據(jù)和音頻數(shù)據(jù),具體方式為:通過FFmpeg中自定義的第二結構體AVInputFormat結構體將第一級結構體AVIOContext去除協(xié)議信息的多媒體流進行解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,再利用AVIOContext的統(tǒng)一接口進行解密處理。
例如,在電影院播放的電影通常是DCP(Digital Cinema Package數(shù)字院線文件包)封裝格式,它是一種數(shù)字文件集,用于存儲和轉換數(shù)字影像的音頻、圖像和數(shù)據(jù)流,通常包括一個視頻文件和多個不同語言版本的音頻文件,當對這種封裝格式的多媒體進行處理時,本發(fā)明的技術方案會針對每個文件分別進行分離:從視頻文件中分離出視頻數(shù)據(jù),從每個語言版本的音頻文件中分離出對應語言的音頻數(shù)據(jù)。
在一些應用場景中,多媒體流文件采用的加密方式不是前面所述的對整個多媒體數(shù)據(jù)封裝包進行加密,而是對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別加密,再封裝成多媒體文件。在這種情況下,本發(fā)明的技術方案,還需要判斷分離出的視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,如果有加密,則需要對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理;如果沒有加密則不處理。目前常用的加密算法有:AES(Advanced Encryption Standard,高級加密標準),RSA(公鑰加密算法)等等。
上述4個步驟是本發(fā)明技術方案的通用步驟,在一優(yōu)選的實施例中,本發(fā)明的多媒體解封裝方法,還包括以下步驟:步驟5、將解封裝后的視頻數(shù)據(jù)和一路以上的音頻數(shù)據(jù)通過時間戳進行同步,然后再重新封裝成通用格式的多媒體流。
這是由于多媒體技術領域存在著眾多的多媒體封裝格式,而傳統(tǒng)的機頂盒播放器通常都是針對某一種具體的多媒體封裝格式進行定制開發(fā),只能支持該種封裝格式的多媒體文件進行播放,通用性不夠,導致在需要支持新的平臺和新的封裝格式時,開發(fā)效率低,交付周期長。
因此在前述步驟分離出視頻數(shù)據(jù)和音頻數(shù)據(jù)之后,本發(fā)明的技術方案會再將它們封裝成統(tǒng)一的封裝格式,例如,mpegts或mpeg4封裝格式。進一步,本發(fā)明不僅可以對一次解封裝的視頻數(shù)據(jù)和音頻數(shù)據(jù)進行重新封裝,還可以將視頻數(shù)據(jù)與其他文件中的音頻數(shù)據(jù)一起進行重新封裝。例如,對一部電影文件進行解封裝后,得到對應電影文件的視頻數(shù)據(jù)和音頻數(shù)據(jù),由于解封裝的電影文件只有一路音頻數(shù)據(jù),例如,只有中文配音,這時,可以找到該電影視頻對應的英文配音,在重新封裝時,將該電影的視頻數(shù)據(jù)與該電影的英文配音、原有的中文配音一起進行重新封裝,從而實現(xiàn)對一個視頻文件可任意增加視頻數(shù)據(jù)的目的,從而使視頻文件更加完整。
對于不開放獨立音視頻解碼器的平臺,或者對于不支持視頻文件和多個音頻文件分別單獨存儲的封裝格式(例如DCP封裝格式)的平臺,采用重新封裝可以解決多媒體封裝格式不支持的問題,提高兼容性。另外,由于重新封裝過程中可以對音視頻的PTS(Presentation TimeStamp,顯示時間戳)、DTS(Decoding Time Stamp,解碼時間戳)進行修改,從而可以控制音視頻同步。
重新封裝后的多媒體流,可以直接輸出給播放器進行播放,展現(xiàn)視頻內容到屏幕并播放音頻內容,也可以將重新封裝后的多媒體流保存成文件,這種方式通常應用于還要對多媒體流進一步分析處理的場景。例如,在視頻監(jiān)控場景中,前端設備采集的視頻信號可能并不一定需要進行實時播放顯示,則可以進行解封裝操作后重新封裝成適合后續(xù)播放的格式,并保存成文件存儲起來,當后續(xù)有需要的時候,再將所需要播放的文件找出來進行播放。
在一優(yōu)選的實施例中,本發(fā)明的多媒體解封裝方法可以應用于機頂盒中,由于傳統(tǒng)的機頂盒都是基于具體某一種多媒體封裝格式和加密方式進行定制,開發(fā)針對性強但是通用性不夠,在遇到新的多媒體封裝格式和新的加密方式時,存在開發(fā)效率不高,交付周期長的問題。通過將本發(fā)明的多媒體解封裝方法應用于機頂盒中,可以將原先機頂盒無法支持的多媒體封裝格式進行解封裝,再重新封裝成機頂盒支持的封裝格式,以增加兼容性;同時,采用統(tǒng)一的解密方式,也可以減少二次開發(fā)次數(shù),避免了傳統(tǒng)方式下針對一種新的加密形式都需要定制開發(fā),導致效率低開發(fā)周期長的問題。
如圖2,是本發(fā)明的一種多媒體解封裝裝置結構圖,包括:
第一處理模塊,用于根據(jù)多媒體流的輸入方式獲得多媒體數(shù)據(jù)封裝包;輸入的多媒體流的來源可以為本地文件,也可以是網絡音視頻流。
在一優(yōu)選的實施例中,本發(fā)明的多媒體解封裝裝置,還可以設置第六處理模塊,用于將第一處理模塊獲取的各種來源的多媒體流以統(tǒng)一的接口輸出,根據(jù)多媒體流屬于本地文件還是網絡資源,以及網絡資源采用何種的網絡傳輸協(xié)議,進行相應預處理,獲取到完整的多媒體數(shù)據(jù)封裝包。具體處理方式為:采用FFmpeg實現(xiàn)多媒體流以統(tǒng)一的接口輸出,通過FFmpeg中輸入輸出數(shù)據(jù)的第一級結構體AVIOContext去除多媒體流中的協(xié)議信息。在這一級的AVIOContext處理過程中,只需關心輸入的多媒體流輸入輸出方式、協(xié)議,而不用關心多媒體流是否加密,封裝格式等等。
第二處理模塊,用于判斷輸入的多媒體流是否為多媒體數(shù)據(jù)封裝包加密方式。
第三處理模塊,若輸入的多媒體流是多媒體數(shù)據(jù)封裝包加密方式,本模塊對所述多媒體數(shù)據(jù)封裝包先進行解密,然后再解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù);
其中,對所述多媒體數(shù)據(jù)封裝包先進行解密,本發(fā)明采用的方式為:利用FFmpeg中解封裝功能的結構體AVFormatContext可以自定義AVIOContext的特性,采用增加第二級AVIOContext來實現(xiàn)統(tǒng)一解密功能,第二級的AVIOContext專門負責對前文所述第一級的AVIOContext輸出的多媒體流進行解密處理,根據(jù)多媒體流的加密信息,采用對應的解密算法進行逐幀解密,輸出解密后的多媒體流;解密后的解封裝步驟只是將封裝在某種具體封裝格式(如flv,mp4,rmvb,avi)中的音視頻分離出來,而不對音視頻原有的編碼方式進行處理。
第四處理模塊,若輸入的多媒體流不是多媒體數(shù)據(jù)封裝包加密方式,本模塊直接將多媒體數(shù)據(jù)封裝包解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷多媒體流是否為視頻數(shù)據(jù)和音頻數(shù)據(jù)單獨分別加密方式,若是,則對視頻數(shù)據(jù)和音頻數(shù)據(jù)分別進行解密處理。具體方式為:通過FFmpeg中自定義的第二結構體AVInputFormat結構體將第一級結構體AVIOContext去除協(xié)議信息的多媒體流進行解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,再利用AVIOContext的統(tǒng)一接口進行解密處理。
第五處理模塊,用于將解封裝后的視頻數(shù)據(jù)和一路以上的音頻數(shù)據(jù)通過時間戳進行同步,然后再重新封裝成通用格式的多媒體流,減少了播放處理對輸入的多媒體流封裝格式的限制,使得后續(xù)的播放處理過程簡單化,從而帶來兼容性和可靠性的提升,并提供標準的音視頻同步方法。
重新封裝后的多媒體流可以直接進行播放,或者保存成文件存儲起來,當后續(xù)有需要的時候,再將所需要播放的文件找出來進行播放。在具體的實施例中,本發(fā)明的多媒體解封裝裝置可以為機頂盒,也可以為智能設備,如手機,平板設備等等。以用戶通過機頂盒點播網絡視頻或播放本地多媒體文件為例,各個模塊實現(xiàn)功能如下:
第一處理模塊,用戶點播網絡視頻的時候,通過廣電有線網絡接收用戶點播的多媒體流;當用戶播放本地多媒體文件時候,本模塊負責通過文件接口加載本地多媒體文件,這里的本地多媒體文件可以為同時包含視頻和音頻的文件,也可以為視頻和音頻分別存儲的文件。
第六處理模塊,采用FFmpeg實現(xiàn)多媒體流以統(tǒng)一的接口輸出,通過FFmpeg中輸入輸出數(shù)據(jù)的第一級結構體AVIOContext去除多媒體流中的協(xié)議信息,根據(jù)協(xié)議接收到網絡傳輸?shù)囊恍蛄袛?shù)據(jù)包后,將每個數(shù)據(jù)包中的協(xié)議信息去除,獲取原始的多媒體數(shù)據(jù)塊信息,再按照順序將數(shù)據(jù)塊組合成原始的多媒體流。
第二處理模塊,判斷點播的多媒體數(shù)據(jù)或本地多媒體文件是否多媒體數(shù)據(jù)封裝包加密方式。
第三處理模塊,若點播的多媒體數(shù)據(jù)或本地多媒體文件為多媒體數(shù)據(jù)封裝包加密方式,則先通過FFmpeg中輸入輸出數(shù)據(jù)的第二級的AVIOContext對第一級的AVIOContext輸出的多媒體流進行解密后,再將多媒體數(shù)據(jù)封裝包進行分離操作,提取出封裝在其中的視頻數(shù)據(jù)和音頻數(shù)據(jù),不對音視頻原有的編碼方式進行處理。
第四處理模塊,若點播的多媒體數(shù)據(jù)或本地多媒體文件不是多媒體數(shù)據(jù)封裝包加密方式,則通過FFmpeg中自定義的第二結構體AVInputFormat結構體將第一級結構體AVIOContext去除協(xié)議信息的多媒體流進行解封裝得到視頻數(shù)據(jù)和音頻數(shù)據(jù),再判斷視頻數(shù)據(jù)和音頻數(shù)據(jù)是否有加密,若有,再利用AVIOContext的統(tǒng)一接口進行解密處理。
第五處理模塊,用于將視頻數(shù)據(jù)和所述音頻數(shù)據(jù)重新封裝成適合本機頂盒播放的統(tǒng)一封裝格式(MPEG4),并輸出給播放模塊,由播放模塊將視頻數(shù)據(jù)顯示到屏幕并播放音頻數(shù)據(jù)。
上述具體實施方式只是對本發(fā)明的技術方案進行詳細解釋,本發(fā)明并不只僅僅局限于上述實施例,凡是依據(jù)本發(fā)明原理的任何改進或替換,均應在本發(fā)明的保護范圍之內。