培訓(xùn)-GB28181中的視頻流

4/20等級：四級淺論GB28181平臺視頻流武漢烽火眾智數(shù)字技術(shù)有限責(zé)任公司目錄負(fù)載類型（payloadtype）:96；編碼名稱（encodingname）：PS；時(shí)鐘頻率（clockrate）：90kHz；SDP描述中“m”字段的“media”項(xiàng)：video。2.基于RTP的視音頻基本流封裝該方式直接將視音頻數(shù)據(jù)以負(fù)載的方式封裝成RTP包。A）MPEG-4視頻流的RTP封裝MPEG-4視頻流的RTP封裝格式應(yīng)符合RFC3016協(xié)議中的相關(guān)規(guī)定。MPEG-4視頻流RTP包的負(fù)載類型（PayloadType）標(biāo)識號選定：從RFC3551協(xié)議的表5中的動態(tài)范圍（96-127）中選擇,建議定為97。B）H.264視頻流的RTP封裝H.264的RTP載荷格式應(yīng)符合RFC3984中的相關(guān)規(guī)定。H.264視頻流RTP包的負(fù)載類型（PayloadType）標(biāo)識號選定：從RFC3551協(xié)議的表5中的動態(tài)范圍（96-127）中選擇,建議定為98。C）SVAC視頻流的RTP封裝SVAC視頻流的RTP載荷格式可參照RFC3984中的相關(guān)規(guī)定。SVAC視頻流RTP包的負(fù)載類型（PayloadType）標(biāo)識號選定：從RFC3551協(xié)議的表5中的動態(tài)范圍（96-127）中選擇,建議定為99。2.2視頻流編解碼要求聯(lián)網(wǎng)系統(tǒng)中，對視音頻編/解碼的技術(shù)要求包括編/解碼的檔次和級別、工具選項(xiàng)、碼流語法的規(guī)定以及比特流和解碼器的一致性測試等。具體要求如下：視頻編碼應(yīng)支持H.264、SVAC或MPEG-4視頻編碼標(biāo)準(zhǔn)，視頻解碼應(yīng)同時(shí)支持H.264、SVAC和MPEG-4視頻解碼標(biāo)準(zhǔn)。2.2.1基于H.264的視頻編、解碼技術(shù)要求H.264的檔次和級別采用H.264標(biāo)準(zhǔn)的視頻編碼應(yīng)至少支持ITU-TRec.H.264-2005視頻標(biāo)準(zhǔn)的基本檔次（BaselineProfile），級別（Level）應(yīng)至少支持到Level1.3，標(biāo)清應(yīng)用宜擴(kuò)展支持到Level3，高清應(yīng)用宜擴(kuò)展支持到Level4；視頻解碼所支持的檔次和級別應(yīng)不低于編碼支持的最高檔次和級別，至少應(yīng)支持到H.264視頻標(biāo)準(zhǔn)基本檔次的Level3；視頻解碼宜擴(kuò)展支持H.264主檔次（MainProfile）中的隔行掃描和B幀工具，且相鄰兩P幀間的B幀個(gè)數(shù)不大于2。1、H.264基本檔次的選項(xiàng)和工具H.264基本檔次支持的選項(xiàng)和工具主要有：I片和P片（Slice）；基于內(nèi)容自適應(yīng)的變長編碼CAVLC；容錯(cuò)工具：FMO，ASO，RS；去塊效應(yīng)濾波器（DeblockingFilter）；多參考幀編碼。 采用H.264編碼標(biāo)準(zhǔn)的視頻流應(yīng)為H.264Baseline視頻流，編碼應(yīng)支持上述Baseline選項(xiàng)和工具中的部分或全部，可不支持容錯(cuò)工具；H.264的解碼至少應(yīng)支持上述除容錯(cuò)工具外的全部選項(xiàng)和工具。多參考幀編碼時(shí)，P片的參考幀數(shù)一般不大于兩幀。為了保證碼流解析的效率，比特流中應(yīng)當(dāng)在每個(gè)I幀之前都出現(xiàn)相應(yīng)的SPS和PPS；2、H.264級別的限制H.264級別（Level1～4）的限制如表1所示，表中“-”表示未做相應(yīng)的限制。表1H.264級別（Level1～4）的限制級別最大宏塊處理速率MaxMBPS(宏塊數(shù)/秒)最大幀尺寸MaxFS(宏塊數(shù))最大解碼圖像緩沖區(qū)MaxDPB(4:2:0視頻以1024字節(jié)為單位)最大視頻比特率MaxBR(1000bits/s或1200bits/s)最大編碼圖像緩沖區(qū)MaxCPB(1000bits或1200bits)垂直運(yùn)動矢量構(gòu)成范圍MaxVmvR(亮度幀采樣)最小壓縮比率MinCR兩個(gè)連續(xù)宏塊的最大運(yùn)動矢量數(shù)MaxMvsPer2Mb1148599148.564175[-64,+63.75]2-15192500[-128,+127.75]2-1.26000396891.03841000[-128,+127.75]2-1.311880396891.07682000[-128,+127.75]2-211880396891.020002000[-128,+127.75]2-2.1198007921782.040004000[-256,+255.75]2-2.22025016203037.540004000[-256,+255.75]2-34050016203037.51000010000[-256,+255.75]2323.110800036006750.01400014000[-512,+511.75]4163.221600051207680.02000020000[-512,+511.75]4164245760819212288.02000025000[-512,+511.75]416注：“-”表示未做相應(yīng)的限制。3、H.264基本檔次各級別的參數(shù)限制H.264基本檔次各級別的參數(shù)限制如表2所示。表2H.264基本檔次各級別的參數(shù)限制級別最大子宏塊尺寸（采樣點(diǎn)數(shù)）15761.15761.25761.357625762.15762.257635763.1-3.2-4-4、H.264各級別的最大幀率限制H.264中CIF、4CIF、720pHD、1080pHD各級別（Level）的最大幀率限制如表3所示，表中的“-”表示未做相應(yīng)的限制。其他分辨率各級別的最大幀率限制見ITU-TRec.H.264-2005中的規(guī)定。表3H.264各級別的最大幀率限制級別最大幀尺寸(宏塊)最大宏塊速率（宏塊數(shù)/秒）最大幀尺寸（采樣點(diǎn)數(shù)）最大采樣率（樣點(diǎn)/秒）格式CIF4CIF720pHD1080pHD亮度寬度3527047201088亮度高度28857612801920總宏塊數(shù)396158436008160亮度采樣點(diǎn)數(shù)10137640550492160020889601991485253443801601b991485253443801601.13963000101376768000-7.6-1.239660001013761536000-15.2-1.3396118801013763041280-30.0-2396118801013763041280-30.0-2.1792198002027525068800-50.0-2.2162020250414720518400051.112.8316204050041472010368000-102.325.63.1360010800092160027648000172.068.230.03.25120216000131072055296000172.0136.460.048192245760209715262914560172.0155.268.330.1注：“-”表示未做相應(yīng)的限制。2.2.2基于MPEG-4的視頻編/、解碼技術(shù)要求MPEG-4的檔次和級別采用MPEG-4標(biāo)準(zhǔn)的視頻編碼應(yīng)至少支持ISO/IEC14496-2:2004中簡單檔次（SimpleProfile）的級別L5（ISO/IEC14496-2:2004/Amd.2:2005），即MPEG-4SP@L5。采用MPEG-4標(biāo)準(zhǔn)的視頻解碼所支持的檔次和級別不應(yīng)低于編碼支持的最高檔次和級別，宜擴(kuò)展支持MPEG-4先進(jìn)簡單檔次（AdvancedSimpleProfile）中的隔行掃描和B幀工具。1、MPEG-4簡單檔次的工具M(jìn)PEG-4簡單檔次的工具包括：Basic：基本工具，又包括以下幾種工具：I-VOP：幀內(nèi)編碼的矩形視頻對象平面，逐行掃描的視頻格式；P-VOP：幀間編碼的矩形視頻對象平面，逐行掃描的視頻格式；AC/DCPrediction：AC/DC預(yù)測；4-MV：每個(gè)宏塊可以有4個(gè)運(yùn)動矢量；UnrestrictedMV：不受限制的運(yùn)動矢量。ErrorResilience：容錯(cuò)工具，又包括以下3種工具：SliceResynchronization：片重同步；DataPartitioning：數(shù)據(jù)劃分；ReversibleVLC：可逆的變長編碼。ShortHeader：短頭工具。MPEG-4視頻編碼應(yīng)支持上述簡單檔次的部分或全部工具，可不支持容錯(cuò)和短頭工具；視頻解碼至少應(yīng)支持除容錯(cuò)工具外的簡單檔次的全部工具。2、MPEG-4簡單檔次各級別的參數(shù)限制MPEG-4視頻編/、解碼應(yīng)至少支持簡單檔次的L5級別，參數(shù)限制如表4所示。簡單檔次其他各級別的參數(shù)限制見ISO/IEC14496-2:2004及ISO/IEC14496-2:2004/Amd.2:2005中的相關(guān)規(guī)定。表4MPEG-4簡單檔次L2、L3、L5級別的參數(shù)限制級別L2L3L5典型分辨率CIF(352×288)CIF(352×288)720×576最大對象數(shù)444每種類型的最大對象數(shù)4個(gè)簡單對象4個(gè)簡單對象4個(gè)簡單對象最大唯一量化表111最大視頻內(nèi)容驗(yàn)證（VMV）緩沖區(qū)(宏塊組)7927923240最大視頻復(fù)雜度驗(yàn)證（VCV）緩沖區(qū)（宏塊）3963961620視頻復(fù)雜度驗(yàn)證（VCV）解碼速率（宏塊/秒）59401188040500視頻復(fù)雜度驗(yàn)證（VCV）邊界宏塊解碼速率（宏塊/秒）不適用不適用不適用最大視頻緩沖驗(yàn)證（VBV）緩沖區(qū)總和(16384bits)4040112最大視頻對象層（VOL）視頻緩沖驗(yàn)證（VBV）緩沖區(qū)總和(16384bits)4040112最大視頻包長度（bits）4096819216384最大目標(biāo)呈現(xiàn)尺寸（宏塊數(shù)）不適用不適用不適用小波限制不適用不適用不適用最大比特率(kbit/s)1283848000單對象最大增強(qiáng)層數(shù)不適用不適用不適用3、MPEG-4的碼流語法為實(shí)現(xiàn)聯(lián)網(wǎng)系統(tǒng)中視頻流的互通，采用MPEG-4標(biāo)準(zhǔn)的視頻碼流語法應(yīng)符合ISO/IEC14496-2:2004中的規(guī)定。MPEG-4中簡單檔次不同級別的相應(yīng)標(biāo)識碼見表5（見ISO/IEC14496-2:2004中的表G-1和ISO/IEC14496-2:2004/Amd.2:2005中的規(guī)定）。表5MPEG-4簡單檔次各級別的標(biāo)識碼檔次/級別標(biāo)識碼保留00000000簡單檔次/級別100000001簡單檔次/級別200000010簡單檔次/級別300000011簡單檔次/級別4a00000100簡單檔次/級別500000101保留00000110?00000111簡單檔次/級別000001000MPEG-4的一致性測試 包括比特流一致性測試和解碼器的一致性測試。 比特流一致性測試MPEG-4的一致性比特流（compliantbitstream）是指實(shí)現(xiàn)了ISO/IEC14496-2:2004在通用語法中定義的所有限制的比特流，包括ISO/IEC14496-2:2004中第9章關(guān)于檔次和級別的限制。MPEG-4的一致性比特流應(yīng)滿足如下測試：當(dāng)使用解碼軟件對MPEG-4視頻比特流進(jìn)行解碼時(shí)，不應(yīng)出現(xiàn)任何由比特流引起的錯(cuò)誤或不一致。注：測試中不考慮由于傳輸而產(chǎn)生的錯(cuò)誤。MPEG-4的比特流一致性測試的附加測試見ISO/IEC14496-4:2004中的描述。上述驗(yàn)證比特流一致性用到的解碼軟件可參考ISO/IEC14496-5:2001中指定的軟件。解碼器的一致性測試MPEG-4的視頻解碼器通常指某一特定檔次和級別的解碼器。MPEG-4視頻解碼器的一致性測試見ISO/IEC14496-4：2004中的規(guī)定，其中簡單檔次L5級別的視頻解碼器一致性測試見ISO/IEC14496-4:2004/Amd.10:2005的規(guī)定。驗(yàn)證解碼器一致性用到的軟件可參考ISO/IEC14496-5:2001中指定的軟件。滿足特定檔次和級別的MPEG-4視頻解碼器應(yīng)能正確解碼相應(yīng)檔次和級別的MPEG-4一致性比特流。2.2.3SIP信令中的SDP內(nèi)容規(guī)范SDP定義聯(lián)網(wǎng)系統(tǒng)中SIP消息體中攜帶的SDP內(nèi)容應(yīng)符合RFC2327-SDPSessionDescriptionProtocol的相關(guān)要求。應(yīng)有如下字段：Sessiondescription：v=(protocolversion)o=(owner/creatorandsessionidentifier).s=(sessionname)u=*(URIofdescription)c=*(connectioninformation-notrequiredifincludedinallmedia)Timedescription：t=(timethesessionisactive)Mediadescriptionm=(medianameandtransportaddress)c=*(connectioninformation-optionalifincludedatsession-level)b=*(bandwidthinformation)a=*(zeroormoremediaattributelines)y=*（SSRC）f=*（媒體描述）說明：a字段：啟用RFC4566中對a字段的定義【a=rtpmap:<payloadtype><encodingname>/<clockrate>[/<encodingparameters>]中的<encodingname>，利用該屬性攜帶編碼器廠商名稱（如：大華或?？稻幋a名稱DAHUA或HIKVISION）。該屬性表明該流為某廠商編碼器編碼且是不符合本標(biāo)準(zhǔn)規(guī)定的媒體流，符合本標(biāo)準(zhǔn)規(guī)定的媒體流無需該屬性。例如：a=rtpmap:96DAHUA/90000； a=rtpmap:96HIKVISION/90000。s字段：使用s字段標(biāo)識請求媒體流的操作類型。“Play”代表實(shí)時(shí)點(diǎn)播；“Playback”代表歷史回放；“Download”代表文件下載。u字段：u行應(yīng)填寫視音頻文件的URI。該URI取值有兩種方式：簡捷方式和普通方式。簡捷方式直接采用產(chǎn)生該歷史媒體的媒體源（如某個(gè)攝像頭）的設(shè)備ID（應(yīng)符合6.1.2的規(guī)定）以及相關(guān)參數(shù)，參數(shù)用“：”分隔；普通方式采用http://存儲設(shè)備ID[/文件夾]*/文件名，[/文件夾]*為0－N級文件夾。t字段：當(dāng)回放或下載時(shí)，t行值為開始時(shí)間和結(jié)束時(shí)間，用“”分隔，時(shí)間格式見RFC4566的5.9，開始時(shí)間和結(jié)束時(shí)間均為要回放或下載的音視頻文件錄制時(shí)間段中的某個(gè)時(shí)刻。y字段：為十進(jìn)制整數(shù)字符串，表示SSRC值。格式如下：Dddddddddd（第一位為歷史或?qū)崟r(shí)媒體流的標(biāo)識位，1為歷史，0為實(shí)時(shí)）。f字段：f=v/編碼格式/分辨率/幀率/碼率類型/碼率大小a/編碼格式/碼率大小/采樣率以實(shí)際我司平臺與其他平臺對接過程中的SIP信令為例，下圖中為我司與某廠家平臺交互時(shí)請求實(shí)時(shí)視頻的信令：其中可以看出下方的SDP中m字段和a字段攜帶了3種編碼方式，即國標(biāo)中要求的PS流、H.264流和MEPG4流，這兩個(gè)字段表明我司可以解碼的3中形式，需要一提的是國標(biāo)中也要求的SVAC（PT=99）視頻流格式，主要用在部分ONVIF設(shè)備中，而大多數(shù)主流設(shè)備都沒有按該方式編碼，故我司沒有做對該類碼流的兼容。S字段的值是“Play”表明該信令是請求實(shí)時(shí)點(diǎn)播。2.3國標(biāo)視頻流示例下面我們針對實(shí)際工程中遇見的碼流來了解下在抓包時(shí)我們需要了解的只是，一般情況下我們在vtdu所在服務(wù)器或者CU客戶端抓包，在Wireshark軟件中打開，可以得到如下圖所示的數(shù)據(jù)包：此時(shí)對該數(shù)據(jù)按RTP協(xié)議方式查看，右鍵點(diǎn)擊該包，按如下步驟操作：操作完成后，數(shù)據(jù)包如下圖所示：現(xiàn)在我們可以看到從該包中已經(jīng)可以顯示傳輸方式，視頻源，邏輯序號，和包的時(shí)間等參數(shù)了：PT（payloadtype，負(fù)載類型）=96即表示該視頻流為2.1中的基于PS封裝的音視頻數(shù)據(jù)；SSRC（SynchronizationSourceIdentifier，同步源標(biāo)示符）一般為32位，表示RTP包的起源，一般為源端隨機(jī)分配的號碼；Seq（sequencenumber）

每發(fā)送一個(gè)RTP數(shù)據(jù)包，序列號增加1，表示該包在PS流中的邏輯序號；Time（timestamp）反映了RTP數(shù)據(jù)包中的第一個(gè)比特組的采樣時(shí)間，表示該包所在幀的時(shí)間，同一幀的時(shí)間應(yīng)該一致。值得注意的是，Seq=68的包末尾有一個(gè)Mark標(biāo)示，該標(biāo)示表示此幀為一個(gè)重要幀，下面我們打開該包來看看該標(biāo)示的位置：我們可以看見序號為68的包中RTP協(xié)議第5行為：1…….=Marker：True。該值為True的時(shí)候即為重要幀，此mark表示一般表示一個(gè)完整幀的數(shù)據(jù)邊界。如下圖：序號為536的包是時(shí)間標(biāo)志為101970的完整幀的結(jié)尾，而序號為537至539的三個(gè)數(shù)據(jù)包即可組成一個(gè)完整的數(shù)據(jù)包，在視頻中即可組成一幅完整的畫面。另外，在國標(biāo)中并沒有對mark字段有詳細(xì)的要求，但是目前我司CU或解碼器解碼的時(shí)候還是對會采用字段作參考。國標(biāo)中實(shí)際對一個(gè)完整幀的數(shù)據(jù)邊界的定義在負(fù)載中，也就是除去前面這些包頭后，真正組成一個(gè)畫面的實(shí)際數(shù)據(jù)，如下圖：該包是該時(shí)間標(biāo)示的所有包中的第一個(gè)，可看到該包中的payload負(fù)載部分的前6個(gè)字節(jié)是000001，有這個(gè)前綴的包即表示一個(gè)完整幀的開始。如果符合國標(biāo)標(biāo)準(zhǔn)，所有表示一個(gè)完整幀的第一個(gè)包負(fù)載部分的首6個(gè)字節(jié)都應(yīng)該是000001。 實(shí)際問題淺析在上述兩節(jié)中說明了國標(biāo)對一些協(xié)議和字段的要求。在貴州省平臺項(xiàng)目中可以接觸許多廠商的攝像機(jī)，雖然國標(biāo)已經(jīng)針對視頻流定義了許多要求與協(xié)議，但是在實(shí)際對接中還是可以發(fā)現(xiàn)這些并不完善。下面我們針對實(shí)際工程中遇到的一些問題作簡單的分析：3.1客戶端解碼花屏在對接過程中，因?yàn)槲宜疽呀?jīng)兼容了大部分主流廠商，但是在實(shí)際工程中還是遇見實(shí)時(shí)視頻解碼出現(xiàn)問題的地方，比如在畢節(jié)七星關(guān)發(fā)現(xiàn)客戶端解碼華為的攝像機(jī)時(shí)出現(xiàn)了花屏的現(xiàn)象。在VTDU上抓包分析后可以看出該包數(shù)據(jù)如下：圖1圖2可以從第二幅圖中看出Seq=42052的重要幀后的第一個(gè)幀的時(shí)間標(biāo)識和該mark幀一樣，而第一幅圖中的mark幀后的第一幀與該mark幀的時(shí)間標(biāo)識則不同。以上兩幅圖中的數(shù)據(jù)是在同一數(shù)據(jù)包中，顯然該mark標(biāo)識的打法沒有規(guī)律，但是我司解碼的使用一般還是會參考該值，故由于在視頻流中mark標(biāo)識亂打的原因，平臺在解碼時(shí)還是會誤認(rèn)為mark前后為兩個(gè)完整幀，即使兩個(gè)幀有相同的時(shí)間標(biāo)識，解碼的時(shí)候還是會讓著兩個(gè)畫面在同一時(shí)間顯示出來，導(dǎo)致了花屏。雖然此處對方的mark打法并沒有不符合國標(biāo)，但是我們依然要求了華為修改，未修改前播放視頻時(shí)如下圖： 在華為修改后如下圖所示：3.2解碼器無法解碼在貴州省畢節(jié)七星關(guān)有一個(gè)特別的現(xiàn)象，有一款攝像機(jī)，在平臺客戶端上的圖像一切正常，但是卻不能通過我司平臺上墻。在我司平臺VTDU上抓包分析，并沒有發(fā)現(xiàn)視頻流有明顯的問題，于是轉(zhuǎn)而在信令上找答案，請求視頻的流程同時(shí)在CMS上抓包。在解釋包之前，先說明下國標(biāo)中第三方點(diǎn)播的流程：1：SIP服務(wù)器向媒體服務(wù)器發(fā)送Invite消息，此消息不攜帶SDP消息體；2：媒體服務(wù)器收到SIP服務(wù)器的Invite請求后，回復(fù)200OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體服務(wù)器接收媒體流的IP、端口、媒體格式等內(nèi)容；3：SIP服務(wù)器收到媒體服務(wù)器返回的200OK響應(yīng)后，向媒體流發(fā)送者發(fā)送Invite請求，請求中攜帶消息2中媒體服務(wù)器回復(fù)的200OK響應(yīng)消息體，并且修改s字段為“Play”代表實(shí)時(shí)點(diǎn)播，增加y字段描述SSRC值，f字段描述媒體參數(shù)；4：媒體流發(fā)送者收到SIP服務(wù)器的Invite請求后，回復(fù)200OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC字段等內(nèi)容；5：SIP服務(wù)器收到媒體流發(fā)送者返回的200OK響應(yīng)后，向媒體服務(wù)器發(fā)送ACK請求，請求中攜帶消息4中媒體流發(fā)送者回復(fù)的200OK響應(yīng)消息體，完成與媒體服務(wù)器的Invite會話建立過程；6：SIP服務(wù)器收到媒體流發(fā)送者返回的200OK響應(yīng)后，向媒體流發(fā)送者發(fā)送ACK請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的Invite會話建立過程；7：SIP服務(wù)器向媒體流接收者發(fā)送Invite消息，此消息不攜帶SDP消息體；8：媒體流接收者收到SIP服務(wù)器的Invite請求后，回復(fù)200OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體流接收者接收媒體流的IP、端口、媒體格式等內(nèi)容；9：SIP服務(wù)器收到媒體流接收者返回的200OK響應(yīng)后，向媒體服務(wù)器發(fā)送Invite請求，請求中攜帶消息8中媒體流接收者回復(fù)的200OK響應(yīng)消息體，并且并且修改s字段為“Play”代表實(shí)時(shí)點(diǎn)播，增加y字段描述SSRC值；10：媒體服務(wù)器收到SIP服務(wù)器的Invite請求后，回復(fù)200OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體服務(wù)器發(fā)送媒體流的IP、端口、媒體格式、SSRC字段等內(nèi)容；11：SIP服務(wù)器收到媒體服務(wù)器返回的200OK響應(yīng)后，向媒體流接收者發(fā)送ACK請求，請求中攜帶消息10中媒體服務(wù)器回復(fù)的200OK響應(yīng)消息體，完成與媒體流接收者的Invite會話建立過程；12：SIP服務(wù)器收到媒體服務(wù)器返回的200OK響應(yīng)后，向媒體服務(wù)器發(fā)送ACK請求，請求中不攜帶消息體，完成與媒體服務(wù)器的Invite會話建立過程；13：SIP服務(wù)器向媒體流接收者發(fā)送BYE消息，斷開消息7、8、11建立的同媒體流接收者的Invite會話；14：媒體流接收者收到BYE消息后回復(fù)200OK響應(yīng)，會話斷開；15：SIP服務(wù)器向媒體服務(wù)器發(fā)送BYE消息，斷開消息9、10、12建立的同媒體服務(wù)器的Invite會話；16：媒體服務(wù)器收到BYE消息后回復(fù)200OK響應(yīng)，會話斷開；17：SIP服務(wù)器向媒體服務(wù)器發(fā)送BYE消息，斷開消息1、2、5建立的同媒體服務(wù)器的Invite會話；18：媒體服務(wù)器收到BYE消息后回復(fù)200OK響應(yīng)，會話斷開；19：SIP服務(wù)器向媒體流發(fā)送者發(fā)送BYE消息，斷開消息3、4、6建立的同媒體流發(fā)送者的Invite會話；20：媒體流發(fā)送者收到BYE消息后回復(fù)200OK響應(yīng)，會話斷開。在本問題中最重要的是流程3、4、6。由在CMS中所抓的包分析可得：流程3：流程4：流程6可以看到當(dāng)CMS向前端發(fā)起INVITE請求時(shí)，前端設(shè)備回復(fù)的m字段中顯示98、96兩種方式解碼，即前端告訴中心管理服務(wù)器，PS流和H.264流解碼都可以。而CMS將會把前端告訴它的消息原樣告訴解碼器，我們再來看看承擔(dān)這個(gè)轉(zhuǎn)述任務(wù)的流程11：這是CMS告訴解碼器的信息，m字段里面是轉(zhuǎn)述的前端的解碼要求，96或者98。這就是原因所在，雖然前端給VTDU的是正常的PS流，但是信令中卻說明96或者98都可以解碼?？蛻舳嗽诮獯a時(shí)會自動去檢測碼流，然后按正常的方式解碼，所以無法發(fā)現(xiàn)該前端的信令問題。而解碼在接受到兩種方式解碼要求時(shí)，是不會也無法判斷碼流的，它只能無法分清應(yīng)該用PS流還是H.264流的方式來解碼，所以即使碼流傳輸?shù)搅私獯a器，解碼器也不會去解碼。（以上主要是針對硬件解碼器，我司解碼器是軟解碼，也會對傳輸過來的碼流進(jìn)行判斷）3.3畫面出現(xiàn)卡頓 在平臺建設(shè)過程中，總會有各種各樣的情況出現(xiàn)，而視頻卡頓總是一個(gè)監(jiān)控平臺極易出現(xiàn)的問題，有時(shí)我們會發(fā)現(xiàn)網(wǎng)頁瀏覽的時(shí)