專利名稱：基于mcu的視頻會議系統(tǒng)及其視頻傳輸丟包處理的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及視頻傳輸領(lǐng)域，具體為一種基于MCU的視頻會議系統(tǒng)和一種基于MCU 的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法。
背景技術(shù)：
現(xiàn)有基于MCU(Multipoint Control Unit，即多點(diǎn)控制單元)的視頻會議系統(tǒng)，如 圖1所示，一般包括編碼端、MCU服務(wù)端和解碼端。其中，MCU服務(wù)端是視頻會議系統(tǒng)中的 重要組成部分，它的作用主要是協(xié)調(diào)和控制編碼端與解碼端之間的視頻數(shù)據(jù)傳輸。視頻會 議系統(tǒng)的一項(xiàng)重要功能就是實(shí)現(xiàn)視頻的實(shí)時(shí)傳輸，一般傳輸視頻數(shù)據(jù)所采用的傳輸協(xié)議是 TCP (TransmissionControl Protocol)協(xié)議或者 UDP (User Datagram Protocol)協(xié)議。TCP協(xié)議比較可靠，它是一種面向連接的、基于字節(jié)流的運(yùn)輸層通信協(xié)議。使用 TCP協(xié)議可以保證數(shù)據(jù)傳輸?shù)目煽啃裕沁@種可靠性是建立在丟失數(shù)據(jù)的重傳之上。例 如，發(fā)送端將一個(gè)視頻數(shù)據(jù)段發(fā)送出去的同時(shí)會啟動一個(gè)重發(fā)定時(shí)器，如果該重發(fā)定時(shí)器 超過預(yù)定時(shí)間也沒有接收到接收端的確認(rèn)信息，那么發(fā)射端會重傳該數(shù)據(jù)段。這樣不但增 加了傳輸?shù)臄?shù)據(jù)量，而且犧牲了視頻數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性，造成視頻圖像的延時(shí)。UDP協(xié)議是OSI參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可 靠信息傳送服務(wù)。傳輸數(shù)據(jù)之前源端和終端是不需要建立連接的，發(fā)送數(shù)據(jù)時(shí)也不需要確 認(rèn)是否正確接收。由于使用UDP協(xié)議傳輸數(shù)據(jù)具有發(fā)送效率高、實(shí)時(shí)性強(qiáng)的優(yōu)點(diǎn)，使用UDP 協(xié)議進(jìn)行視頻數(shù)據(jù)傳輸是目前大多數(shù)視頻會議軟件選擇的方式。但是UDP協(xié)議無法保證數(shù) 據(jù)傳輸?shù)目煽啃?，一旦視頻出現(xiàn)數(shù)據(jù)包丟失，那么解碼圖像很可能出現(xiàn)質(zhì)量嚴(yán)重下降，例如 馬賽克的出現(xiàn)。

發(fā)明內(nèi)容
本發(fā)明的目的在于，提出一種基于MCU的視頻會議系統(tǒng)和一種基于MCU的視頻會 議系統(tǒng)中視頻傳輸丟包處理的方法，能夠?qū)崟r(shí)傳輸視頻數(shù)據(jù)，并提高視頻傳輸?shù)目煽啃?。本發(fā)明基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，該基于MCU的視頻 會議系統(tǒng)包括編碼端、MCU服務(wù)端和解碼端，其中，該視頻傳輸丟包處理的方法具體包括步驟Si，所述編碼端對視頻圖像進(jìn)行采樣與編碼，將編碼后獲得的子碼流按UDP 協(xié)議發(fā)送至所述MCU服務(wù)端。步驟S2，所述MCU服務(wù)端對接收到的子碼流進(jìn)行丟包檢測，然后返回反饋信息至 所述編碼端；所述反饋信息包括丟包檢測結(jié)果。步驟S3，所述編碼端根據(jù)所述反饋信息，執(zhí)行丟包處理策略；其中，所述丟包處理 策略包括對發(fā)生丟包的子碼流所屬的圖像組序列，所述編碼端停止向所述MCU服務(wù)端發(fā) 送該圖像組序列的剩余數(shù)據(jù)。步驟S4，所述MCU服務(wù)端將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至所述解碼端。步驟S5，所述解碼端接收到所述子碼流后進(jìn)行丟包檢測和重組，出現(xiàn)子碼流丟包
5時(shí)返回終止數(shù)據(jù)發(fā)送的請求至所述MCU服務(wù)端；所述MCU服務(wù)端根據(jù)所述請求，對發(fā)生丟包 的子碼流所屬的圖像組序列，停止向所述解碼端發(fā)送該圖像組序列的剩余數(shù)據(jù)。步驟S6，所述解碼端對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。本發(fā)明還同時(shí)提出一種基于MCU的視頻會議系統(tǒng)，該基于MCU的視頻會議系統(tǒng)包 括編碼端、MCU服務(wù)端和解碼端。其中，所述編碼端包括用于對視頻圖像進(jìn)行采樣和編碼的采樣編碼模塊、以及用 于對子碼流進(jìn)行發(fā)送與控制的編碼端發(fā)送控制模塊。所述MCU服務(wù)端包括用于對接收的子 碼流進(jìn)行丟包檢測和丟包率統(tǒng)計(jì)的數(shù)據(jù)包分析模塊，以及用于對子碼流進(jìn)行發(fā)送與控制的 MCU發(fā)送控制模塊。所述解碼端包括用于對接收的子碼流進(jìn)行丟包檢測與重組的分析重組 模塊，以及用于對子碼流進(jìn)行解碼的解碼模塊。所述采樣編碼模塊對視頻圖像進(jìn)行采樣與編碼，所述編碼端發(fā)送控制模塊將編碼 后獲得的子碼流按UDP協(xié)議發(fā)送至所述MCU服務(wù)端。所述數(shù)據(jù)包分析模塊對所述MCU服務(wù)端接收到的子碼流進(jìn)行丟包檢測，然后所述 MCU服務(wù)端根據(jù)丟包檢測結(jié)果返回反饋信息至所述編碼端。所述編碼端發(fā)送控制模塊根據(jù)所述反饋信息，執(zhí)行丟包處理策略；其中，所述丟包 處理策略包括對發(fā)生丟包的子碼流所屬的圖像組序列，所述編碼端發(fā)送控制模塊停止向 所述MCU服務(wù)端發(fā)送該圖像組序列的剩余數(shù)據(jù)。所述MCU發(fā)送控制模塊將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至所述解碼端；所 述分析重組模塊接收到所述子碼流后進(jìn)行丟包檢測與重組，所述解碼端在出現(xiàn)子碼流數(shù)據(jù) 包丟失時(shí)返回終止數(shù)據(jù)發(fā)送的請求至所述MCU服務(wù)端；所述MCU發(fā)送控制模塊根據(jù)所述請 求，對發(fā)生丟包的子碼流所屬的圖像組序列，停止向所述解碼端發(fā)送該圖像組序列的剩余 數(shù)據(jù)；所述解碼模塊對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。本發(fā)明的技術(shù)方案，在傳輸子碼流時(shí)都采用UDP協(xié)議進(jìn)行傳輸，充分保證了視頻 數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性；而且MCU服務(wù)端和解碼端在接收數(shù)據(jù)時(shí)都進(jìn)行丟包檢測，在發(fā)生丟包 時(shí)利用消息反饋的手段進(jìn)行反饋，可以停止無用數(shù)據(jù)的發(fā)送，避免利用這些無用數(shù)據(jù)解碼 出現(xiàn)馬賽克的現(xiàn)象，充分降低了帶寬占用，提高視頻傳輸?shù)目煽啃浴?br>

圖1為基于MCU的視頻會議系統(tǒng)結(jié)構(gòu)示意圖；圖2為基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法流程示意圖；圖3為兩路子碼流關(guān)鍵幀交替出現(xiàn)示意圖；圖4為基于MCU的視頻會議系統(tǒng)內(nèi)部組成示意圖；圖5為實(shí)施例4提出的基于MCU的視頻會議系統(tǒng)內(nèi)部組成示意圖。
具體實(shí)施例方式實(shí)施例1 本實(shí)施例是基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，該基于MCU的 視頻會議系統(tǒng)如圖1所示，包括編碼端、MCU服務(wù)端和解碼端。本實(shí)施例中，僅以一個(gè)解碼 端進(jìn)行描述。其中，該視頻傳輸丟包處理的方法具體如圖2所示，包括
步驟Si，編碼端對視頻圖像進(jìn)行采樣與編碼，將編碼后獲得的子碼流按UDP協(xié)議 發(fā)送至MCU服務(wù)端。編碼端對采集的視頻圖像進(jìn)行隔行下采樣，然后將圖像送入H. 264編 碼器進(jìn)行編碼獲得子碼流。步驟S2，MCU服務(wù)端對接收到的子碼流進(jìn)行丟包檢測，然后返回反饋信息至編碼 端。每一路子碼流包含若干數(shù)據(jù)包，每個(gè)數(shù)據(jù)包的包頭都會有唯一的編號-PacketNum， PacketNum是逐一遞增的，MCU服務(wù)端在接收子碼流時(shí)等待指定PacketNum的數(shù)據(jù)包到來， 若發(fā)現(xiàn)收到的數(shù)據(jù)包的PacketNum發(fā)生跳躍，則認(rèn)為當(dāng)前等待的數(shù)據(jù)包已經(jīng)丟失，則會按 TCP協(xié)議發(fā)送反饋消息至編碼端，該反饋消息中包含發(fā)生丟包的子碼流的信息。步驟S3，編碼端根據(jù)反饋信息，確定發(fā)送的子碼流是否發(fā)生丟包情況，若發(fā)生丟包 則執(zhí)行相應(yīng)的丟包處理策略。即對發(fā)生丟包的子碼流所屬的圖像組序列，編碼端停止向MCU 服務(wù)端發(fā)送該圖像組序列的剩余數(shù)據(jù)。這些剩余數(shù)據(jù)屬于無用數(shù)據(jù)，若根據(jù)這些無用的數(shù) 據(jù)進(jìn)行解碼，很可能解碼后獲得的圖像出現(xiàn)馬賽克。同時(shí)，停止這些無用數(shù)據(jù)的發(fā)送，還能 夠節(jié)省網(wǎng)絡(luò)帶寬，降低編碼端和MCU服務(wù)端的帶寬占用。步驟S4，MCU服務(wù)端將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至解碼端。在丟包檢 測后，若未發(fā)生丟包情況，則MCU服務(wù)端將接收的完整子碼流傳輸至解碼端；若發(fā)生丟包情 況，因?yàn)橐呀?jīng)停止該子碼流所述圖像組序列的剩余數(shù)據(jù)的發(fā)送，則將已接收的子碼流中的 數(shù)據(jù)發(fā)送至解碼端。步驟S5，解碼端接收到子碼流后進(jìn)行丟包檢測和重組，解碼端進(jìn)行丟包檢測的過 程與MCU服務(wù)端進(jìn)行丟包檢測的過程相同，數(shù)據(jù)包重組是指將屬于同一幀的數(shù)據(jù)包視頻數(shù) 據(jù)組合在一起，每個(gè)數(shù)據(jù)包包頭都有一個(gè)幀索引-Framelndex，可以利用這個(gè)索引將同幀的 所有數(shù)據(jù)包組合在一起。同樣，丟包檢測之后，若發(fā)生子碼流丟包的情況，解碼端返回一個(gè) 請求至MCU服務(wù)端，要求終止數(shù)據(jù)發(fā)送。MCU服務(wù)端根據(jù)返回的這個(gè)請求，對發(fā)生丟包的子 碼流所屬的圖像組序列，停止向解碼端發(fā)送該圖像組序列的剩余數(shù)據(jù)。這里，同樣起到避免 使用無用數(shù)據(jù)解碼使解碼圖像出現(xiàn)馬賽克的情況，并同時(shí)降低了 MCU服務(wù)端和解碼端的帶 寬占用。步驟S6，解碼端對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。通過本實(shí)施例的描述，該視頻傳輸丟包處理的方法使用UDP協(xié)議進(jìn)行視頻數(shù)據(jù)傳 輸保證視頻的實(shí)時(shí)性，并在子碼流發(fā)生丟包情況時(shí)通過消息反饋的手段要求停止無用數(shù)據(jù) 的發(fā)送，降低了帶寬占用，也提高了視頻傳輸?shù)目煽啃浴?shí)施例2 本實(shí)施例同樣描述一種基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，該 基于MCU的視頻會議系統(tǒng)如圖1所示，包括編碼端、MCU服務(wù)端和解碼端，其中，該視頻傳輸 丟包處理的方法具體包括步驟Si，編碼端對視頻圖像進(jìn)行采樣與編碼，將編碼后獲得的子碼流按UDP協(xié)議 發(fā)送至MCU服務(wù)端。編碼端對采集的視頻圖像進(jìn)行隔行下采樣，然后將采樣獲得的圖像分 成第一子圖像和第二子圖像，再將這兩個(gè)子圖像分別放入不同的H. 264編碼器進(jìn)行編碼， 編碼得出的碼流稱作第一子碼流和第二子碼流。在上述編碼過程中，可以對子碼流關(guān)鍵幀的出現(xiàn)進(jìn)行控制，S卩，將兩個(gè)子碼流的 關(guān)鍵幀周期都設(shè)置為相同值，但關(guān)鍵幀的出現(xiàn)的時(shí)間是交替的，如圖3所示，在圖3中，IDR(Instantaneous Decoding Refresh)表示即時(shí)解碼刷新。用GopSize表示關(guān)鍵幀周 期，編碼端將第一子圖像和第二子圖像關(guān)鍵幀的間隔幀數(shù)都設(shè)置為^^，然后根據(jù)幀序
FrameNum進(jìn)行調(diào)整，具體為在FrameM^時(shí)，編碼端只對第一子圖像進(jìn)行編碼；
在FrameiVMm^^^時(shí)，編碼端對第一子圖像和第二子圖像都進(jìn)行編碼。編碼端再將編 碼后獲得的這兩路子碼流按UDP協(xié)議發(fā)送至MCU服務(wù)端。步驟S2，MCU服務(wù)端對接收到的子碼流進(jìn)行丟包檢測和丟包率的統(tǒng)計(jì)，然后返回 反饋信息至編碼端。本步驟中，MCU服務(wù)端進(jìn)行丟包檢測的過程可以參考實(shí)施例1中步驟 S2對丟包檢測的描述，同樣是檢測數(shù)據(jù)包的PacketNum是否發(fā)生跳躍，若發(fā)生跳躍則認(rèn)為 當(dāng)前等待的數(shù)據(jù)包已經(jīng)丟失。同時(shí)，MCU服務(wù)端還會按照預(yù)定的時(shí)間間隔(例如30秒)進(jìn) 行丟包率的統(tǒng)計(jì)，丟包率按照公式(ι-實(shí)際接收數(shù)據(jù)包數(shù)/應(yīng)該接收數(shù)據(jù)包數(shù))X 100%進(jìn) 行計(jì)算。然后MCU服務(wù)端將包含丟包檢測結(jié)果和丟包率的反饋信息以TCP方式發(fā)送至編碼 端。步驟S3，編碼端根據(jù)反饋信息，確定是否哪路子碼流發(fā)生丟包，并按照發(fā)生丟包的 子碼流以及丟包率執(zhí)行丟包處理策略。丟包處理策略包括1)若第一子碼流發(fā)生丟包情況，則編碼端停止向MCU服務(wù)端發(fā)送第一子碼流所屬 圖像組序列的剩余數(shù)據(jù)。若第二子碼流發(fā)生丟包情況，則采取同樣的處理方式。2)根據(jù)返回的不同丟包率，執(zhí)行以下處理策略當(dāng)丟包率為0% -10%時(shí)，編碼端不做任何處理；當(dāng)丟包率為10% -20%時(shí)，編碼端將對應(yīng)同一幀的兩個(gè)子碼流的數(shù)據(jù)包發(fā)送間隔 進(jìn)行設(shè)置，該發(fā)送間隔最小為1幀，最大為5幀，即發(fā)送間隔在1幀以上并且在5幀以下；當(dāng)丟包率為20% -30%時(shí)，編碼端在第一子碼流和第二子碼流中任意選擇一路子 碼流發(fā)送至MCU服務(wù)端；此種情況下，丟包率較為嚴(yán)重，除了停止無用數(shù)據(jù)的發(fā)送，再次發(fā) 送子碼流時(shí)，只傳輸一路子碼流數(shù)據(jù)，以保證視頻的流暢性；當(dāng)丟包率大于30%時(shí)，編碼端在第一子碼流和第二子碼流中任意選擇一路子碼 流，并將該子碼流的編碼幀率降低為IOfps以上，再將編碼幀率降低后的子碼流發(fā)送至MCU 服務(wù)端。當(dāng)丟包率在30%以上，屬于丟包率非常嚴(yán)重的情況，此時(shí)僅傳輸一路子碼流是不夠 的，還需要降低編碼幀率，使降低編碼幀率后的子碼流能夠適應(yīng)惡劣的網(wǎng)絡(luò)帶寬，來保證視 頻的流暢性。步驟S4，MCU服務(wù)端將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至解碼端。步驟S5，解碼端接收到子碼流后進(jìn)行丟包檢測和重組，在子碼流丟包時(shí)返回終止 數(shù)據(jù)發(fā)送的請求至MCU服務(wù)端；MCU服務(wù)端根據(jù)請求，對發(fā)生丟包的子碼流所屬的圖像組序 列，停止向解碼端發(fā)送該圖像組序列的剩余數(shù)據(jù)。本步驟丟包檢測的過程和步驟S2中丟包 檢測過程相同。解碼端對子碼流進(jìn)行重組的過程也與實(shí)施例1中步驟S5中對子碼流進(jìn)行 重組的過程相同，即根據(jù)幀索引Framelndex將同幀的所有數(shù)據(jù)包的視頻數(shù)據(jù)組合在一起。步驟S6，解碼端對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。本實(shí)施例 中，解碼端接收到的子碼流包括兩種情況A)解碼端接收到兩路子碼流，即當(dāng)前幀的第一子碼流和第二子碼流的完整數(shù)據(jù)都被接收到，則解碼端對兩個(gè)子碼流的數(shù)據(jù)進(jìn)行解碼，然后再對解碼后的圖像進(jìn)行拼接處理， 再對拼接處理后的圖像進(jìn)行濾波處理，獲得質(zhì)量最好的圖像。B)解碼端僅接收到一路子碼流，此處以僅接收到第一子碼流為例，如果當(dāng)前幀的 第一子碼流的完整數(shù)據(jù)被接收到，則解碼端對第一子碼流中的數(shù)據(jù)進(jìn)行解碼后，再對解碼 獲得的圖像進(jìn)行圖像還原處理，例如，可以采用隔行插值的辦法進(jìn)行圖像還原過程，獲得可 以接受的圖像。傳統(tǒng)視頻會議系統(tǒng)中使用的是單流模式，當(dāng)一個(gè)GOP (Group of Pictures，圖像 組)序列中出現(xiàn)數(shù)據(jù)包丟失，為了保證圖像不出現(xiàn)質(zhì)量下降的情況，解碼端只能放棄GOP序 列后續(xù)數(shù)據(jù)的解碼，因此視頻的流暢性較差，并且浪費(fèi)帶寬。但通過上述描述，本實(shí)施例采 用雙流模式進(jìn)行傳輸，并且利用相應(yīng)的反饋和丟包處理策略，使得解碼端在接收到兩路子 碼流的情況能夠獲得質(zhì)量最好的圖像，即使丟失了一路子碼流，也可以利用另外一路子碼 流還原出令人可以接受的視頻圖像，盡可能地保證視頻流暢性；同時(shí)，利用MCU服務(wù)端和解 碼端的消息反饋，能夠停止無用數(shù)據(jù)的發(fā)送，盡最大可能降低帶寬占用。實(shí)施例3 本實(shí)施例提出一種基于MCU的視頻會議系統(tǒng)，該基于MCU的視頻會議系統(tǒng)包括編 碼端、MCU服務(wù)端和解碼端。其中，如圖4所示，編碼端包括用于對視頻圖像進(jìn)行采樣和編碼的采樣編碼模塊、 以及用于對子碼流進(jìn)行發(fā)送與控制的編碼端發(fā)送控制模塊。MCU服務(wù)端包括用于對接收的 子碼流進(jìn)行丟包檢測和丟包率統(tǒng)計(jì)的數(shù)據(jù)包分析模塊，以及用于對子碼流進(jìn)行發(fā)送與控制 的MCU發(fā)送控制模塊。解碼端包括用于對接收的子碼流進(jìn)行丟包檢測與重組的分析重組模 塊，以及用于對子碼流進(jìn)行解碼的解碼模塊。基于MCU的視頻會議系統(tǒng)工作過程如下采樣編碼模塊對視頻圖像進(jìn)行隔行下采樣，然后將采樣的圖像送入H. 264編碼器 進(jìn)行編碼，編碼端發(fā)送控制模塊將編碼獲得的子碼流按UDP協(xié)議發(fā)送至MCU服務(wù)端。數(shù)據(jù)包分析模塊對MCU服務(wù)端接收到的子碼流進(jìn)行丟包檢測，然后MCU服務(wù)端根 據(jù)丟包檢測結(jié)果返回反饋信息至編碼端。每一路子碼流包含若干數(shù)據(jù)包，每個(gè)數(shù)據(jù)包的 包頭都會有唯一的編號-PacketNum，PacketNum是逐一遞增的，數(shù)據(jù)包分析模塊等待指定 PacketNum的數(shù)據(jù)包到來，若發(fā)現(xiàn)收到的數(shù)據(jù)包的PacketNum發(fā)生跳躍，則認(rèn)為當(dāng)前等待的 數(shù)據(jù)包已經(jīng)丟失，MCU服務(wù)端按TCP協(xié)議發(fā)送反饋消息至編碼端，該反饋消息中包含發(fā)生丟 包的子碼流的信息。編碼端發(fā)送控制模塊根據(jù)反饋信息，確定發(fā)生丟包的子碼流，然后執(zhí)行丟包處理 策略，即對發(fā)生丟包的子碼流所屬的圖像組序列，編碼端發(fā)送控制模塊停止向MCU服務(wù)端 發(fā)送該圖像組序列的剩余數(shù)據(jù)。這些剩余數(shù)據(jù)屬于無用數(shù)據(jù)，若根據(jù)這些無用的數(shù)據(jù)進(jìn)行 解碼，很可能解碼后獲得的圖像出現(xiàn)馬賽克。同時(shí)，停止這些無用數(shù)據(jù)的發(fā)送，還能夠節(jié)省 網(wǎng)絡(luò)帶寬。MCU發(fā)送控制模塊將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至解碼端。在丟包檢測 后，若未發(fā)生丟包情況，則MCU發(fā)送控制模塊將接收的完整子碼流傳輸至解碼端；若發(fā)生丟 包情況，因?yàn)橐呀?jīng)停止該子碼流所述圖像組序列的剩余數(shù)據(jù)的發(fā)送，則MCU發(fā)送控制模塊 將已接收的子碼流中的數(shù)據(jù)發(fā)送至解碼端。
9
然后在解碼端中，分析重組模塊接收到子碼流后進(jìn)行丟包檢測與重組。此處分析 重組模塊進(jìn)行丟包檢測的過程與MCU服務(wù)端中數(shù)據(jù)包分析模塊進(jìn)行丟包檢測的過程相同。 數(shù)據(jù)包重組是指將屬于同一幀的數(shù)據(jù)包視頻數(shù)據(jù)組合在一起，每個(gè)數(shù)據(jù)包包頭都有一個(gè)幀 索引-Framelndex，可以利用這個(gè)索引將同幀的所有數(shù)據(jù)包組合在一起。解碼端在發(fā)生子碼流數(shù)據(jù)包丟失時(shí)返回請求至MCU服務(wù)端，要求終止剩余數(shù)據(jù)的 發(fā)送。MCU發(fā)送控制模塊根據(jù)請求，對發(fā)生丟包的子碼流所屬的圖像組序列，停止向解碼端 發(fā)送該圖像組序列的剩余數(shù)據(jù)。這樣能夠避免使用無用數(shù)據(jù)解碼使解碼圖像出現(xiàn)馬賽克的 情況，并同時(shí)降低了 MCU服務(wù)端和解碼端的帶寬占用。解碼模塊對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。無論是編碼端發(fā)送控制模塊還是MCU發(fā)送控制模塊，都使用UDP協(xié)議進(jìn)行視頻數(shù) 據(jù)傳輸，以保證視頻傳輸?shù)膶?shí)時(shí)性。而在發(fā)生子碼流丟包情況時(shí)MCU服務(wù)端和解碼端都通 過消息反饋的手段要求停止無用數(shù)據(jù)的發(fā)送，降低了帶寬占用，盡可能保證視頻傳輸?shù)牧?暢性。實(shí)施例4 本實(shí)施例提出一種基于MCU的視頻會議系統(tǒng)，該基于MCU的視頻會議系統(tǒng)包括編 碼端、MCU服務(wù)端和解碼端。如圖5所示，編碼端包括用于對視頻圖像進(jìn)行采樣和編碼的采樣編碼模塊、用于 對子碼流進(jìn)行發(fā)送與控制的編碼端發(fā)送控制模塊、以及對圖像數(shù)據(jù)的編碼進(jìn)行編碼控制的 編碼控制模塊。其中，采樣編碼模塊包含兩個(gè)不同的編碼器。MCU服務(wù)端包括用于對接收的子碼流進(jìn)行丟包檢測和丟包率統(tǒng)計(jì)的數(shù)據(jù)包分析模 塊，以及用于對子碼流進(jìn)行發(fā)送與控制的MCU發(fā)送控制模塊。解碼端包括用于對接收的子碼流進(jìn)行丟包檢測與重組的分析重組模塊，用于對子 碼流進(jìn)行解碼的解碼模塊、用于對解碼后的圖像進(jìn)行拼接處理的拼接模塊、用于對拼接處 理后的圖像進(jìn)行濾波處理的濾波模塊、以及用于對解碼后的圖像進(jìn)行圖像還原處理的圖像 還原模塊。本實(shí)施例將采樣“雙流”模式進(jìn)行視頻傳輸，即數(shù)據(jù)是以兩路碼流的方式，所以 對應(yīng)不同的接收狀況，將采用不同的模塊來對解碼后的圖像進(jìn)行處理，以獲得所需的視頻 圖像。具體工作過程如下編碼端中，采樣編碼模塊對視頻圖像進(jìn)行隔行下采樣，然后將采樣的圖像分成 第一子圖像和第二子圖像，將這兩幅子圖像分別送入不同的H. 264編碼器進(jìn)行編碼。以 GopSize表示關(guān)鍵幀周期，F(xiàn)rameNum表示幀序，編碼控制模塊將第一子圖像和第二子
圖像關(guān)鍵幀的間隔幀數(shù)都設(shè)置為"^^，再根據(jù)幀序進(jìn)行相應(yīng)調(diào)整編碼控制模塊在
時(shí)發(fā)送第一控制指令至采樣編碼模塊，采樣編碼模塊只對第一子圖
像進(jìn)行編碼；編碼控制模塊在FrameM^時(shí)發(fā)送第二控制指令至采樣編碼模塊，
采樣編碼模塊對第一子圖像和第二子圖像都進(jìn)行編碼。其中，第一控制指令和第二控制指 令僅僅是為了描述的方便，并不構(gòu)成對本發(fā)明技術(shù)方案的限定。編碼端發(fā)送控制模塊將編 碼獲得的第一子碼流和第二子碼流按UDP協(xié)議發(fā)送至MCU服務(wù)端。
10
在MCU服務(wù)端，數(shù)據(jù)包分析模塊對MCU服務(wù)端接收到的子碼流進(jìn)行丟包檢測和丟 包率的統(tǒng)計(jì)，丟包檢測的過程與實(shí)施例3中介紹的丟包檢測過程相同，即檢測收到的數(shù)據(jù) 包的PacketNum是否發(fā)生跳躍，若發(fā)生跳躍則認(rèn)為當(dāng)前等待的數(shù)據(jù)包已經(jīng)丟失。MCU服務(wù)端 按TCP協(xié)議發(fā)送包含發(fā)生丟包的子碼流信息和丟包率的反饋消息至編碼端。編碼端發(fā)送控制模塊根據(jù)反饋信息，確定發(fā)生丟包的子碼流以及相應(yīng)的丟包率， 然后執(zhí)行丟包處理策略。其中，丟包處理策略具體包括1)若第一子碼流發(fā)生丟包情況，則編碼端發(fā)送控制模塊停止向MCU服務(wù)端發(fā)送第 一子碼流所屬圖像組序列的剩余數(shù)據(jù)。若第二子碼流發(fā)生丟包情況，則采取同樣的處理方 式。2)根據(jù)返回的不同丟包率，執(zhí)行以下處理策略當(dāng)丟包率為0% -10%時(shí)，編碼端發(fā)送控制模塊不做任何處理；當(dāng)丟包率為10% -20%時(shí)，編碼端發(fā)送控制模塊將對應(yīng)同一幀的兩個(gè)子碼流的數(shù) 據(jù)包發(fā)送間隔進(jìn)行設(shè)置，該發(fā)送間隔最小為1幀，最大為5幀，即發(fā)送間隔在1幀以上并且 在5幀以下；當(dāng)丟包率為20% -30%時(shí)，編碼端發(fā)送控制模塊在第一子碼流和第二子碼流中任 意選擇一路子碼流發(fā)送至MCU服務(wù)端；此種情況下，丟包率較為嚴(yán)重，除了停止無用數(shù)據(jù)的 發(fā)送，再次發(fā)送子碼流時(shí)，僅僅傳輸一路子碼流數(shù)據(jù)，保證視頻的流暢性；當(dāng)丟包率大于30%時(shí)，編碼端發(fā)送控制模塊在第一子碼流和第二子碼流中任意選 擇一路子碼流，并將該子碼流的編碼幀率降低為IOfps以上，再將編碼幀率降低后的子碼 流發(fā)送至MCU服務(wù)端。當(dāng)丟包率在30%以上，屬于丟包率非常嚴(yán)重的情況，此時(shí)僅傳輸一路 子碼流是不夠的，還需要降低編碼幀率，使降低編碼幀率后的子碼流能夠適應(yīng)惡劣的網(wǎng)絡(luò) 帶寬，來保證視頻的流暢性。MCU發(fā)送控制模塊將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至解碼端。在丟包檢測 后，若未發(fā)生丟包情況，則MCU發(fā)送控制模塊將接收的完整子碼流傳輸至解碼端；若發(fā)生丟 包情況，因?yàn)橐呀?jīng)停止該子碼流所述圖像組序列的剩余數(shù)據(jù)的發(fā)送，則MCU發(fā)送控制模塊 將已接收的子碼流中的數(shù)據(jù)發(fā)送至解碼端。在解碼端中，分析重組模塊接收到子碼流后進(jìn)行丟包檢測與重組。分析重組模塊 進(jìn)行丟包檢測的過程與MCU服務(wù)端中數(shù)據(jù)包分析模塊進(jìn)行丟包檢測的過程相同。數(shù)據(jù)包重 組與實(shí)施例3中對重組過程的介紹相同，即根據(jù)幀索引Framelndex將同幀的所有數(shù)據(jù)包組
合在一起。解碼端在發(fā)生子碼流數(shù)據(jù)包丟失時(shí)返回請求至MCU服務(wù)端，要求終止剩余數(shù)據(jù)的 發(fā)送。MCU發(fā)送控制模塊根據(jù)請求，對發(fā)生丟包的子碼流所屬的圖像組序列，停止向解碼端 發(fā)送該圖像組序列的剩余數(shù)據(jù)。這樣能夠避免使用無用數(shù)據(jù)解碼使解碼圖像出現(xiàn)馬賽克的 情況，并同時(shí)降低了 MCU服務(wù)端和解碼端的帶寬占用。解碼模塊對丟包檢測與重組后的子碼流進(jìn)行解碼，這里包括兩種情況A)解碼端接收到兩路子碼流，即當(dāng)前幀的第一子碼流和第二子碼流的完整數(shù)據(jù)都 被接收到，則解碼模塊對兩個(gè)子碼流的數(shù)據(jù)進(jìn)行解碼，然后由拼接模塊對解碼后的圖像進(jìn) 行拼接處理，再由濾波模塊對拼接處理后的圖像進(jìn)行濾波處理，獲得質(zhì)量最好的圖像。B)解碼端僅接收到一路子碼流，此處以僅接收到第一子碼流為例，如果當(dāng)前幀的第一子碼流的完整數(shù)據(jù)被接收到，則解碼模塊對第一子碼流中的數(shù)據(jù)進(jìn)行解碼后，再由圖 像還原模塊對解碼獲得的圖像進(jìn)行圖像還原處理，例如，可以采用隔行插值的辦法進(jìn)行圖 像還原過程，獲得可以接受的圖像。通過UDP協(xié)議進(jìn)行傳輸，保證了視頻傳輸?shù)膶?shí)時(shí)性，并且使用雙流模式結(jié)合相應(yīng) 的反饋機(jī)制和策略調(diào)整，解碼端在接收到兩路碼流的情況下能夠獲得最好的視頻圖像，而 在僅接收到一路碼流，采用圖像還原處理還原出能夠接受的視頻圖像，盡可能地保證視頻 的流暢性。以上所述的本發(fā)明實(shí)施方式，并不構(gòu)成對本發(fā)明保護(hù)范圍的限定。任何在本發(fā)明 的精神和原則之內(nèi)所作的修改、等同替換和改進(jìn)等，均應(yīng)包含在本發(fā)明的權(quán)利要求保護(hù)范 圍之內(nèi)。
權(quán)利要求
一種基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，該基于MCU的視頻會議系統(tǒng)包括編碼端、MCU服務(wù)端和解碼端，其特征在于，該視頻傳輸丟包處理的方法具體包括步驟S1，所述編碼端對視頻圖像進(jìn)行采樣與編碼，將編碼后獲得的子碼流按UDP協(xié)議發(fā)送至所述MCU服務(wù)端；步驟S2，所述MCU服務(wù)端對接收到的子碼流進(jìn)行丟包檢測，然后返回反饋信息至所述編碼端；所述反饋信息包括丟包檢測結(jié)果；步驟S3，所述編碼端根據(jù)所述反饋信息，執(zhí)行丟包處理策略；其中，所述丟包處理策略包括對發(fā)生丟包的子碼流所屬的圖像組序列，所述編碼端停止向所述MCU服務(wù)端發(fā)送該圖像組序列的剩余數(shù)據(jù)；步驟S4，所述MCU服務(wù)端將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至所述解碼端；步驟S5，所述解碼端接收到所述子碼流后進(jìn)行丟包檢測和重組，出現(xiàn)子碼流丟包時(shí)返回終止數(shù)據(jù)發(fā)送的請求至所述MCU服務(wù)端；所述MCU服務(wù)端根據(jù)所述請求，對發(fā)生丟包的子碼流所屬的圖像組序列，停止向所述解碼端發(fā)送該圖像組序列的剩余數(shù)據(jù)；步驟S6，所述解碼端對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。
2.根據(jù)權(quán)利要求1基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 所述步驟Sl具體包括所述編碼端對視頻圖像進(jìn)行采樣，將采樣獲得的圖像分成第一子圖像和第二子圖像并 分別送入不同的編碼器進(jìn)行編碼，將編碼后獲得的第一子碼流和第二子碼流按UDP協(xié)議發(fā) 送至所述MCU服務(wù)端；所述步驟S6具體包括若在丟包檢測與重組后所述解碼端接收到所述第一子碼流和所述第二子碼流，則所述 解碼端對所述第一子碼流和所述第二子碼流中的數(shù)據(jù)進(jìn)行解碼，并將解碼后的圖像進(jìn)行拼 接處理，獲得視頻圖像；若在丟包檢測與重組后所述解碼端僅接收到所述第一子碼流或所述第二子碼流，則所 述解碼端對接收到的所述第一子碼流或所述第二子碼流進(jìn)行解碼，對解碼后的圖像進(jìn)行圖 像還原處理，獲得視頻圖像。
3.根據(jù)權(quán)利要求2基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 所述步驟Sl中所述編碼端對所述第一子圖像和所述第二子圖像進(jìn)行編碼的過程具體包括所述編碼端將所述第一子圖像和所述第二子圖像關(guān)鍵幀的間隔幀數(shù)都設(shè)置為"^^；時(shí)，所述編碼端只對第一子圖像進(jìn)行編碼;^FrameNum>G°P^Ze時(shí)，所述編碼端對所述第一子圖像和所述第二子圖像都進(jìn)行編碼；其中，GopSize表示關(guān)鍵 幀周期，F(xiàn)rameNum表示幀序。
4.根據(jù)權(quán)利要求3基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 步驟S2具體包括所述MCU服務(wù)端接收到所述子碼流后進(jìn)行丟包檢測并進(jìn)行丟包率的統(tǒng)計(jì)，然后返回反 饋信息至所述編碼端；其中，所述反饋信息包括丟包檢測結(jié)果和丟包率；步驟S3中執(zhí)行丟包處理策略的過程還包括 當(dāng)所述丟包率為0% -10%時(shí)，所述編碼端不做任何處理；當(dāng)所述丟包率為10% -20%時(shí)，所述編碼端將對應(yīng)同一幀的兩個(gè)子碼流的數(shù)據(jù)包發(fā)送 間隔設(shè)置為該發(fā)送間隔在1幀以上并且在5幀以下；當(dāng)所述丟包率為20% -30%時(shí)，所述編碼端在所述第一子碼流和所述第二子碼流中任 意選擇一路子碼流發(fā)送至所述MCU服務(wù)端；當(dāng)所述丟包率大于30%時(shí)，所述編碼端在所述第一子碼流和所述第二子碼流中任意選 擇一路子碼流，并將該子碼流的編碼幀率降低為IOfps以上，再將編碼幀率降低后的子碼 流發(fā)送至所述MCU服務(wù)端。
5.根據(jù)權(quán)利要求4基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 步驟S2中所述MCU服務(wù)端按照預(yù)定的時(shí)間間隔進(jìn)行丟包率的統(tǒng)計(jì)。
6.根據(jù)權(quán)利要求1或5基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征 在于，所述編碼端采用隔行下采樣的方法對視頻圖像進(jìn)行采樣。
7.根據(jù)權(quán)利要求1基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 步驟S2中所述MCU服務(wù)端返回反饋信息至所述編碼端的過程為所述MCU服務(wù)端按照TCP協(xié)議發(fā)送反饋信息至所述編碼端；步驟S5中所述解碼端返回終止數(shù)據(jù)發(fā)送的請求至所述MCU服務(wù)端的過程包括所述 MCU服務(wù)端按照TCP協(xié)議發(fā)送終止數(shù)據(jù)發(fā)送的請求至所述編碼端。
8.根據(jù)權(quán)利要求2基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 步驟S6中，若在丟包檢測與重組后所述解碼端接收到所述第一子碼流和所述第二子碼流， 則所述解碼端對拼接處理后的圖像進(jìn)行濾波處理，獲得濾波處理后的視頻圖像。
9.根據(jù)權(quán)利要求2基于MCU的視頻會議系統(tǒng)中視頻傳輸丟包處理的方法，其特征在于， 步驟S6中，若在丟包檢測與重組后所述解碼端僅接收到所述第一子碼流或所述第二子碼 流，則所述解碼端采用隔行插值的方法對解碼后的圖像進(jìn)行圖像還原處理，獲得圖像還原 處理后的視頻圖像。
10.一種基于MCU的視頻會議系統(tǒng)，該基于MCU的視頻會議系統(tǒng)包括編碼端、MCU服務(wù) 端和解碼端，其特征在于，所述編碼端包括用于對視頻圖像進(jìn)行采樣和編碼的采樣編碼模塊、以及用于對子碼流 進(jìn)行發(fā)送與控制的編碼端發(fā)送控制模塊；所述MCU服務(wù)端包括用于對接收的子碼流進(jìn)行丟包檢測和丟包率統(tǒng)計(jì)的數(shù)據(jù)包分析 模塊，以及用于對子碼流進(jìn)行發(fā)送與控制的MCU發(fā)送控制模塊；所述解碼端包括用于對接收的子碼流進(jìn)行丟包檢測與重組的分析重組模塊，以及用于 對子碼流進(jìn)行解碼的解碼模塊；所述采樣編碼模塊對視頻圖像進(jìn)行采樣與編碼，所述編碼端發(fā)送控制模塊將編碼后獲 得的子碼流按UDP協(xié)議發(fā)送至所述MCU服務(wù)端；所述數(shù)據(jù)包分析模塊對所述MCU服務(wù)端接收到的子碼流進(jìn)行丟包檢測，然后所述MCU 服務(wù)端根據(jù)丟包檢測結(jié)果返回反饋信息至所述編碼端；所述編碼端發(fā)送控制模塊根據(jù)所述反饋信息，執(zhí)行丟包處理策略；其中，所述丟包處理 策略包括對發(fā)生丟包的子碼流所屬的圖像組序列，所述編碼端發(fā)送控制模塊停止向所述MCU服務(wù)端發(fā)送該圖像組序列的剩余數(shù)據(jù)；所述MCU發(fā)送控制模塊將丟包檢測后的子碼流 按UDP協(xié)議發(fā)送至所述解碼端；所述分析重組模塊接收到所述子碼流后進(jìn)行丟包檢測與重 組，所述解碼端在出現(xiàn)子碼流數(shù)據(jù)包丟失時(shí)返回終止數(shù)據(jù)發(fā)送的請求至所述MCU服務(wù)端； 所述MCU發(fā)送控制模塊根據(jù)所述請求，對發(fā)生丟包的子碼流所屬的圖像組序列，停止向所 述解碼端發(fā)送該圖像組序列的剩余數(shù)據(jù)；所述解碼模塊對丟包檢測與重組后的子碼流進(jìn)行 解碼獲得視頻圖像。
全文摘要
本發(fā)明視頻傳輸丟包處理的方法，包括編碼端采樣與編碼，將獲得的子碼流按UDP協(xié)議發(fā)送至MCU服務(wù)端；MCU服務(wù)端對子碼流進(jìn)行丟包檢測，然后返回反饋信息至編碼端；編碼端根據(jù)反饋信息，執(zhí)行丟包處理策略；MCU服務(wù)端將丟包檢測后的子碼流按UDP協(xié)議發(fā)送至解碼端；解碼端進(jìn)行丟包檢測和重組，在子碼流丟包時(shí)返回終止數(shù)據(jù)發(fā)送的請求至MCU服務(wù)端，MCU服務(wù)端接收該請求并執(zhí)行；解碼端對丟包檢測與重組后的子碼流進(jìn)行解碼獲得視頻圖像。本發(fā)明基于MCU的視頻會議系統(tǒng)，包括采樣編碼模塊、編碼端發(fā)送控制模塊、數(shù)據(jù)包分析模塊、MCU發(fā)送控制模塊、分析重組模塊和解碼模塊。本發(fā)明既能提高傳輸?shù)膶?shí)時(shí)性，還能提高傳輸?shù)目煽啃浴?br> 文檔編號H04N7/26GK101883240SQ20101019748
公開日2010年11月10日 申請日期2010年6月9日 優(yōu)先權(quán)日2010年6月9日
發(fā)明者石金川 申請人:廣東威創(chuàng)視訊科技股份有限公司