在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Jitsi實(shí)現(xiàn)自動(dòng)減少轉(zhuǎn)發(fā)視頻層,從而降低客戶端CPU和帶寬使用

LiveVideoStack ? 來源:未知 ? 作者:李倩 ? 2018-08-10 14:43 ? 次閱讀

本文來自Jitsi Videobridge SFU的后端開發(fā)人員之一Brian Baldino,他過去在思科和Highfive工作過,擁有豐富的視頻會議產(chǎn)品研發(fā)經(jīng)驗(yàn)。他分享了在Jitsi實(shí)現(xiàn)自動(dòng)減少轉(zhuǎn)發(fā)視頻層,從而降低客戶端CPU和帶寬使用。

對高流量的流控制(來源:usbr.gov)

大多數(shù)人可能都熟悉典型的SFU風(fēng)格的用戶界面,該界面最初是在Google Hangouts的消費(fèi)者市場中推廣的,并由Jitsi Meet和其他服務(wù)部門使用。絕大多數(shù)屏幕空間的正面和中心是當(dāng)前活躍的演講者的視頻。所有其他參與者都可以在他們自己的縮略圖中看到,通常在右側(cè)或底部。我們想讓活躍的演講者的視頻在中間看起來很棒,因此分辨率很高。底部/右側(cè)的縮略圖會很小,因此高分辨率會浪費(fèi)帶寬。為了優(yōu)化這些不同的模式,我們需要每個(gè)發(fā)送者視頻的多個(gè)分辨率。值得慶幸的是,這已經(jīng)是一個(gè)用聯(lián)播解決了的問題!

通過聯(lián)播,所有發(fā)送者編碼3種不同的分辨率并將其發(fā)送到SFU。SFU決定將哪些流轉(zhuǎn)發(fā)到每個(gè)接收器。如果參與者是活躍的發(fā)言者,我們會嘗試并將他們發(fā)送給其他人的最高質(zhì)量的流轉(zhuǎn)發(fā)到他們的主界面上。如果要在右側(cè)的縮略圖中看到參與者,那么我們就會轉(zhuǎn)發(fā)他們的最低質(zhì)量的流。

聯(lián)播權(quán)衡

聯(lián)播是優(yōu)化下載帶寬的絕佳機(jī)制。然而,與生活中的大多數(shù)事情一樣,聯(lián)播涉及權(quán)衡——編碼3個(gè)流比編碼單個(gè)流需要占用更多CPU。您可以在下面的chrome:// webrtc-internals統(tǒng)計(jì)信息中看到這一點(diǎn),其中使用聯(lián)播的CPU使用率提高了幾個(gè)百分點(diǎn):

沒有聯(lián)播的CPU使用率

使用聯(lián)播的CPU使用率

它還涉及發(fā)送更多比特?cái)?shù):

在沒有使用聯(lián)播時(shí)的發(fā)送比特率(~2,5M比特/秒)

使用聯(lián)播時(shí)的發(fā)送比特率?(3M比特/秒)

這些圖表是由chrome:// webrtc-internals自動(dòng)縮放的,因此請注意y軸刻度可能不同。請查看實(shí)際的y軸值。

流暫停

那么這是否意味著聯(lián)播對用戶來說效率較低呢?相反,由于我們可以單獨(dú)控制聯(lián)播的流,因此聯(lián)播使我們有機(jī)會通過關(guān)閉不使用的層來節(jié)省CPU和比特?cái)?shù)。如果你不是活躍的發(fā)言者,則根本不需要3層中的2層!

讓我們看看當(dāng)我們關(guān)閉前2層時(shí)的使用率:

CPU使用率

沒有使用聯(lián)播的CPU使用率基線

具有3個(gè)聯(lián)播流的CPU使用率

禁用前兩個(gè)層的聯(lián)播的CPU使用率

每秒比特?cái)?shù)

沒有使用聯(lián)播的發(fā)送比特率基線

使用3個(gè)聯(lián)播流的比特率

禁用前兩個(gè)層的聯(lián)播的比特率

對于客戶端和SFU上的負(fù)載來說,這是一個(gè)巨大的勝利!

實(shí)施暫停

現(xiàn)在讓我們看看我們是否可以將其集成到實(shí)際代碼中。這里有兩個(gè)問題需要解決:

1.在SFU上——弄清楚何時(shí)沒有使用流并讓客戶知道

2.在客戶端——在不使用流時(shí)關(guān)閉流,并在需要時(shí)再次啟動(dòng)它們

SFU

第一個(gè)問題很容易解決——當(dāng)客戶成為活躍的發(fā)言人時(shí),客戶端會明確地請求參與者提供高質(zhì)量的流,這樣我們就可以告訴發(fā)送者何時(shí)使用高質(zhì)量的流以及何時(shí)不通過數(shù)據(jù)消息通道。

客戶端

第一次嘗試

我們也想到了第二個(gè)問題。我們知道Chrome會在可用帶寬下降時(shí)暫停聯(lián)播流的傳輸,那么如果我們只限制可用帶寬會發(fā)生什么呢?我們可以通過在遠(yuǎn)程SDP中設(shè)置帶寬限制來實(shí)現(xiàn)此目的:

使用SDP限制最大發(fā)送帶寬

在 b = AS 的那一行將可用帶寬限制到200kbps。讓我們試一試,看看會是什么樣子:

SDP限制帶寬后的CPU使用率

SDP限制帶寬后的發(fā)送比特率

太棒了!這正是我們所希望的:它與我們之前的測試結(jié)果相匹配!現(xiàn)在讓我們移除上限以模擬某個(gè)人成為活躍的發(fā)言者并且我們想要他們的高質(zhì)量流:

移除上限的CPU使用率

移除上限的發(fā)送比特率

移除上限的發(fā)送幀的高度

話說回來,還有一個(gè)問題......整個(gè)過程需要30秒才能恢復(fù)到高質(zhì)量。這意味著當(dāng)某人成為活躍發(fā)言人時(shí),他們在主舞臺上的低視頻質(zhì)量將至少持續(xù)30秒。這不行,那么為什么這么慢呢?

如果你曾經(jīng)使用Chrome進(jìn)行過網(wǎng)絡(luò)損傷測試,那么你知道它會應(yīng)用大量邏輯來防止監(jiān)控。由于擔(dān)心丟失數(shù)據(jù)包,因此提高發(fā)送比特率是非常謹(jǐn)慎的。我們基本上通過我們的SDP參數(shù)完成的工作是讓Chrome認(rèn)為網(wǎng)絡(luò)的數(shù)據(jù)包容量非常低(200 kbps),因此當(dāng)我們刪除它時(shí),Chrome會小心地提高比特率,同時(shí)計(jì)算實(shí)際發(fā)送的數(shù)量。當(dāng)網(wǎng)絡(luò)出現(xiàn)問題時(shí),這很有意義,但對于我們的用例,這是一個(gè)阻礙因素。

Google Meet測試

我們注意到當(dāng)Google Meet正在使用時(shí),我們首先開始討論聯(lián)播流暫停。我們來看看Google Meet電話會議的圖表:

Google Meet上的CPU使用率上升

Google Meet上的發(fā)送比特率上升

Google Meet上的發(fā)送幀的高度

哇!它們下降并且非常快速地增加。他們是如何做到的呢?我們看了他們的SDP,他們正在使用b = AS上限。我們知道這不會讓我們快速上升(正如我們在第一次嘗試中看到的那樣),所以他們肯定還做了其他事情。

我們看了一下chrome:// webrtc-internals并注意到了這一點(diǎn):

使用webrtc-internals調(diào)查Google Meet

這個(gè)addStream可能看起來沒有什么作用,但它不是在調(diào)用的開始,它在中間的位置,當(dāng)我們希望流恢復(fù)時(shí),那么這里發(fā)生了什么呢?正在添加另一個(gè)視頻流,但沒有一個(gè)被刪除,這是如何工作的呢?它與比特率快速上升有關(guān)嗎?

所以我們仔細(xì)看了一下,發(fā)現(xiàn)了一些細(xì)節(jié)。這是參與者首先將其媒體流添加到 peerConnection的位置:

以下是當(dāng)我們想要提高比特率時(shí)的addStream:

所以我們在這里可以看到軌道ID是相同的但是流ID是不同的。這讓我們想起了Chrome如何為新創(chuàng)建的流提供一個(gè)免費(fèi)的時(shí)間段,其比特率可以很快提升; 這樣,當(dāng)你加入通話時(shí),你可以快速開始發(fā)送高清視頻。我們懷疑,新流的自由上升期是這里所利用的,當(dāng)參與者成為活躍的演講者時(shí),讓流看起來是新的。

嘗試2

根據(jù)對Meet的調(diào)查,我們開始使用獨(dú)立的WebRTC演示應(yīng)用程序嘗試重現(xiàn)其中的行為。通過這樣做,我們能夠在我們的測試環(huán)境中重現(xiàn)相同的行為:

復(fù)制媒體流

將復(fù)制的媒體流添加到對等連接

Munge SDP從新流中刪除新的ssrcs / stream信息并將其替換為原始信息。

但我們還沒有在實(shí)際的Jitsi調(diào)用中嘗試它,測試環(huán)境是點(diǎn)對點(diǎn)的,并沒有使用聯(lián)播,所以我們不確定它能移植到Jitsi并工作。曾經(jīng)我們嘗試或,我們發(fā)現(xiàn)我們沒有得到快速上升。它很慢,就像以前一樣只有帶寬上限。我們開始對此進(jìn)行調(diào)試,并認(rèn)為它可能與我們在SFU上的速率控制中的某些因素有關(guān),這會阻止比特率快速上升。

在我們進(jìn)一步發(fā)展之前,出現(xiàn)了一種新的可能性。

嘗試3

WebRTC團(tuán)隊(duì)最近推出了關(guān)于RTCRtpSender的PSA。支持修改登陸Chrome 69的編碼參數(shù)。這有一個(gè)API,可讓我們控制各個(gè)聯(lián)播編碼,包括它們是否已啟用!所以,當(dāng)我們發(fā)現(xiàn)我們不能進(jìn)入主界面時(shí),客戶端可以這樣做:

應(yīng)該禁用前2層,讓我們看看它的表現(xiàn):

CPU通過RtpSender參數(shù)丟棄沒有使用的層

通過RtpSender參數(shù)丟棄沒有使用層的發(fā)送比特率

我們沒有像以前那樣下降,但它仍然是一個(gè)很大的進(jìn)步!但是,讓我們看看當(dāng)我們重啟它們時(shí)如何提升:

CPU使用率上升

發(fā)送比特率上升

發(fā)送幀高度上升

哇!比特率立即上升了!這將完全適用于有源揚(yáng)聲器切換。我們不會在Chrome 69之前獲得此功能,但它是一個(gè)好的解決方案,并為我們提供了我們想要的東西:當(dāng)流不使用時(shí)快速降低比特率,并在我們再次需要時(shí)快速恢復(fù)。

今天就試試看Jitsi Meet,將#config.enableLayerSuspension = true添加到你的URL(只要你使用Chrome v69 +)或查看Jitsi Github中代碼。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • 接收器
    +關(guān)注

    關(guān)注

    15

    文章

    2563

    瀏覽量

    73460
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    11048

    瀏覽量

    216106
  • 帶寬
    +關(guān)注

    關(guān)注

    3

    文章

    992

    瀏覽量

    41850

原文標(biāo)題:實(shí)現(xiàn)Jitsi SFU自動(dòng)關(guān)閉/啟動(dòng)視頻層

文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    Linux網(wǎng)絡(luò)編程-TCP客戶端如何獲取要連接的服務(wù)IP?

    本篇介紹了在TCP通信中,客戶端通過UDP廣播,實(shí)現(xiàn)自動(dòng)獲取服務(wù)的IP地址,并進(jìn)行TCP連接的具體方法,并通過代碼實(shí)現(xiàn),來測試此方案是實(shí)際
    的頭像 發(fā)表于 09-27 08:56 ?5305次閱讀
    Linux網(wǎng)絡(luò)編程-TCP<b class='flag-5'>客戶端</b>如何獲取要連接的服務(wù)<b class='flag-5'>端</b>IP?

    請問stm32 407能實(shí)現(xiàn)作為網(wǎng)絡(luò)服務(wù)器又作為客戶端實(shí)現(xiàn)數(shù)據(jù)的轉(zhuǎn)發(fā)嗎?

    請問一下,stm32 407 能不能實(shí)現(xiàn)即作為網(wǎng)絡(luò)服務(wù)器又作為客戶端,來實(shí)現(xiàn)數(shù)據(jù)的轉(zhuǎn)發(fā)呢,在裸機(jī)的情況下,用Lwip
    發(fā)表于 03-13 01:10

    如何使用Socket實(shí)現(xiàn)UDP客戶端

    本教程介紹了如何利用socket 編程來實(shí)現(xiàn)一個(gè) UDP 客戶端,與服務(wù)器進(jìn)行通信。與開發(fā) TCP 客戶端一樣,我們先將 socket 編程的流程列出來,然后給出具體的實(shí)例。
    發(fā)表于 03-30 07:39

    實(shí)時(shí)性計(jì)算能力帶寬內(nèi)存客戶端需要計(jì)算什么

    嵌入式視覺嵌入式視覺相關(guān)產(chǎn)品機(jī)器人醫(yī)療影像設(shè)備自動(dòng)駕駛?cè)四樧R別相機(jī)車牌識別相機(jī)平板電腦智能手機(jī)智能眼鏡局限低成本體積小資源有限(CPU、內(nèi)存)實(shí)時(shí)性計(jì)算能力帶寬內(nèi)存客戶端需要計(jì)算什么?
    發(fā)表于 12-23 07:22

    用Delphi開發(fā)OPC客戶端工具的方法研究

    本文通過介紹OPC 技術(shù)的工作原理,結(jié)合OPC 客戶端的工作機(jī)制,給出OPC 客戶端的開發(fā)方法及在的Delphi 的具體實(shí)現(xiàn),提出了OPC 客戶端開發(fā)工具的設(shè)計(jì)方案,并
    發(fā)表于 06-15 10:37 ?35次下載

    基于USB的加密視頻客戶端的設(shè)計(jì)與實(shí)現(xiàn)

    針對USB無線視頻實(shí)時(shí)接收裝置的開發(fā),論文介紹了在Windows視頻客戶端通過USB數(shù)據(jù)接口來接收數(shù)據(jù),并且通過在Linux服務(wù)器將采集的視頻
    發(fā)表于 08-31 16:04 ?23次下載

    基于H.264的監(jiān)控系統(tǒng)中手機(jī)客戶端的設(shè)計(jì)

    本文以設(shè)計(jì)并顯實(shí)現(xiàn)了基于H.264 的視頻監(jiān)控系統(tǒng)中的Symbian 手機(jī)客戶端,提出了在帶寬較低的無線網(wǎng)絡(luò)狀況下低時(shí)延的傳輸H.264 視頻
    發(fā)表于 12-22 14:35 ?31次下載

    CoolpyCould客戶端

    一款開源的物聯(lián)網(wǎng)服務(wù)器平臺,利用nodejs寫成,此文件是CoolpyCould客戶端
    發(fā)表于 11-06 17:00 ?18次下載

    CSDN博客客戶端源碼

    CSDN博客客戶端源碼CSDN博客客戶端源碼CSDN博客客戶端源碼
    發(fā)表于 11-18 10:22 ?1次下載

    一種基于多媒體的英語智能客戶端設(shè)計(jì)

    文中提出一種基于計(jì)算機(jī)多媒體技術(shù)的英語智能客戶端。通過采用B/S與C/S結(jié)合的方式,并通過web services 接口調(diào)用的方式,實(shí)現(xiàn)對系統(tǒng)的訪問,同時(shí)采用多媒體技術(shù)的中的視頻傳輸壓縮技術(shù),以此
    發(fā)表于 12-24 16:05 ?5次下載

    iOS淘寶客戶端應(yīng)用名稱發(fā)生變化 Android客戶端應(yīng)用名稱尚未更改

    iOS淘寶客戶端應(yīng)用名稱發(fā)生變化 Android客戶端應(yīng)用名稱尚未更改
    發(fā)表于 04-18 15:37 ?1032次閱讀

    基于LwIP的TCP客戶端設(shè)計(jì)

    上一篇我們基于LwIP協(xié)議棧的RAW API實(shí)現(xiàn)了一個(gè)TCP服務(wù)器的簡單應(yīng)用,接下來一節(jié)我們來實(shí)現(xiàn)一個(gè)TCP客戶端的簡單應(yīng)用。
    的頭像 發(fā)表于 12-14 15:12 ?2602次閱讀
    基于LwIP的TCP<b class='flag-5'>客戶端</b>設(shè)計(jì)

    HTTP客戶端快速入門指南

    HTTP客戶端快速入門指南
    發(fā)表于 01-12 18:45 ?0次下載
    HTTP<b class='flag-5'>客戶端</b>快速入門指南

    MQTT中服務(wù)客戶端

    MQTT 是一種基于客戶端-服務(wù)架構(gòu)(C/S)的消息傳輸協(xié)議,所以在 MQTT 協(xié)議通信中,有兩個(gè)最為重要的角色,它們便是服務(wù)客戶端。 1)服務(wù)
    的頭像 發(fā)表于 07-30 14:55 ?3123次閱讀

    ROS是如何設(shè)計(jì)的 ROS客戶端

    實(shí)現(xiàn)通信的代碼在ros_comm包中,如下。 其中clients文件夾一共有127個(gè)文件,看來是最大的包了。 現(xiàn)在我們來到了ROS最核心的地帶。 客戶端這個(gè)名詞出現(xiàn)的有些突然,一個(gè)機(jī)器人操作系統(tǒng)里
    的頭像 發(fā)表于 09-14 17:29 ?1057次閱讀
    ROS是如何設(shè)計(jì)的 ROS<b class='flag-5'>客戶端</b>庫
    主站蜘蛛池模板: 很很鲁在线视频播放影院 | 午夜影院普通用户体验区 | 色综合天天综合网亚洲影院 | 俄罗斯欧美色黄激情 | 国产清纯白嫩大学生正在播放 | 欧美日韩亚洲国产一区二区综合 | 波多野结衣在线视频观看 | 嫩草影院永久入口在线观看 | 欧美黄色大全 | 456成人免费高清视频 | 久久青草免费91观看 | 美女教师一级毛片 | 特级一级毛片 | 日本欧美一区二区三区不卡视频 | 亚洲ol| 夜夜夜精品视频免费 | 亚洲精品久久久久午夜三 | 成人免费一区二区三区 | 精品国内视频 | 都市激情综合 | 国产一级特黄一级毛片 | 老色歌uuu26 老湿成人影院 | 亚洲福利视频一区二区 | 亚洲精品播放 | 激情五月社区 | 久操视频免费看 | 亚洲国产日韩欧美在线as乱码 | 你懂的网站在线播放 | 最黄毛片 | 69一级毛片 | 18满xo影院视频免费体验区 | 日本一级高清不卡视频在线 | 男人呻吟双腿大开男男h互攻 | 欧美aaaaa性bbbbb小妇 | 国产精品成人va在线观看入口 | 亚洲欧美人成网站综合在线 | 在线网站黄色 | 天天色天天操天天 | 欧美日韩一区二区三区视视频 | 高h乱肉辣文辣书阁 | 亚洲人成电影在线小说网色 |