Hoe goed is WebRTC-skermdeling regtig? Ek stel 4 kodeks op die proef

Ek was nog altyd nuuskierig oor hoe verskillende codecs op mekaar staan wanneer dit kom by skermdeling oor WebRTC. So, ek het besluit om self uit te vind deur die vier mees algemenes te toets: VP8, VP9, H.264 en AV1.

Om seker te maak dat die resultate solied was, het ek toetse oor 'n verskeidenheid inhoudtipes en netwerktoestande uitgevoer. Ek het nie net op visuele indrukke staatgemaak nie - ek het raam-vir-raam vergelykings gebruik, die pieksein-tot-geraasverhouding (PSNR) bereken en gedetailleerde WebRTC-statistieke getrek om 'n duidelike, data-gedrewe aansig te kry.

Om 'n stap verder te gaan, het ek selfs 'n pasgemaakte Chrome-inprop gebou wat SVE-gebruik tydens beide enkodering en dekodering naspoor. Dit het my 'n goeie blik gegee op hoe elke kodek stelselwerkverrigting beïnvloed - want kwaliteit is puik, maar nie as jou rekenaar aan die brand is en probeer byhou nie.

Ek het gekyk na sleutelmaatstawwe soos bitsnelheid, raamtempo, resolusie, kwantisering (QP), PSNR en CPU-lading. Op grond van dit alles het ek met 'n paar praktiese aanbevelings vorendag gekom om enigiemand te help wat WebRTC-skermdeling vir hul eie gebruiksgevalle probeer optimaliseer.

Oor die eksperiment

Waarom skermdeling nie so eenvoudig is soos dit lyk nie

As jy al ooit jou skerm tydens 'n video-oproep gedeel het en opgemerk het dat die kwaliteit daal - of die video raak wankelrig - is jy nie alleen nie. Om skermdeling skerp en glad te hou, is eintlik moeiliker as wat dit lyk.

Die probleem? Dit gaan alles oor verskeidenheid. Sommige inhoud is stil, soos 'n skyfiedek of 'n dokument. Ander kere deel jy hoë-beweging video. Hierdie verskillende tipes inhoud vereis baie verskillende dinge van die kodek. Snelbewegende video vreet byvoorbeeld 'n ton bandwydte op, terwyl statiese beelde meer sensitief is vir kompressie-artefakte wat hulle vaag of blokkerig kan laat lyk.

Gooi werklike internetkwessies soos pakkieverlies of bandwydtedalings in, en dinge raak nog morsiger. Dit is hoekom die keuse van die regte kodek - en fyn instel hoe dit werk - so belangrik is om skermdeling van hoë gehalte sowel as responsief te maak.

Daar is reeds baie navorsing daar buite oor hoe video-kodeks in algemene stroomscenario's presteer. Maar skermdeling het sy eie eienaardighede. Dit gaan nie net oor die kyk van 'n video nie - dit gaan oor interaksie in reële tyd, en die inhoudtipes is oraloor. Dit beteken dat die gewone navorsing nie altyd van toepassing is nie.

Wat ek van plan was om te doen

Ek wou dieper in hierdie spesifieke gebruiksgeval delf. My doel was om te sien hoe verskillende codecs presteer wanneer dit kom by skermdeling, veral onder werklike beperkings soos verskillende inhoudtipes en onvoorspelbare netwerktoestande.

Om dit te doen, het ek 'n metode ontwerp om skermdeelkwaliteit so akkuraat as moontlik te evalueer - nie net gebaseer op hoe dit lyk nie, maar gerugsteun deur soliede statistieke en data. Langs die pad het ek baie geleer oor watter codecs die beste hou en hoe om dinge te verfyn vir beter werkverrigting in intydse toepassings.

Een ding het vinnig duidelik geword: skermdeelprestasie hang regtig af van wat jy deel. 'n Vinnige video tree baie anders op as 'n statiese dokument of 'n stadige blaai deur 'n webblad.

Om dinge regverdig en konsekwent te hou, het ek seker gemaak dat elke toets met presies dieselfde toestande uitgevoer word - dieselfde resolusie, dieselfde beginpunt en dieselfde duur. Op dié manier kon ek vol vertroue wees dat die resultate alles oor die kodek-prestasie gaan, nie een of ander toevallige veranderlike nie.

Ek het twee verskillende toetsgevalle geskep om werklike skermdeelsituasies te simuleer:

• Hoëbeweging-video – Dit was 'n regte snit van motorfietsryers wat deur 'n woud jaag. Baie vinnige beweging, gedetailleerde natuurskoon en 'n voortdurend veranderende visuele omgewing - perfek om die grense van kompressie te verskuif.

• Outo-blaai teks - Ek het 'n eenvoudige HTML-bladsy met teks en beelde gebou, en dan JavaScript gebruik om dit teen 'n bestendige spoed te blaai. Dit boots 'n algemene gebruiksgeval na soos die deel van 'n dokument of lees vanaf 'n webblad.

Hierdie twee tipes inhoud het my 'n goeie mengsel gegee om te toets hoe elke kodek verskillende uitdagings hanteer - van tred hou met beweging tot die behoud van duidelikheid in meer statiese tonele.

Hoe ek alles opstel

Om die codecs behoorlik te toets, het ek 'n stewige opstelling nodig gehad wat alles kon vasvang - beide wat gestuur word en wat ontvang is. Ek het begin met 'n instrument genaamd webrtc-sandbox (Terloops, jy kan meer oor hierdie hulpmiddel en nog vele meer leer in my ander pos: " Leer WebRTC in die praktyk: Beste gereedskap en demonstrasies "), wat wonderlik is om met WebRTC-interne te mors. Ek het dit uiteindelik nogal aangepas om skermdeling beter te hanteer en seker te maak dat ek beide die uitgaande en inkomende videostrome kan opneem. Elke toetslopie het vir my twee videolêers gegee – een vir wat gestuur is en een vir wat ontvang is – wat ek later vir sy-aan-sy-analise gebruik het.

Maar ek het nie by video gestop nie. Ek wou ook dophou wat onder die enjinkap gebeur. Daarvoor het ek gedetailleerde WebRTC-statistieke direk vanaf die Chrome-blaaier getrek. Hierdie statistieke het my 'n venster gegee in hoe elke kodek gevaar het en hoe die gesimuleerde netwerk tydens elke toets opgetree het.

Een groot stuk van die legkaart was SVE-gebruik - en dit blyk 'n bietjie lastig te wees. Chrome se normale weergawe laat nie toe dat plugins SVE-lading vir individuele oortjies monitor nie, so ek het 'n ontwikkelingsbou van die blaaier gebruik en my eie inprop geskryf om dit te omseil.

Ek het spesifiek gefokus op die meet van SVE-gebruik vanaf die oortjie wat die skermdeel gestuur of ontvang het. Op dié manier het ek onverwante leweringstake uit ander dele van die blaaier uitgesluit. Aangesien beide stuur en ontvang in dieselfde oortjie gebeur het, was die nommers wat ek gekry het 'n gekombineerde aansig - maar steeds redelik naby aan wat jy in 'n werklike gebruiksgeval sou sien. (Spoiler: enkodering tref gewoonlik die SVE harder as dekodering.)

Versamel die data: 157 toetslopies later...

Sodra die opstelling gereed was, was dit tyd om die werklike eksperimente uit te voer - en ek het baie daarvan uitgevoer. Ek het die toetse op dieselfde masjien oor en oor herhaal, met verskillende netwerktoestande en kodek-instellings om te sien hoe dinge stand gehou het. In totaal het ek 157 datapunte ingesamel, om seker te maak dat elke kombinasie van toetstoestande goed verteenwoordig is.

Dit het my 'n stewige datastel gegee om mee te werk en het 'n bietjie diepgaande ontleding moontlik gemaak van hoe skermdeling in WebRTC onder verskillende scenario's optree. Hier is wat ek spesifiek getoets het:

• Video tipe :
  Ek het twee tipes skermdeelinhoud gebruik om algemene gebruiksgevalle te weerspieël:
  • Hoë-beweging video - Werklike beeldmateriaal met tonne pixel verander elke raam.
  • Outo-gerol teks - Meestal statiese beeldmateriaal, maar met pixels wat posisie verskuif soos die teks blaai.
• Kodek :
  Ek het die vier gewildste skermdeling-kodeks getoets:
  • AV1
  • H.264
  • VP8
  • VP9
• Netwerk bandwydte :
  Aangesien bandwydte 'n groot rol in videokwaliteit speel (veral in video-oproepe), het ek 'n verskeidenheid netwerktoestande gesimuleer om te sien hoe goed elke kodek stywe of wisselende bandwydte hanteer het.

Deur hierdie veranderlikes op 'n gestruktureerde manier te meng en te pas, kon ek werklike skermdeel-scenario's naboots - die soort wat jy in 'n video-oproep, tydens 'n regstreekse demonstrasie of in 'n gesamentlike afgeleë sessie sou ontmoet.

Die regstelling van die foute: hoe ek die toetse meer betroubaar gemaak het

Soos met die meeste eksperimente, het die eerste paar lopies nie so glad verloop as wat ek gehoop het nie. Twee groot probleme het dadelik opgeduik:

1. Handmatige begin = Morsige tydsberekening. Aanvanklik het ek die skermdeling met die hand begin - letterlik op 'n knoppie geklik om dinge af te skop. Die probleem? Dit was byna onmoontlik om die begin van die opname met die begin van die video-inhoud te sinkroniseer. Dit het beteken dat elke toetslopie effens verskillende tydsberekening gehad het, wat die vergelykings van die hand gewys het.
2. Gestuur vs. Ontvang = Nie gesinkroniseer nie. Selfs wanneer die tydsberekening reg was, het intydse video sy eie eienaardighede. Danksy enkodering, dekodering en netwerkvertragings het die gestuurde en ontvangde strome nooit perfek in lyn gekom nie. Dit het raam-vir-raam kwaliteit vergelykings byna onmoontlik gemaak.

Om hierdie probleme op te los, het ek 'n paar belangrike verbeterings aangebring:

• Programmatiese sinkronisering : In plaas daarvan om alles handmatig te begin, het ek 'n kode geskryf om die begin van die video of blaaiteks met die opnameproses te sinkroniseer. Op dié manier het elke toetslopie op presies dieselfde oomblik aan albei kante begin - probleem opgelos.
• QR-kode-raampassing : Vir die desinkroniseringskwessie het ek 'n klein QR-kode-oorleg by die gedeelde video gevoeg. Hierdie klein merker het soos 'n tydstempel opgetree - dit het my met presisie laat rame tussen die gestuurde en ontvangde strome pas. Skielik het raam-vir-raam-analise uitvoerbaar geword (en baie meer akkuraat).

Daar was nog een ding waarvoor ek rekening moes hou: WebRTC se aanpasbare bitsnelheid . Een van WebRTC se cool kenmerke is dat dit outomaties videokwaliteit aanpas op grond van beskikbare bandwydte. Maar daardie aanpassing gebeur nie onmiddellik nie – dit neem ’n paar sekondes om te stabiliseer. So, ek het 'n kort vertraging bygevoeg voordat die werklike opname begin het. Dit het die stelsel tyd gegee om teen die teikenbitsnelheid te vestig, sodat die resultate die werklike kwaliteit weerspieël wat jy sou kry nadat dinge gelyk is.

Hierdie veranderinge het die eksperiment baie meer betroubaar gemaak en het my vertroue gegee dat die data wat ek insamel eintlik weerspieël hoe skermdeling in die regte wêreld optree.

Wat ek gemeet het (en hoekom dit saak maak)

Ek het baie data tydens hierdie toetse ingesamel, maar om dinge eenvoudig te hou en maklik om te vergelyk, het ek gefokus op 'n paar kernstatistieke wat regtig die storie vertel van hoe elke kodek in 'n skermdeelscenario presteer.

Hier is waarna ek gekyk het:

• Raamtempo
  Dit vertel my hoeveel rame per sekonde werklik geënkodeer, gestuur en ontvang is. Dit is 'n goeie aanduiding van hoe glad die videostroom voel - 'n hoër raamtempo beteken gewoonlik 'n meer vloeiende ervaring.
• Resolusie
  Resolusie gaan alles oor hoeveel visuele detail bewaar word. Ek het die aantal pixels per raam in elke stadium (gestuur en ontvang) opgespoor om te sien of die kodeks beeldkwaliteit behou of dit laat val het om bandwydte te bespaar.
• Video kwaliteit
  Ek het 'n paar sleutelmaatstawwe hier gebruik:
  • Kwantiseringsparameter (QP) - 'n Laer QP beteken oor die algemeen beter kwaliteit.
  • Piek sein-tot-geraas-verhouding (PSNR) - Dit gee 'n numeriese gevoel van hoeveel die ontvangde video van die oorspronklike verskil. Hoër = beter.
• SVE Gebruik
  Kodekverrigting gaan nie net oor wat jy sien nie – dit gaan ook oor wat jou masjien agter die skerms doen. Ek het gemeet hoeveel SVE-krag gebruik is vir enkodering en dekodering tydens elke toets, genormaliseer met verloop van tyd, om te sien watter kodeks liggewig is en watter hulpbronvarke is.

Deur dinge met hierdie maatstawwe af te breek, kon ek die kodeks nie net op kwaliteit vergelyk nie, maar ook oor gladheid, doeltreffendheid en hoe veeleisend hulle is. Dit het gehelp om te onthul waar elke kodek skyn - en waar dit sukkel - in werklike skermdeeltoestande.

Kom uiteindelik by die resultate

Hoeveel maak die tipe inhoud saak? Baie meer as wat jy sou dink

Een van die mees verrassende wegneemetes uit my eksperimente was net hoeveel die tipe inhoud wat jy deel, die werkverrigting van skermdeling beïnvloed – beide in terme van videokwaliteit en hulpbrongebruik. En dit was waar vir elke kodek wat ek getoets het.

Die idee daaragter is redelik eenvoudig: wanneer meer pixels van raam tot raam verander (soos in 'n vinnigbewegende video), moet die stelsel harder werk. Dit beteken meer bandwydte is nodig, en jou SVE moet meer druk om by te hou.

Neem AV1 , byvoorbeeld. Toe ek dit gebruik het om 'n 1,5-megapixel-skerm te deel, het die vereiste bandwydte baie gewissel na gelang van wat gedeel is. In een geval, waar die inhoud meer dinamies was, moes AV1 aansienlik meer data stoot om die stroom glad te hou. Ek het dit in die volgende grafiek vasgevang, wat wys hoe drasties inhoudskompleksiteit die bandwydtegebruik beïnvloed.

Maar dit is nie net bandwydte nie - jou hardeware voel dit ook.

Die volgende grafiek wys hoe SVE-gebruik verander op grond van die inhoud wat gedeel word. Weereens, deur AV1 as die voorbeeld te gebruik, kan jy duidelik sien dat meer komplekse beeldmateriaal baie meer SVE-krag vereis om dinge teen dieselfde raamtempo en resolusie aan die gang te hou.

Dit is ook nie net 'n AV1-ding nie. Alle codecs maak staat op dieselfde basiese beginsels vir die enkodering en dekodering van video, so jy sou verwag dat hulle soortgelyke gedrag sal toon - maar die data vertel 'n ander storie. Die SVE-lading verander nie net met die inhoud nie, dit verander ook op grond van watter kodek jy gebruik.

Om dit makliker te maak om te vergelyk, het ek die volgende tabel saamgestel, wat wys hoeveel SVE elke kodek gebruik wanneer 'n 1,5-megapixel-video teen ongeveer 24 rame per sekonde stroom - 'n redelik tipiese opstelling vir gladde skermdeling. Die resultate beklemtoon 'n paar groot verskille in hoe doeltreffend elke kodek is wanneer dit kom by die gebruik van jou hardeware.

Dus, as jy iets bou of optimaliseer wat op WebRTC-skermdeling staatmaak, is die wegneemete duidelik: beide jou inhoud en jou keuse van kodek maak saak. Baie.

Codec Showdown: Raamkoerse, SVE-lading en die werklike koste van kwaliteit

As dit by skermdeling kom, is een van die eerste dinge wat jy opmerk hoe glad (of nie) die video voel. Dit is waar raamtempo inkom. As jy hoë-beweging inhoud deel, soos videoterugspeel of animasies, is 'n hoër raamtempo noodsaaklik om strome wat moeilik is om te kyk, te vermy.

Vir hierdie deel van die eksperiment het ek gefokus op raamtempo-prestasie oor verskillende codecs, terwyl ek alles konstant gehou het: dieselfde resolusie (ongeveer 1,5 megapixels) en dieselfde inhoud vir elke toets. Ek het die contentHint WebRTC-instelling gebruik om seker te maak dat die resolusie oor die hele linie vasgesluit bly.

In die volgende prent kan jy sien hoe verskillende kodeks hoë-beweging inhoud hanteer soos bandwydte toeneem. Op die x-as: bitsnelheid in Mbps. Op die y-as: raamtempo in rame per sekonde (fps).

Hier is wat uitgestaan het:

• H.264 en AV1 het vorentoe getrek sodra die bandwydte 2 Mbps of meer bereik het, wat albei 20+ fps gelewer het - 'n gladde ervaring wat selfs op 'n ordentlike 3G-verbinding haalbaar is.
• VP8 en VP9 het nie so goed bygehou nie. Hulle het onder dieselfde toestande teen ongeveer die helfte van die raamtempo gesweef en het regtig 4 Mbps of meer nodig gehad om bruikbaar te voel - wat nie altyd realisties is op laer-end-netwerke nie.

Toe het ek oorgeskakel na lae-beweging inhoud - 'n stadig blaai teks bladsy - om te sien hoe codecs presteer wanneer nie veel verander tussen rame.

Dit is nie verbasend dat beide H.264 en AV1 selfs beter gevaar het in hierdie scenario, met AV1 wat bo uitkom . Dit is te danke aan 'n kenmerk genaamd Intra Block Copy , waarmee AV1 herkodering van dele van die skerm wat nie verander het nie, kan oorslaan. Dit is ongelooflik effektief vir statiese of semi-statiese skermdeling.

In die volgende grafiek kan jy sien hoe doeltreffend AV1 hierdie lae-beweging situasies hanteer, wat bandwydtegebruik indrukwekkend laag hou terwyl hoë visuele kwaliteit gehandhaaf word.

Maar ... daar is 'n afweging.

AV1 gee jou dalk beter beeldmateriaal en kompressie, maar dit vreet ook meer SVE op . Volgende prent wys dit duidelik: AV1 se SVE-gebruik klim geleidelik namate bitsnelheid toeneem, en verby H.264 met 'n lang skoot. H.264 het hier 'n groot voordeel danksy wydverspreide hardewareversnelling , wat sy SVE-lading laag en stabiel hou.

Interessant genoeg gebruik VP9 selfs meer SVE as AV1 - volgens 'n soortgelyke neiging, maar met hoër pieke. Beide VP9 en AV1 maak staat op komplekse algoritmes om goeie gehalte te lewer, maar dit kom teen 'n prys: hulle is swaar op jou verwerker.

Daar was 'n kinkel toe ek lae-beweging-inhoud herbesoek het. Hierdie keer het VP8 en VP9 eintlik redelik doeltreffend gelyk - met minder SVE as AV1, soos in die volgende grafiek getoon.

AV1, ondanks die feit dat dit ontwerp is met skermdeling in gedagte, het steeds die meeste SVE gebruik. Hoekom? Al daardie optimaliserings wat dit help om hoë-beweging-video saam te komprimeer, voeg ook bokoste by - selfs wanneer daar nie veel op die skerm gebeur nie.

'n Groot rede hiervoor? AV1 het steeds nie wydverspreide hardeware-enkoderingondersteuning nie . Alhoewel dekodering relatief liggewig is, word enkodering steeds meestal in sagteware gedoen - en dit is 'n SVE-intensiewe taak, veral in intydse scenario's soos skermdeling waar beide enkodering en dekodering voortdurend plaasvind.

Dit is waar dinge moeilik raak vir draagbare toestelle soos skootrekenaars en tablette. Sonder hardeware-versnelling kan kodeks soos AV1 vinnig krag en varkhulpbronne dreineer – nie ideaal wanneer jy op pad is nie. Totdat beter hardeware-ondersteuning meer algemeen word, het AV1 se gevorderde kenmerke 'n redelik merkbare prestasiekoste.

Kodeks en resolusie: wat gebeur as u raamtempo prioritiseer?

Tot dusver kom die resultate wat ek gedeel het van toetse wat resolusie konstant gehou het. Wanneer bandwydte krap geraak het, sou die stelsel reageer deur die raamtempo te verlaag - wat sin maak vir dinge soos statiese inhoud of teks. Maar wat as die doel is om dinge vlot te laat beweeg , selfs al beteken dit dat resolusie opgeoffer word?

Om dit te verken, het ek 'n nuwe stel eksperimente uitgevoer waar WebRTC opgestel is om eerder raamtempo te prioritiseer. Dit is gedoen deur gebruik te maak van die contentHint -instelling in WebRTC, waarmee jy die blaaier kan vertel wat belangriker is – hoë resolusie of gladde beweging.

Ek het gemik om raamtempo teen 'n konsekwente 30 fps te hou, wat algemeen erken word as die lieflike plek vir gladde, gemaklike kyk. Dit was moeilik om dit konsekwent te kry - aanpasbare streaming beteken dat daar altyd 'n bietjie fluktuasie is - maar die resultate het waardevolle insig gebied in hoe elke kodek hierdie afweging hanteer.

Om hierdie gedrag te help ontleed, het ek 'n nuwe maatstaf bekendgestel:

Gestuurde piksels per sekonde = Raamtempo × Resolusie

Dit gee 'n meer volledige prentjie as om net na FPS of resolusie alleen te kyk. Dit wys hoeveel visuele data die kodek werklik per sekonde lewer onder verskillende toestande.

Vir hoë-beweging video het AV1 weereens bo uitgekom - en met 'n merkbare marge. Selfs teen laer bitrate het dit daarin geslaag om aansienlik meer pixels per sekonde as enige ander kodek te stuur. Dit wys duidelik hoe goed AV1 dinamiese inhoud hanteer wanneer die stelsel onder druk is om 'n hoë raamtempo te handhaaf. Sien asseblief die volgende grafiek :

Toe ek oorgeskakel het na lae-beweging inhoud - soos 'n webblad met blaai teks - die speelveld het 'n bietjie meer gelyk. Die werkverrigting van alle codecs het meer eenvormig geword soos u op die volgende prent kan vind. AV1 het egter steeds 'n voorsprong behou , veral teen hoër bitrate. Die kompressie-optimalisasies het dit gehelp om sterk deurset te handhaaf sonder om hulpbrongebruik aansienlik te verhoog.

Wat beteken dit alles in die praktyk?

Wel, as jou gebruiksgeval dinamiese beeldmateriaal met hoë bewegings behels - soos video-deurlopers, lewendige animasies of speletjiestroming - kan die prioritisering van raamtempo 'n groot verskil maak , en AV1 blyk besonder bekwaam in daardie omgewing te wees.

Selfs vir stadiger bewegende inhoud, toon AV1 steeds krag. Alhoewel die verskil kleiner kan wees, slaag dit konsekwent daarin om meer visuele data te stuur - wat beter gehalte teen dieselfde of laer bandwydte beteken - danksy sy gevorderde kompressiestrategieë.

In beide gevalle was die "gestuurde pixels per sekonde" -metriek nuttig om te verstaan hoe kodeks resolusie en raamtempo balanseer wanneer bandwydte beperk is. En AV1 se werkverrigting onder hierdie toestande bevestig dit verder as die mees bekwame opsie - mits jou stelsel die bykomende SVE-eise kan hanteer.

Hoe skoon is die beeld? Kom ons praat PSNR

Behalwe raamtempo, resolusie en SVE-gebruik, is daar nog 'n belangrike deel van die skermdeelraaisel: hoe naby lyk die ontvangde prent aan die oorspronklike? Dit is waar die pieksein-tot-geraasverhouding (PSNR) inkom.

PSNR is 'n wyd gebruikte maatstaf om die kwaliteit van saamgeperste video te meet. Dit vertel jou hoeveel vervorming - of "geraas" - ingestel is tydens enkodering. Dit word in desibels (dB) gemeet, en die reël is eenvoudig: hoe hoër, hoe beter . 'n Hoë PSNR beteken die beeld lyk amper presies soos die oorspronklike; 'n laer telling beteken daar is meer sigbare agteruitgang.

Om dit in konteks te plaas, het ek PSNR-waardes oor codecs in twee verskillende scenario's getoets: een waar resolusie die prioriteit is, en 'n ander waar raamtempo die voortou neem. Albei toetse het dieselfde hoë-beweging video-inhoud gebruik om dinge konsekwent te hou.

In hierdie opstelling, waar duidelikheid die fokus is (selfs al eindig die video 'n bietjie wankelrig), het H.264 besonder goed gevaar en skerp beeldmateriaal met minimale vervorming gelewer. Dit is 'n sterk keuse wanneer gladheid nie so krities is nie.

Wanneer die doelwit verskuif na die handhawing van vloeiende beweging, kom AV1 vooruit , veral teen hoër bitsnelhede. Dit slaag daarin om beeldkwaliteit te behou, selfs terwyl dit aggressief saamgepers word om raamtempo-teikens te bereik.

Alhoewel die verskille in PSNR tussen codecs nie altyd dramaties is nie, beklemtoon dit die afwegings wat u maak wanneer u 'n codec kies. Sommige prioritiseer skerpheid; ander streef na gladde beweging - en afhangende van jou gebruiksgeval, is die een dalk beter geskik as die ander.

Toe het ek weer dieselfde toetse uitgevoer, hierdie keer met behulp van gerolde teksinhoud – iets wat die belangrikheid van resolusie en duidelikheid regtig beklemtoon.

Wanneer beweging geprioritiseer word, lyk PSNR-waardes oor alle codecs redelik soortgelyk. Die inhoud verander nie veel nie, so die verskille in kompressiestrategie het nie veel impak op algehele beeldkwaliteit nie.

Dit is waar dinge interessant raak. Met resolusie as die prioriteit, trek AV1 ver voor die ander kodeks – veral teen hoër bitsnelheid. Sy prestasie hier is uitsonderlik.

Hoekom? AV1 bevat spesifieke optimaliserings vir die hantering van statiese, herhalende inhoud soos teks. Dit laat dit toe om hoër beeldgetrouheid te handhaaf, artefakte te vermy en meer doeltreffend saam te pers. Dit maak AV1 'n fantastiese keuse vir gebruiksgevalle soos die deel van dokumente of kode deurloop - enige plek waar skerp, leesbare detail regtig saak maak .

Kortom, PSNR help om 'n subtiele maar belangrike dimensie van skermdeelkwaliteit uit te lig. Of jy nou beweging of skerpte prioritiseer, om te verstaan hoe codecs onder verskillende beperkings optree, laat jou die regte een vir die werk kies.

Wat is die Deal met QP? Verstaan kompressie vs kwaliteit

Nog 'n belangrike faktor in skermdeelkwaliteit is iets wat die Quantization Parameter , of QP , genoem word. As jy al ooit gewonder het wat beheer hoeveel detail tydens kompressie verlore gaan, is dit dit.

In eenvoudige terme vertel QP die enkodeerder hoe aggressief die video moet saamgepers word .

• 'n Lae QP beteken minder kompressie en beter beeldkwaliteit.
• ’n Hoë QP beteken meer kompressie – wat bandwydte bespaar, maar die video erger kan laat lyk.

Terwyl PSNR vir ons 'n resultaat gee – hoeveel beeldkwaliteit behoue gebly het – vertel QP vir ons waarna die enkodeerder gemik het . So, ek het na albei gekyk.

In hierdie studie:

• QP-waardes is uit standaard WebRTC-metrieke getrek.
• PSNR is ná die feit gemeet deur elke oorspronklike raam met sy ontvangde weergawe te vergelyk.

Hier is waar dinge interessant geword het. AV1 het die beste PSNR-tellings gehad , wat beteken dat dit die beeldkwaliteit die beste behou het - maar dit het ook QP-waardes tot vier keer hoër as die ander kodeks gehad. Dit lyk met die eerste oogopslag teenstrydig.

Maar hier is die vangplek: elke kodek definieer en hanteer QP anders , so die waardes is nie direk vergelykbaar nie. 'n QP van 50 in een kodek beteken nie noodwendig dieselfde vlak van kompressie as 'n QP van 50 in 'n ander nie.

Tog vertel QP-tendense ons iets nuttigs. Oor alle codecs het ek opgemerk dat namate bandwydte toeneem, QP afneem . Dit maak sin – met meer bandwydte beskikbaar, kan die codecs bekostig om kompressie te verminder en beeldkwaliteit te verbeter.

So alhoewel ons nie QP-nommers langs mekaar kan opstel oor codecs nie, wys hulle steeds hoe elke kodek kompressie dinamies aanpas op grond van beskikbare netwerktoestande.

Kortom: QP is nie 'n gehaltetelling nie - dit is 'n instelling . Maar om na te spoor hoe dit met bandwydte verskuif, gee nuttige insig in wat die enkodeerder agter die skerms doen. En gekombineer met PSNR, gee dit 'n meer volledige beeld van kodekgedrag.

Finale gedagtes: wat dit alles beteken vir WebRTC-skermdeling

Nadat jy diep geduik het in hoe WebRTC onder die enjinkap presteer, is een ding duidelik: nie alle kodeks is gelyk geskep nie - en die beste keuse hang regtig van jou prioriteite en omgewing af.

Hier is die belangrikste wegneemetes uit my eksperimente:

AV1: Beste kwaliteit, hoogste koste

AV1 het konsekwent die beste visuele kwaliteit gelewer, of ek vinnigbewegende video gedeel het of stadig blaai van teks. Sy gevorderde kompressie en optimalisering maak dit ongelooflik doeltreffend - maar dit kom met 'n prys. AV1 is SVE-honger , en aangesien hardeware-ondersteuning steeds inhaal, is dit nog nie ideaal vir laer-aangedrewe of mobiele toestelle nie .

H.264: Die Solid All-Rounder

As jy 'n balans tussen werkverrigting en doeltreffendheid soek, is H.264 steeds 'n goeie keuse. Dit word wyd ondersteun, hardeware-versnel op die meeste platforms, en doen 'n goeie werk in byna elke scenario - veral wanneer stelselhulpbronne of batterylewe 'n bekommernis is.

Inhoud maak meer saak as wat jy dink

Die tipe inhoud wat jy deel het 'n groot impak op prestasie. Hoë-beweging video vereis veel meer van jou SVE en bandwydte as statiese inhoud soos dokumente of teks. Die keuse van die regte kodek - en die regte instellings - vir jou inhoud kan 'n groot verskil in kwaliteit en hulpbrongebruik maak.

SVE-gebruik is nie net 'n voetnoot nie

Danksy 'n pasgemaakte Chrome-inprop wat ek gebou het, kon ek SVE-gebruik akkuraat meet tydens skermdeling. Die resultate het groot verskille getoon in hoe veeleisend elke kodek is , wat veral belangrik word op mobiele toestelle of in energie-sensitiewe omgewings.

Wat is volgende? Waarheen hierdie navorsing kan gaan

Hierdie eksperiment het die deur oopgemaak vir 'n paar opwindende volgende stappe. Hier is waar ek dink toekomstige werk 'n selfs groter impak kan maak:

Toets op mobiele toestelle

Tot dusver is alle toetse op rekenaars gedoen - maar skermdeling is net so algemeen (indien nie meer nie) op fone en tablette . Om te toets hoe hierdie codecs op mobiele toestelle werk, sal 'n meer volledige prentjie gee, veral in terme van reaksie en kragverbruik.

Energiedoeltreffendheid

Van krag gepraat - codecs verbrand nie net SVE nie, hulle verbrand ook batterylewe . Toekomstige navorsing moet ondersoek watter kodeks die energiedoeltreffendste is, veral vir lang skermdeelsessies op draagbare toestelle.

KI-aangedrewe kodek-instelling

Stel jou voor of WebRTC outomaties kodek-instellings kon aanpas op grond van jou huidige inhoud en netwerkspoed. KI kan dit moontlik maak , deur dinamies die perfekte balans tussen kwaliteit en werkverrigting in real-time te vind.

Om dit toe te draai

Kodek-keuse is meer as net 'n tegniese besluit - dit beïnvloed direk die kwaliteit, gladheid en hulpbrongebruik van jou skermdeelervaring. Of jy nou 'n videokonferensie-instrument bou, 'n samewerkingsplatform, of net jou eie werkvloeie optimaliseer, om te verstaan hoe hierdie codecs onder verskillende omstandighede optree, kan jou help om slimmer, doeltreffender besluite te neem.

Soos WebRTC voortgaan om te ontwikkel, sal die gereedskap en tegnieke daarom ook. Ek hoop hierdie diep duik help ander om beter te verstaan wat agter die skerms aangaan – en hoe om die meeste uit hul skermdelingstapel te kry.

Wil jy self die data verken?

As jy nuuskierig is om dieper in die resultate te delf of jou eie analise uit te voer, het ek die volledige datastel van hierdie studie hier beskikbaar gestel:

Laai die datastel op Kaggle af

Dit bevat rou statistieke vir raamtempo, resolusie, PSNR, QP, SVE-gebruik en meer - alles georganiseer volgens kodek, inhoudtipe en bandwydtetoestand. Gebruik dit gerus vir jou eie eksperimente, benchmarking, of net om te verken hoe WebRTC in verskillende scenario's optree.