1006大設(shè)計翻譯版

H.264streamStorageand Formeetingneedsofanorganizationproject,SystemArchitectureLabofBeihangUniversitycontractedto“HDVGAsignalacquisitionstorageandplaybacksystem“researchanddevelopmentproject.Thisprojectinvolvesanumberofkeytechnologies,including"VGAtranscoding","H.264streamtransmissionandstorage","packagetotheMKVfile","buildmultimediamonitorrecordingserver".Thispaperisasubprojectof"HDVGAsignalacquisitionstorageandplaybacksystem"project,mainlydevelotwoissueabove,"H.264streamtransmissionandstorage"and"packagetotheMKVfile".PaperwillstartfromtheH.264encodingstandard,throughtheysisofcodingtheoryandlearninganumberofkeyproblemsincodingtolearnthemethodofreadingandysisH.264streams,especiallythemethodofysisNALU.Andalso,paperwilllearnaboutExtensibleBinaryMarkupLanguage(EBML)thatcoulddescribeextensionframework.ByyzingstandardMKVfile,wecanunderstandthestandardofpackingandcharacteristicsofcontainerandbasicallymasterthesignificanceofelementswhichconsistMKVfile.FinallythisprojectwilluseC++programminglanguagetobuildthissystemandcondueriesoftests.：H.264,NAL,MKV,EBML,緒 選題背景及研究意 國內(nèi)外研究現(xiàn)狀及發(fā)展動 1.2.1壓縮編 1.2.2封裝格 的研究內(nèi)容及相關(guān)技 H.264編碼原 結(jié) 系統(tǒng)需求和總體設(shè) 功能需 性能需 總體設(shè) 系統(tǒng)組 設(shè)備選 技術(shù)選 小 系統(tǒng)實現(xiàn)中的..........................................................................................3.1壓縮編碼標(biāo)準(zhǔn)—— H.264中的基本概 H.264碼流詳細(xì)分 EBML示例分 vint類介 MKV文件格 小 系統(tǒng)實 碼流錄制接收 碼流封裝部 重要的數(shù)據(jù)結(jié) 類和主要流 小 系統(tǒng)測 功能測 測試環(huán) 測試過 結(jié)果分 性能測 畫面質(zhì)量分 封裝速率分 小 總結(jié)與展 工作總 工作展 致 參考文 圖圖1.1VGA信號系 圖1.2研究內(nèi)容及相關(guān)技術(shù)結(jié)構(gòu) 圖2.1多VGA錄播系 圖2.2/VGA編...................................................................................圖3.1vint類與其他主要類關(guān)系 圖3.2MKV分層結(jié)構(gòu)示意 圖3.3EBML層次結(jié)構(gòu) 圖3.4Cluster結(jié)構(gòu)層次 圖3.5Cluster數(shù)據(jù)解析示意 圖3.6CueingData部分結(jié)構(gòu)層次 圖3.7MKV有無Cues部分效果對比 圖3.8CuePoint解析示意 圖4.1碼流錄制端程序界 圖4.2h264buf操作示意 圖4.3MKV生成流程 圖5.1系統(tǒng)初始化截 圖5.2系統(tǒng)運行截 圖5.3碼流封裝過程截 圖5.4MKV效果截 圖5.5原屏幕截 圖5.6VGA編碼后屏幕截 圖5.7封裝為MKV后效果截 圖5.8有無關(guān)鍵幀索引效果對比 圖5.9封裝時程序CPU占用 表表1.1MKV結(jié)構(gòu)層次 表2.1多錄播服務(wù)器技術(shù)規(guī)格 表2.2VGA編主要參數(shù) 表3.1NALU單元頭格 表3.2H.264建議規(guī)定的NALU類 表3.30階無符號整數(shù)指數(shù)編碼 表3.4Vint類型數(shù)表示 表3.5EBMLHeader屬性 表3.6vint類定義成員屬性 表3.7MKVEBMLHeader元素意義 表3.8MKVSegmentHeader元素結(jié)構(gòu) 表4.1MKV_HANDLE類屬性 表4.2cluster類屬性 表5.1功能性測試環(huán)境配置 表5.2MKV文件封裝速率對比 緒本章將主要介紹《H.264碼流的與封裝》的選題背景與研究意義，并列舉選題背景及研究意義與應(yīng)某單位工程項目需求，航空航天大學(xué)系統(tǒng)結(jié)構(gòu)承制“VGA與 網(wǎng)絡(luò)千兆自適應(yīng)交換 ...... 可選顯 網(wǎng)絡(luò)千兆自適應(yīng)交換 ...... 可選顯示圖1.1VGA信號系本主要研究的系統(tǒng)結(jié)構(gòu)如圖1.1所示，分為三個部分內(nèi)容?！扒岸薖C機”部分中還包含有“VGA編”，VGA的作用是將目標(biāo)機輸出的VGA信號編碼為適應(yīng)不同需求的高低清H.264碼流，項目要求最少支持同時對8路VGA信號進行，同時，將的信號錄制為MKV文件格式在服務(wù)器上，供隨時調(diào)用。服務(wù)器最大能夠支持同時對16路信號進行。服務(wù)器得到的輸入信號為可選清晰度的H.264碼流。當(dāng)對8路信號同時時，不需要過晰度，但是對流暢度有要求，這時服務(wù)器從VGA編處請求到的即為低清H.264碼流；當(dāng)需要錄制以供后續(xù)調(diào)取時，服務(wù)器從VGA編處請求的即為H.264碼流信號，用于封裝。另外，服務(wù)器還支持可選顯示器，在系統(tǒng)進行調(diào)試和時，可直接外接顯示器和輸入設(shè)備在服務(wù)器上行操作，便于服務(wù)器的日常管理第三部分為“網(wǎng)絡(luò)千兆自適應(yīng)交換機”。交換機是整個的中心。VGA的中心，為系統(tǒng)擴展提供了條件。交換機提16100/1000M自適應(yīng)端口，所有端口都能夠自動適應(yīng)網(wǎng)絡(luò)速率，既可以在100M速率進行工作，也可以在1000M速率進行本系統(tǒng)中主要涉及的壓縮編碼為H.264編碼，涉及到的格式為MKV文件格式。壓縮標(biāo)準(zhǔn)采用目前最先進的H.264HighProfile標(biāo)準(zhǔn)[1]，此標(biāo)準(zhǔn)的主要目Matroska的一種文件，是一種新的多封裝格式，也稱為多容器(MultimediaContainer)。MKV支持可變幀率的編碼，在靜態(tài)畫面中使用較小的幀率，這樣可以組成系統(tǒng)的硬件和軟件采用標(biāo)準(zhǔn)化、模塊化和系統(tǒng)化設(shè)計，更加便于系統(tǒng)的測國內(nèi)外研究現(xiàn)狀及發(fā)展動態(tài)的原因。并通過對比不同的封裝格式，來說明MKV文件格式的比較優(yōu)勢。壓縮編碼H.261是1990年ITU-T制定的一個編碼標(biāo)準(zhǔn)，是第一個實用的數(shù)字編碼標(biāo)準(zhǔn)2]。其設(shè)計的目的是能夠在帶寬為64kbps的倍數(shù)的綜合業(yè)務(wù)數(shù)字網(wǎng)(ISDNforIntegratedServicesDigitalNetwork)上傳輸質(zhì)量可接受的信號。H.261使用幀間預(yù)測（2）MPEG- MPEG-2是MPEG工作組于1994年發(fā)布的和音頻壓縮國際標(biāo)準(zhǔn)[3]MPEG-2通常用來為廣播信號提供和音頻編碼，包括電視、有線電視等。MPEG-2經(jīng)過少量修改后，也成為DVD產(chǎn)品的技術(shù)。MPEG-2圖像壓縮的原理是利用了圖像中的兩種特性：空間相關(guān)性和時間相關(guān)性。量非相關(guān)信息進行傳輸，就可以傳輸頻帶。而利用這些非相關(guān)信息，按照一定的算法，可以在保證一定的圖像質(zhì)量的前提下恢復(fù)原始圖像。MPEG-2的編碼碼流分為六個層次。為更好地表示編碼數(shù)據(jù)，MPEG-2用句定了一個層次性結(jié)構(gòu)。它分為六層，從上至下依次為：串行層（Sequence圖像組層Picture（Picture（Slice（BlockH.263是由ITU-T制定的會議用的低碼率編碼標(biāo)準(zhǔn)，屬于編器[4]。基于之前的編碼國際標(biāo)準(zhǔn)（H.261，MPEG-1和H.262／MPEG-2，H.263的性能有置成更低的數(shù)據(jù)率或更好的糾錯能力；(3)H.263包含四個可協(xié)商的選項以改善性能；H.263采用運動編碼中常見的編碼方法，將編碼過程分為幀內(nèi)編碼和幀間編碼兩個部分。IDCT1/2象素運動矢量預(yù)測補（4）MPEG-H.264MPEG-4標(biāo)準(zhǔn)里的第10章（part10）MPEG-4H.264MPEG-4包含了MPEG-1MPEG-2的絕大部份功能及其他格加入及MPEG-4MPEG-2更先進的其中一個特點，就是不再使用宏區(qū)塊做圖像分H.264比起以前的編能夠帶來性能上顯著的提高，并在各種不同的環(huán)境下達成更廣泛的應(yīng)用。H.264MPEG-2有很大的提高，在相同的圖像質(zhì)提供優(yōu)質(zhì)。封裝格式AVI格式，英文全稱為 Interleaved，即音頻交錯格式[5]。是將語DVD相并稱。但它的缺點也是十分明顯的：體積大。與MPEG-2格式文件體積差不多的情況下，AVI格式的質(zhì)量相對而言要差不少。另外，由于AVI格式中，索引塊位于文件末尾，所以導(dǎo)致了網(wǎng)絡(luò)視頻流時，無法做到“邊下邊播。RMVBRM多了一VB，VB指的就VariableBit，動態(tài)碼率的意思[6]Real公司的新的編碼格式9.0格式。RMVB實際上是RealHeilx系列的一種容器，與本身格式?jīng)]有關(guān)系，類似于：AVI、MKV等格式。對于本工程而言，RMVB最大的缺點在于，其一，RealMedia編為商業(yè)用途，容器封閉，并不開源和免費使用；其二，其編碼速度慢，編碼，耗電耗資源嚴(yán)重，16MatroskaMedia檔內(nèi)。它也是其中一種開放源代碼的多封裝格式。Matroska定義了三種類型的檔：MKV File）——檔可以包含音頻和字幕；MKA（MatroskaAudio幕文件。MKV是Matroska系列的其中一種文件格式。態(tài)畫面中使用較大的幀率，而在靜態(tài)畫面中使用較小的幀率，這樣可以有效的減少TS流的原因基本一致，通的研究內(nèi)容及相關(guān)技術(shù)H.264H.264流V圖1.2程研發(fā)，所以主要需要對H.264編碼標(biāo)準(zhǔn)和MKV的封裝格式進行深入了解。學(xué)習(xí)，從而了解和分析H.264碼流的方法，為之后的MKV封裝做準(zhǔn)備。同時，由于MKV文件的高度可定制性，項目將通過對標(biāo)準(zhǔn)MKV文件進行分析實驗，了解MKV容器的封裝標(biāo)準(zhǔn)和特點，得出適合工程實際情況的MKV封裝結(jié)構(gòu)。H.264編碼原本工程系統(tǒng)中處于部分的為錄播服務(wù)器，其輸入信號為經(jīng)過VGA編編碼后的H.264碼流信號。本系統(tǒng)的任務(wù)即為處理H.264碼流信號，所以，需H.264編碼標(biāo)準(zhǔn)做一定的學(xué)習(xí)了解。掌握H.264碼流解析方法，從而從中得到封裝MKV所需要的數(shù)據(jù)和信息。在編碼層(CodingLayer--VCL)和網(wǎng)絡(luò)提取層(Network ionLayer--NAL)碼、去區(qū)塊效應(yīng)濾波及熵編碼等封裝在編碼層而在解析H.264時，不用涉及H.264如因此，本主要會對H.264編碼中NAL層的相關(guān)問題進行詳述，學(xué)習(xí)分析和解析H.264碼流的方法。MKV封裝格式的研究MKV的文件格式的目標(biāo)多媒休包容格式的標(biāo)EBML（ExtensibleBinaryMetaLanguage，擴展的二進制多語言。與XML標(biāo)記語言有點相似。的主要目標(biāo)，是在了解EBML語言的基礎(chǔ)上，對標(biāo)準(zhǔn)MKV的二進制文件分析。深入MKVEBML（ExtensibleBinaryMetaLanguage）是一個可適應(yīng)任何類型數(shù)據(jù)的廣義文件格式，其目標(biāo)是成為“XML的二進制形式”或者說二進制下的類似XML的語言[7]。EBML提供了一種數(shù)據(jù)的框架其中為類似XML的形式。與XML不同，EBML不是一種可擴展的形式，在數(shù)據(jù)前必須知道文件類型定義（TypeDefinition解析。從結(jié)構(gòu)上來看，EBML中的每一個元素有三個部分：ID，SIZE，DATA，是典型TLV（TypeLength長度，Value值）格式結(jié)構(gòu)。其中，IDSIZE的表示方法，都是采用UTF-8編碼那樣的不定長前綴表示法。而DATA采用普通的方法，但DATA既可以是該元素的值，也可以是其他一系列元素的列表：typedef{}

1.1MKVLevelLevelLevelLevelMetaEditionCueing MKV文件格式的顯著特點是模塊化、結(jié)構(gòu)化。每一個高一級的元素由若干次MKV文件有兩部分組成：EBMLHeaderSegment，EBMLHeaderEBMLVersion、DocType等子元素組成，包含了文件的版本、文檔類型等相關(guān)信息。Segment部分保存了文件的和音頻的實際數(shù)據(jù)，其data部分又可以分為SeekHeadTracksCluster等如表1.1。所示，MKV文件分為五個層次，Level0、Grou、Level1、Level2、level3。從縱向看，MKV封裝格式包含五個層面，Level0代表MKV文件的最基本框架，是由兩部分組成，EBMLHeader和Segment；Grou代表了在Level0這兩大框架下包含了的數(shù)據(jù)組織，這些Grou之間是相互獨立的，MKV文檔給出了建議的順序，但是改變順序并不會影響MKV文件的正常；Level1表示在數(shù)據(jù)組織的內(nèi)部，有并列的各種數(shù)據(jù)包，比如對于GrouClusters而言，每一個Cluster包含一秒的細(xì)的分級，主要用于描述基本數(shù)據(jù)塊的不同屬性；而Level3即為構(gòu)成MKV文件的最可見，MKV的封裝格式中包含了的內(nèi)容，其每個元素對于一個具體文件結(jié)本文的主要內(nèi)容是研究H.264碼流的與封裝，首先需要研究H.264碼流結(jié)構(gòu)形式H.264碼流中正確分析出目標(biāo)信息；其次，在分H.264碼流文件的前提下，還要針對MKV的文件結(jié)構(gòu)進行深入的學(xué)習(xí)了解；期知識準(zhǔn)備完畢之后，利用C++程序設(shè)計語言實現(xiàn)對H.264碼流文件的MKV形式封裝，并且達到工程預(yù)期的效果。首先本文分析了現(xiàn)階段，編碼的發(fā)展情況和封裝格式的對比情況，簡單論述了在系統(tǒng)實現(xiàn)中，選取H.264編碼方式和MKV文件封裝格式的優(yōu)勢和意義；其次，第一章緒論主要介紹《H.264碼流的與封裝》的選題背景與其研究意義，并且列舉中主要論述整個H.264編碼與封裝過程中所涉及到的。針對“H.264碼流傳輸與”和“MKV文件封裝”等兩個問題進行詳細(xì)敘述，主要涉及到H.264編碼標(biāo)準(zhǔn)與MKV封裝格式的相關(guān)內(nèi)容。系統(tǒng)需求和總體設(shè)本系統(tǒng)為多VGA錄播系統(tǒng)。系統(tǒng)可同時實現(xiàn)局域網(wǎng)內(nèi)的和化構(gòu)建，可以讓用戶進行管理，增加系統(tǒng)的可用性。功能需求多VGA錄播系統(tǒng)的大部分功能需通過一鍵式操作完成，降低用戶使用的難度，增強系統(tǒng)的易用性和穩(wěn)定性。系統(tǒng)需完成信號、VGA信號采播系統(tǒng)在局域網(wǎng)內(nèi)，為遠(yuǎn)端用戶提供實時，并支持第非線性編輯。對于系統(tǒng)的音頻信號，需兼容音頻壓縮標(biāo)準(zhǔn)AAC或G.721，保證音同時DVI、VGA、過網(wǎng)絡(luò)實時到的VGA信號，或點播已錄制在服務(wù)器中的文件，或備份下載，也可以對服務(wù)器上數(shù)據(jù)進行管理。 節(jié)點VGA信號進行或擴充時，只需要將設(shè)備安裝到位并在錄播服務(wù)器中修改性能需求CPU40%，只有滿對于系統(tǒng)的質(zhì)量，需要其具有適應(yīng)計算機不同分辨率的能力，在用戶有特別的要求，但是，當(dāng)用戶點擊某一分屏，需要監(jiān)視特定前端PC機時，服務(wù)器行8路低清信號轉(zhuǎn)切到1路信號時，延遲時間不得超過1秒鐘。對于錄制質(zhì)量，是說錄制的分辨率需為系統(tǒng)前端PC機原始分辨率，即1600*1200的VGA分辨率。錄制的還需支持可變幀率，使在相同文件大小的文稿類文件，需要保證或來的數(shù)據(jù)及字體的辨識度高。主要標(biāo)準(zhǔn)為，OfficeWord中的5號字可以清晰識別，肉眼基本上看不出回放屏與錄制的清晰度對于可擴展性，系統(tǒng)要求至少可同時8路，最多要能夠支持16路的制一天VGA信號的情況下，系統(tǒng)能夠正常運行，而不會因為空間不足導(dǎo)裝為MKV格式?？傮w設(shè)計系統(tǒng)組成編編......編編圖2.1多VGA錄播系整體系統(tǒng)結(jié)構(gòu)示意圖如圖2.1所示。分為四個部分標(biāo)機輸出的VGA信號編碼為適應(yīng)不同需求的高低清H.264碼流，以供后續(xù)處項目要求最少支持同時對8路VGA信號進行，同時，將的信號錄制為MKV文件格式在服務(wù)器上，供隨時調(diào)用。服務(wù)器最大能夠支持同時對路信號進行。服務(wù)器得到的輸入信號為可選清晰度的H.264碼流。當(dāng)對8路信號同時時，不需要過晰度，但是對流暢度有要求，這時服務(wù)器從VGA編處請求到的即為低清H.264碼流；當(dāng)需要錄制以供后續(xù)調(diào)取時，服務(wù)器從16100/1000M自適應(yīng)端口，所有端口都100M1000M速率進行工屏幕內(nèi)容。點播客戶端的主要功能是調(diào)取及管理服務(wù)器上已錄制好的MKV文件進行。數(shù)據(jù)備份機主要用于周期性的備份系統(tǒng)數(shù)據(jù)。由于管理服務(wù)器的容量有限，所以需要定時備份服務(wù)器上錄制好的數(shù)據(jù)，并清理服務(wù)器設(shè)備選型轉(zhuǎn)發(fā)和管理，實現(xiàn)錄播功能。每個服務(wù)器可連接多達16個錄播編，并對編及表2.1多錄播服務(wù)器技術(shù)規(guī)格H.264HighHAD17428多錄播服務(wù)器支持的輸入信號為符合H.264HighProfile圖像壓縮標(biāo)準(zhǔn)的碼流信號。服務(wù)器支持包括移動通信技術(shù)在內(nèi)的多種網(wǎng)絡(luò)調(diào)制方式。在參數(shù)方面，服務(wù)器支持目前主流的大部分分辨率，可適應(yīng)不同的前端PC機。與此同時，服務(wù)器支持Rate碼率可以使其增加兼容性。VBR（VariableBitRate，為動態(tài)比特率。其編碼時會根據(jù)數(shù)文件質(zhì)量。對于容量，系統(tǒng)標(biāo)準(zhǔn)配置為2TB。這是因為，經(jīng)過實際測算，按照一天錄制八個小時為標(biāo)準(zhǔn)，一路1600×900分辨率VGA信號占用約1GB空間。2TB可以保證系統(tǒng)最大負(fù)荷下（16路同時進行錄制，長時間（至少一個月）由于系統(tǒng)的需要，本系統(tǒng)采用了VGA編碼這一成硬件，從而更好的實現(xiàn)系統(tǒng)需求。編同時支持一路/VGA編碼和一路聲編碼，提供豐富的接口，支持VGA、DVI、和CVBS輸入。采用H.264HighProfile編碼，可提供廣播級的質(zhì)量。外觀如圖2.2。所示。圖2.2/VGAVGA編主要參數(shù)如表2.2所示表2.2VGA編主要參數(shù)1D-sub(15針)輸1920x1080 800x600、640x480及其他指定分辨xx1-60128Kbps–部1 ；1路分量；1路1-60128Kbps–音頻部分1路RCA1路RCA其他部分110/100MbpsIO及控制接1RS485；1個地；4個用嵌入WEB服IE瀏覽、配置、升SD卡接口，可內(nèi)置1塊液晶280mm×190mm×4個功能按鍵；1個紅 技術(shù)選型本系統(tǒng)工程主要選取了Windows平臺為服務(wù)器和與點播系統(tǒng)客戶端的操作系統(tǒng)，并選擇了目前市場占據(jù)份額最大的WindowsXP版本。在Windows系統(tǒng)UNIX、LINUXMACOS而言最好的。由于工程設(shè)計涉及到包括VGA信號的處理，H.264碼流的封裝與，多服務(wù)WindowsXPWindowsXP系統(tǒng)作C++語言。另外，C++作為面向?qū)ο笳Z言，擁有面向?qū)ο笳Z執(zhí)行效率下，選用了更加利于編寫系統(tǒng)程序的面向?qū)ο笳Z言C++。此外，系統(tǒng)工程的實現(xiàn)還調(diào)用了第的庫。對于VGA編，由于其是成THDEXFSDK_NE.dlTLHDEXFSDK_DECODE.dl能，庫主要完成對網(wǎng)絡(luò)庫接收來的數(shù)據(jù)做的功能。另一類開發(fā)包是TLHDEXFSDK_APP.dll庫，是對TLHDEXFSDK_NET.dll和TLHDEXFSDK_DECODE.dll小本在系統(tǒng)設(shè)計中所做的工作。系統(tǒng)實現(xiàn)中的MKVMKV文件格式各部分的作用和意義的情況下，才能順利的進行MKV文件的封裝工作。壓縮編碼標(biāo)準(zhǔn)——高級編碼）是一種壓縮標(biāo)準(zhǔn)，一種被廣泛使用的高精度的錄制、壓縮和發(fā)布格式。第一版標(biāo)準(zhǔn)的最終草案于2003年5月完成。編碼組與ISO/IEC聯(lián)合工作組——即動態(tài)圖像組（MPEG）——聯(lián)合組成的聯(lián) H.264中的基本概將逐字節(jié)的展示如何在H.264碼流中解析本節(jié)所示元素。H.264I幀、P幀、B幀的概念，也沒有IDR幀的概念。協(xié)議來說，平常所熟悉的那些稱呼，例如：I幀、P幀、B幀等等，實際上都是把圖像但是，在本所研究的問題中，因為不涉及到H.264本身編碼算法的問題，I幀、P幀、B幀等。NALUIDR幀是I幀的一種，所以它們也不參照其它幀。這意味著它們可以作為的搜（3）I幀、P幀、B面說明，本所述之I幀、P幀、B幀等概念，非概念，但適合于本論I幀來壓縮數(shù)據(jù)。I幀表示關(guān)鍵幀，可以理解為這一幀畫面的完整保留；時只需要本幀數(shù)據(jù)就可P幀表示的是這一幀與之前的一個關(guān)鍵幀（或P幀）的差別，時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。P幀也就是差別幀，P幀沒有完整畫4種情況，不贅述。換言之，要B幀，不僅要取得之前的緩存畫面，還要之后H.264SPS（SequenceParameterSet）PPS（PictureParameterSet）串，包含了初始化H.264器所需要的信息參數(shù)，如編碼所用的profile，level，圖像的寬和高，參數(shù)，如果沒有這些參數(shù)，MKV文件就無法完整的制作，也無法正常的。另外，SPS和PPS都是以BASE64編碼形式進行編碼的，所以在解析時，有一定的難度，下一節(jié)將會通過實例，展示如何進行H.264簡單。NAL單元是一個一定語法元素的可變長字節(jié)字符串，包括包含一個字節(jié)的頭個編碼片、A/B/C型數(shù)據(jù)分割或一個序列或圖像參數(shù)集。性指示位，占2個bit；最后的F為位，占1bit。如表3.1所示：3.1NALU01234567F位01，以便接F位為0時，智能的器將嘗試重構(gòu)這個NAL單元（已知它可能包含比特錯誤而非智能的器將簡單地拋棄這個NAL單元。重要性指示位NRI——nal_ref_idc，2NAL單元的重要性，值越大，越重要。值為0表示這個NAL單元沒有用于預(yù)測，因此可被器拋棄而不會有錯誤擴散；值高0表示此NAL單元要用于無漂移重構(gòu)，且值越高，對此NAL單元丟這個組件NAL單元的有效載荷（payload）的類NALU32種24～31H.264以外的，RTP負(fù)荷規(guī)范使用這其中的一些值來定義包聚合和分裂，其他值為H.264保留。表3.2H.264建議規(guī)定的NALUNAL單元的內(nèi)0123456789H.264碼流詳細(xì)分第一個NALU為：674D40339A74142342000104BA003D09011E3065SliceSEIH.264NALUSPS，PPS，IDR。下面來驗證一forbidden_zero_bit= //nal_ref_idc= //nal_unit_type= //profile_idc==00=11=00=00=00=00=0level_idc=level_idc元素解析之后，下一個元素比較特殊seq_parameter_set_id，文檔規(guī)顯示其為ue(v)的數(shù)據(jù)結(jié)構(gòu)，實際上是一種Exponential-Golombcoding編碼（指數(shù)哥編碼）[10]指數(shù)碼作為一種由編碼可直接解得碼字的變長碼，應(yīng)用非常廣泛，在H.264編碼中，使用的是0階無符號整數(shù)指數(shù)編碼。階碼字結(jié)構(gòu)CodeNum取示K=101025階碼字結(jié)構(gòu)CodeNum取示K=101025--2i–1+bs_read(s,i)。也就是20-1+0=0。意味著編碼1的實際值為0。也就是log2_max_frame_num22–1+2=7。num_units_in_ticktime_scaleHz的頻time_scale27MHz的時鐘測量時間的時間坐標(biāo)系的time_scale27000000。time_scale0。fps=sps.vui.i_time_scale/sps.vui.i_num_units_in_tick/EBML（ExtensibleBinaryMetaLanguage）是一個可適應(yīng)任何類型數(shù)據(jù)的廣義文件提供了一種數(shù)據(jù)的框架，其中為類似XML的形式。與XML不同，EBML不是一種可擴展的形式在數(shù)據(jù)前必須知道文件類型定（TypeDefinition。IDSIZE的表UTF-8編碼那樣的不定長前DATA采用普通的方法，但DATA既可以是該元素的值，也可以是其他一系列元素的列表。=====n+11做間隔標(biāo)志，1后面跟的是實際的整數(shù)值，該整數(shù)值由隊列數(shù)據(jù)和尾數(shù)據(jù)組成，尾數(shù)據(jù)的字節(jié)數(shù)為n。所以它的整數(shù)是這樣的，最多可以表示七個字節(jié)的數(shù)據(jù)，如表3.4所示3.4Vint11xxx201xxxxxxxxxx3001xxxxxxxxxxxxxxxxx40001xxxxxxxxxxxxxxxxxxxxxxxx例如，0x7A24，其二進制編0111101000100100，若VINT類型，那么可以通過表3.4查的，其數(shù)據(jù)為0x3A24。EBML示例分8101726F以上，為MKV中EBMLHeader部分的編碼。根據(jù)MKV文檔列出下表，表中顯示了相關(guān)元素對應(yīng)的編碼，工程中主要通過對比表3.5來對文件進行分析。3.5EBMLHeaderElementDefault01A45DF-142114211424142814214211421[1A][45][DF][A3]EBML，[A3]10100011VINTEBML的數(shù)據(jù)長度，為0x23，也就是35個字節(jié)。可以看到，數(shù)量（42=1=1=4=8接著，分析“4282886D6174726F736B61”，[42][82]表示元素名稱DocType，[88]表示數(shù)據(jù)內(nèi)容長度為8個字節(jié)，剩下8個字節(jié)長的數(shù)據(jù)為原始數(shù)據(jù)，按照UTF-8解最后，（42878104）和（42858102）DocTypeVersion4，DocTypeReadVersion=2。vint類介VINT類是處理上述問題的一個的類，可以在圖3.1中看出，在寫MKV文件VINTEBMLMKVEBML格式語言所書寫的，所以在MKV的每一個部分都會調(diào)用vint類。所以，在這里對vint類做圖3.1vint3.6vint3.6vint成員變量成員函數(shù)構(gòu)造函數(shù)重載，將傳入?yún)?shù)value為vint對象設(shè)value為其值（將傳入的32位無符號整型量value將傳入的64位無符號整型量value用字符串str對對象設(shè)置此元素的EBML_ID的size值為uint8unsignedchar8位無符號整型量。uint32實際上unsignedint32位無符號整型量。uint64unsignedlonglong的重定義，指64位無符號整型量。對于成員函數(shù)full4set而言，此方法設(shè)置對象的值將只用滿4個字節(jié)，也就是說，0x100x100000103個字節(jié)+4BIT表示長度。而對于成員函數(shù)full8set而言，此方法是將傳入的64位無符號整型量以VINT的形式存入8個字節(jié)，也就是0x100x0100000000000010。MKV文件格MKV是一種新的多封裝格式，支持多種和音頻編碼格式，能夠?qū)⒍噙_16MKV全稱為Matroska，是一種新的多封裝格式。多封裝格式也稱多容器(MultimediaContainer)。它只是為多編碼提供了一個“外殼”，本身不涉種類似于XML格式的可擴展二進制元語言，使用可變長度的整數(shù)，一方面便于結(jié)EBML節(jié)已經(jīng)做了很詳細(xì)的敘述，這里不再贅述圖3.2MKV如圖3.2所示，MKV文件分為五個層次，Level0、Grou、Level1、Level2、Level3[11]。Level0代表MKV文件的最基本框架，是由兩部分組成，EBMLHeader和Segment；Grou代表了在Level0這兩大框架下包含了的數(shù)據(jù)組織這些Grou之間是相互獨立的，MKV文檔給出了建議的順序，但是改變順序并不會影響MKV文件的正常；Level1表示在數(shù)據(jù)組織的，有并列的各種數(shù)據(jù)包；Level2是相對于Level1而言更加細(xì)的分級，主要用于描述基本數(shù)據(jù)塊的不同屬性；而Level3即為構(gòu)成MKV文件的最基本的元素?？梢姡琈KV的封裝格式中包含了的內(nèi)容，其每個元素對于一個具體文件的作用與影響不同，下面將介紹各個組織數(shù)據(jù)中，重要元素對于MKV封裝和的影通常，MKV文件的第一部分為EBML屬性數(shù)據(jù)。EBML部分實際上標(biāo)識了這MKV，并且給出了文檔的基本信息。EBMLLevel1級數(shù)據(jù)構(gòu)成，其同屬于EBMLHeader數(shù)據(jù)包。層次結(jié)構(gòu)如圖3.3所示：圖3.3EBML其主要描述的信息包括生成此MKVEBMLEBML文件的類型。3.7MKVEBMLHeaderEBMLIDEBMLSizeMKVLevel0EBMLSegment。Segment部分主要包括了音視對于SegmentHeader，相比較而言，與EBMLHeader類似，很多元素的值可以事先約定，完全不影響MKV文件的解析與。在之前的試驗中，去掉某些元素（以Seek元素為主也完全不會影響MKV文件的解析，也不會影響效果。Tags。其組織結(jié)構(gòu)如表示SeekHead部分包含了其他數(shù)據(jù)組織在MKV文件中的位置的索引，例如Trackinformation,Chapters,Tags,Cues,Attaents等等。這部分元素并不是必須的，但是如Level1層次數(shù)據(jù)。MKVEBMLMatroska3.83.8MKVSegmentHeader SegmentInformationMKV文件的基礎(chǔ)信息。包括文件的標(biāo)題其中SegmentUIDSegment128位字符串，是區(qū)別于其他的Segment的一個唯一的ID，用來標(biāo)識文件的唯一性。Track包含了音的基本信息，如音器類型、分辨率、音頻采樣率初始化這些器做好準(zhǔn)備工作。每個TrackEntry代表著1條軌道信息。其中，TrackNumber用于ClusterSimpleBlockSimpleBlockstream1時，ID，用于標(biāo)識Track信息。比如當(dāng)直接某軌道流到另一文件時，此ID就用于標(biāo)識1:；2:audio；3:complex；0x10:logo；0x11:subtitle；0x12:buttons；0x20:control。都在保存在這部分中。1Cluster內(nèi)可能有很多個BlockGroup組成，BlockGroup內(nèi)又由若干個Block組成。這些Block內(nèi)就是音的幀數(shù)據(jù)。其結(jié)構(gòu)層次如圖3.4所示：圖3.4ClusterMKV文件中，通常會有很多Cluster。Cluster機制的存在，可以使原有的Block被分散，利于更好的利用空間。另外，Cluster的存在也利于文件解析時的搜索和錯誤處理。理論上，每一個Cluster所包含的數(shù)據(jù)大小或者時間長度沒有任何限制，但是目前開發(fā)者普遍有一個共識，即一個Cluster中數(shù)據(jù)大小不超5MB，或者時長不5s。在本工程中，一Clusterfps幀數(shù)據(jù)，也就1s時長的數(shù)據(jù)信息。1個Cluster中并不一定只是音頻或者。它是由不同的音BlockGroup交叉組成。因為多文件中的音數(shù)據(jù)本來就是交叉出現(xiàn)的。在實際解析MKV數(shù)據(jù)時發(fā)現(xiàn)，一個Cluster中的眾多SimpleBlock，并不只屬于這一個Cluster，而是分屬于不同的Cluster。圖3.5為MKV中Cluster的部分?jǐn)?shù)據(jù)解析情況，可以注意到有三個藍色框線的H.264的NAL單元數(shù)據(jù)。同時，對于圖3.5，紅線標(biāo)明的關(guān)鍵點1，顯示了Cluster的一個重要屬性——TimeCode其意義為基于TimecodeScale的絕對時間標(biāo)識了Cluster所包含的Block的開始時間碼。而具體時間（以微妙為單位）的其計算方法為TimeCode的值與TimecodeScale（對于特定MKV文件而言是常量）的值進行相乘。圖3.5Cluster3.5中紅色實線標(biāo)明的關(guān)鍵點1和橙色框線標(biāo)明的關(guān)鍵點3，敘述本SegmentCueingData部分。如果沒有關(guān)鍵幀的索引的話，在MKV文件解析和時，進行“seek”操作或者“快進快退”操作將會十Cues中包含很多CuePoint，每一個CuesPoint就是一個關(guān)鍵幀的索引，數(shù)據(jù)中記SegmentH.2643I幀、PB幀圖3.6CueingDataCues的結(jié)構(gòu)相對比較簡單，如圖3.6所示，其中包含了非常有用的，通常Block的時間碼Cluster的位置。CuePosition中，還包含了此索引所對應(yīng)的軌道號TrackNum。CueTime指此關(guān)鍵幀所在ClusterTimeCode3.5所示，圖中橙色框線標(biāo)明的關(guān)鍵3說明了當(dāng)SimpleBlock是關(guān)鍵幀，而圖中紅色實線標(biāo)明Cues部分對于MKV文件的影響十分大，通過實驗中的例子可以直觀展示這種區(qū)別。如3.7所示，選取了同一時刻的兩幀畫面作為對比。圖3.7左側(cè)畫面所示為缺少Cues數(shù)據(jù)的MKV文件畫面，右側(cè)畫面為有Cues數(shù)據(jù)的MKV文件畫面。兩個MKV文件唯一的區(qū)別在于，一個有Cues部分，一個沒有?？梢悦黠@的看出，缺少關(guān)鍵幀索引的MKV畫面人物面部模糊，馬賽克情況嚴(yán)重，字幕不清晰，幾乎無法閱讀；而有關(guān)鍵幀MKV文件時，畫面清晰柔和，字幕能夠正確辨認(rèn)。圖3.7MKV有無Cues部分效果對比圖3.8CuePoint個SimpleBlock是keyframe，也就是關(guān)鍵幀。當(dāng)?shù)疥P(guān)鍵幀的時候，就會添加一處CuePoint，其中，CueTime指的是此關(guān)鍵幀所屬的Cluster的絕對時間，也就Cluster的TimeCode，而CueTrack指的是軌道，與之前Tracks的信息對應(yīng)，1為軌。這里說CuePoint為關(guān)鍵幀。而剩下的CueClusterPosition是此關(guān)鍵幀所屬的Cluster相對的Segment的位置，單位是字節(jié)?！?92Segment429個字節(jié)開始，即為關(guān)鍵幀對應(yīng)的位置。圖3.5中關(guān)鍵點4Clusterpos528，也就是起始字節(jié)為文件的528個MKV文件可以知道SegmentID和Size長度12Segment的起始字節(jié)為文件的第24字節(jié)，所以528-24-12=492。了MKV的不同的部分。Info、Track、Clusters、CueingData、Attaent和Tagging等內(nèi)容。EBMLHeaderMKV可辨識性的信息，SeekHead包含其實部分位置信息。SegmentInformation包含識別文件的信息，Track包含了音的基本信息，如音[12]此外，CueingDataSeek小涉及到的。由于H.264編碼具有特殊性和復(fù)雜性，只有深入了解其編碼形式及MKV的封裝做好準(zhǔn)備。同時，也詳細(xì)為MKV文件的封裝工作奠定了基礎(chǔ)。文件封裝為MKV文件形式。碼流錄制接收端此部分主要利用成硬件—— VGA編提供的API實現(xiàn)。在實現(xiàn)的過程中，主要通過參看軟件開發(fā)手冊，調(diào)用相應(yīng)的API，來實現(xiàn)H.264碼流的獲取和。VGA編硬件能夠提供多路碼流，包清和低清兩個畫面質(zhì)量，并且包括和音頻信號。在實際工程中，考慮到后續(xù)工作，選擇了碼流（分辨率：1440×900）,并且只錄制了信號。圖4.1因為整個部分的目的在于將獲取的信號的H.264碼流保存成文件以供后續(xù)處4.1所示的是程序運行界面，下面將會通過幾個主要的調(diào)用函BOOL頻文件，以二進制寫入形式打開。m_stream=fopen("c:\\FFmpeg\\bin\\.h264","wb"void當(dāng)點擊“登錄并獲取數(shù)據(jù)首先將會初始化SDK，調(diào)用TLHDEXFSDK_NET_APITLENCODE_Init()，當(dāng)初始化成功時，返回TLENCODEHD_RESULT_SUCCESS（實際值為0）。然后會設(shè)置網(wǎng)絡(luò)超時時間，調(diào)用TLHDEXFSDK_NET_API 系統(tǒng)默認(rèn)是TLHDEX1000F_MAX_TIMEOUT，5秒后超時。括設(shè)備唯一標(biāo)識、IP地址等。以上信息，通過MFC的框輸入，這些參數(shù)都傳給方char*pchAryUserName,char*pchAryPassword,STLEncodeDeviceInfo&struDeviceInfo)，要連接的設(shè)備IP地址；dwPort[DWORD,IN]，表示要連接的設(shè)備端；strUserName[string,IN]，表示登錄設(shè)備的用戶名；strPassword[string,IN]表示登錄設(shè)備的；struDeviceInfo[STLEncodeDeviceInfo,OUT]，表示設(shè)備信息。當(dāng)方法成功返回時，會返當(dāng)連接設(shè)備成功后，會調(diào)用方法 voidTENCODE_StopGtEnoddt(HANDEhDhnnl)用TENCODE_oout，來斷開與硬。為MKV，最后看到的即為可以用常用器點擊的MKV文件。system("C:\\FFmpeg\\bin\\ffmpeg.exe-iC:\\FFmpeg\\bin\\.h264-vcodeccopy-acodeccopyC:\\FFmpeg\\bin\\.mkv");碼流封裝部分此部分內(nèi)容，實際上為獨立實現(xiàn)FFmpeg開源的庫所實現(xiàn)的將H.264碼流文件封裝MKVMKV的文件格式，進一步熟悉闡述，來詳細(xì)敘述封裝MKV的工程實現(xiàn)過程。重要的數(shù)據(jù)結(jié)構(gòu)unsignedcharh264buf[1024*程序在一開始會申請一塊1MB的內(nèi)存空間，用于存放的H.264數(shù)據(jù)，然后從nalu，進行后續(xù)的工作。自始至終，h264buf會不斷的被覆蓋和填充。第一次讀入數(shù)據(jù)時，也就是調(diào)用openFile()函數(shù)時，會在1MB的數(shù)據(jù)中搜索第一個nalu，在3.1壓縮編碼標(biāo)準(zhǔn)——H.264節(jié)中，詳細(xì)介紹了這樣做的原因，此處不再贅述。從里面搜索出 圖4.2h264bufh264buf的是函read_nalu函數(shù)定義為：intread_nalu(unsignedchar**nal,unsignedint*size)。參數(shù)nal為指向h264buf的指針，size保存的nalu的取的數(shù)據(jù)末尾，p_next指針記錄已數(shù)據(jù)部分的結(jié)尾。這樣每次在調(diào)用read_nalu函H.264read_nalu函數(shù)的主要作用，是分析出h264buf中的nalu，以供后續(xù)封裝cluster使用。其中，size記錄了此次到的nalu的長度，指針p記錄nalu的起始位置，指針p_next記錄的是解析到的此nalu的結(jié)束位置。這些信息，將會在之后傳給函數(shù)mkv_block.build_buf使用。類和主要流程MKVMKV文件中的不同的對象數(shù)據(jù)，MKV文件中。所以這個類所包含的屬性MKVMKV文4.14.1MKV_HANDLE成員變量成員函數(shù)int64SEEK_SET）posuint8*uint32向buf中寫入大小為size的數(shù)據(jù)int64SEEK_CUR）pos在工程中頻繁使用的成員函數(shù)有兩個，分別是seek_head和write_buf。以下舉例說seek_head函數(shù)而言，每次在所有的Cluster處理完后，需要返回原來Segment可，然后重寫Segment的Header部分。write_bufbufMKV的某部分，size為將MKV文件中。例如，Cueswrite_buf(cues.buf,cues.head_size+cues.payload_size)將寫好的Cues部分，寫入MKV文件中。MKV文件中比較重要的結(jié)構(gòu)元素都構(gòu)建了類。MKV其他的部分元素與Cluster類似，均為EBML結(jié)構(gòu)語言描述，所以，選取有代表性的cluster類進行闡4.24.2cluster默認(rèn)構(gòu)造函數(shù)，申請一塊unsigned將時間ms寫入time_bufunsigned增加sizecluster_sizeVINTVINTCluster的總大小，以便于SegmentHeader的時候，確定參數(shù)。head_sizeClusterHeader的大小，payload_size為所有block也就是所見到的SimpleBlock的大小總和。而total_sizeClusterHeaderSimpleBlock的大小總和的相加，實際上也就是整Cluster的大小。offset記錄著當(dāng)前寫數(shù)據(jù)的偏移量。timecodecluster的屬性中塊都會寫入buf中，最后buf再寫入MKV文件中。MKVMKV文件的Read生成CuesSegmentRead生成CuesSegment合并寫寫key 建立修改Cues圖4.3MKV引。在分析出nalu之后，會生成一個Block，每一個cluster中保存一秒的，所以也cluster中含fps幀畫面。同時，在read_nalu的時候，也會分析是否到達不到nalu的分隔符時，即可認(rèn)為碼流文件結(jié)尾，并拋棄不完整的nalu單元。最后cluster部分MKV文件CuePoint寫在之MKV文件的封小H.264從產(chǎn)生，獲取，保存.h264文件到本地，到分析.h264MKV文件形式的具體過程，詳細(xì)描述了在以上過程功能測試測試環(huán)境因為VGA編提供的API支持WindowsXP操作系統(tǒng)平臺，所以根據(jù)實際情況，系統(tǒng)選用了以下配置，如表5.1所示：5.1硬件環(huán)境i7-2600@4GB(DDR3編VGA編屏幕尺寸：18.6(40x25厘米顯示比例：寬屏（16分辨率：1440x 32位真彩軟件環(huán)境WindowsXP32BuiltonFeb27201422:07:15withgcc4.8.2能看清OfficeWord中的五號字。測試過程圖5.1如圖5.1所示，在窗口初始化后，會自動填充設(shè)備端口、用戶名和信息，沒有需要填寫的是設(shè)備IP地址，也就是VGA編的IP地址，因為在整個局域網(wǎng)絡(luò)中，VGA編的IP地址會隨著網(wǎng)絡(luò)的情況發(fā)生變化。志輸出處，顯示相應(yīng)的錯誤代碼。如圖5.2所示。此時系統(tǒng)日志輸出的語句，實際意思即返回TLENCODEHD_RESULT_SUCCESS（實際值為0）結(jié)果；輸出語句圖5.2這時，可以看到在對應(yīng)的，已經(jīng)開始生成H.264碼流文件——“.h264”圖5.3MKV5.3所示。控制臺輸出的信息為在碼流封裝過程中所輸出的有關(guān)封裝MKV的相關(guān)參數(shù)信息等。最后，會在碼流文件生成處發(fā)現(xiàn)封裝好的MKV文件——“.mkv”，雙擊即可。結(jié)果分析的一小部分，來驗證是否能看清OfficeWord中的五號字。圖5.4MKV效果截性能測試畫面質(zhì)量分析的。在沒有特殊說明的情況下，都是流暢的，沒有其他性能上的問題。VGA信號通過編會有一部分損失，本將會對比三個畫面，分別是原屏幕截圖，通過VGA編后圖象截圖和封裝為MKV后畫面截圖。論文將通過這三個截圖來展示信號經(jīng)過VGA編的損失程度，以及封裝對于信號圖5.55.5是直接在屏幕上截取的圖像，相比較而言是質(zhì)量最高的圖像，是沒有經(jīng)過任圖5.6VGA圖5.7封裝為MKV后效果截5.65.7MKV封裝過程中，畫面質(zhì)量并沒有MKVVGA編編碼過程中。所以，可以