Hoe we schermdelen vier keer sneller maakten

Latentie bij schermdelen is zo'n probleem dat je pas opmerkt als het slecht is. Een presentator klikt naar de volgende dia en het publiek dat naar het gedeelde scherm kijkt, ziet het anderhalve tel later. Niet echt kapot, gewoon net niet goed. Over een paar releases hebben we kritisch bekeken waar die vertraging in het schermdelen van Cliqer vandaan kwam, en we hebben de basislatentie teruggebracht van meer dan twee seconden naar ongeveer een halve seconde, een verbetering van grofweg vier keer. Dit is in gewone taal hoe we dat deden.

We gaan geen codenamen verstoppen of doen alsof er één wondermiddel was. Er waren drie afzonderlijke fixes, elk gericht op een andere plek waar de vertraging zich verstopte, en ze versterkten elkaar.

Waarom schermdelen überhaupt hapert

Wanneer je een scherm deelt, moeten er drie dingen gebeuren voordat een kijker een frame ziet: je computer moet het vastleggen, naar video encoderen en verzenden. Elk van die stappen kan ongemerkt vertraging toevoegen, en het effect stapelt zich op. Een trage encoder plus een voorzichtige buffer plus wachten op de volgende volledige frame-update kan makkelijk oplopen tot twee of drie seconden, zelfs op een snelle verbinding.

Het lastige is dat geen van die stappen afzonderlijk kapot lijkt. Vastleggen werkt. Encoderen werkt. De stream komt aan. Hij is alleen te laat, en ‘alleen te laat’ is moeilijk te diagnosticeren zonder elke fase afzonderlijk te meten.

Fix één: stop met hetzelfde beeld twee keer encoderen

De eerste bron van vertraging was verspild werk. Scherm- en NDI-shares werden achter de schermen twee keer geëncodeerd, één keer voor elk uitvoerpad, en een stilstaande dia werd continu opnieuw geëncodeerd, ook al was er niets op het scherm veranderd. Dat verdubbelde de belasting van de encoder zonder enig visueel voordeel, en het betekende dat de pipeline altijd drukker was dan nodig, waardoor elk frame verder achteraan in de wachtrij belandde.

Door de dubbele encodeerstap te schrappen en het opnieuw encoderen over te slaan als het beeld niet is veranderd, kwam er direct flink wat CPU-ruimte vrij. Minder concurrentie om de encoder betekent dat elk frame dat wel geëncodeerd moet worden, sneller wordt verwerkt.

Fix twee: de buffer strakker maken zonder in te leveren op veerkracht

De tweede bron was de buffer tussen de encoder en het netwerk, het onderdeel dat korte netwerkhaperingen opvangt zodat een hapering op de lijn geen hapering op het scherm wordt. Zulke buffers zijn van nature een afweging: te klein en een kleine hapering veroorzaakt zichtbare glitches, te ruim en je voegt aan elk afzonderlijk frame vertraging toe, voor het geval er later iets misgaat.

De buffer was ruim bemeten, waardoor hij in de normale situatie aan elk frame vertraging toevoegde om te beschermen tegen een zeldzame situatie. Door hem strakker te maken daalde de vertraging in het slechtste geval van een paar seconden naar ruim onder de één, terwijl korte netwerkhaperingen nog steeds zonder zichtbare glitches worden opgevangen. Dit is het soort fix dat er in een diff uitziet als een kleine aanpassing van een getal, maar eigenlijk een afweging is over welke manier van falen je liever hebt.

Fix drie: nieuwe kijkers niet laten wachten op het volgende keyframe

De derde fix richtte zich op een specifiek, pijnlijk moment: wat er gebeurt als iemand aansluit bij een share die al loopt. Videocompressie werkt door slechts af en toe volledige frames te sturen, keyframes genoemd, met daartussen goedkopere frames van het type ‘wat is er veranderd sinds de vorige keer’. Een kijker die halverwege de stream instapt, kan die tussenliggende frames pas interpreteren als hij een keyframe ontvangt om op te ankeren, en voorheen betekende dat wachten op het volgende geplande keyframe, tot wel drie seconden later.

De oplossing was om het meest recente keyframe in de cache te bewaren en het direct aan een nieuwe kijker te geven zodra die aansluit, in plaats van hem te laten wachten op het volgende keyframe in het schema. Gecombineerd met de op intervallen gebaseerde frametiming die in onze documentatie over schermdelen wordt beschreven, zien nieuwe kijkers nu binnen milliseconden na het aansluiten video, in plaats van tot drie seconden te wachten op het volgende keyframe.

Tel alle drie de fixes bij elkaar op en de basislatentie van ruim twee seconden die de meeste mensen nooit helemaal vertrouwden, werd ongeveer een halve seconde, een verbetering van grofweg vier keer, terwijl er minder CPU en minder bandbreedte wordt gebruikt dan voorheen. De volledige framerate telt hier ook mee: programmavideo was ongemerkt beperkt tot ongeveer 31 frames per seconde, ongeacht de bron, dus een share op 60 fps ziet er aan de ontvangende kant nu net zo vloeiend uit als op het eigen scherm van de presentator.

Wat dit betekent als je nu presenteert

Je hoeft hiervoor geen enkele instelling te wijzigen. Het zit in de schermdeelpipeline van de desktop-app en geldt of je nu één monitor deelt met een kleine ruimte of een volledige Studio-productie met meerdere bronnen draait, inclusief vMix-workflows die leunen op een snelle, voorspelbare feed. In Cliqer 3 is Studio-video op de Mac zero-copy: camerabeelden, bronnen en Program blijven in het GPU-geheugen, en de hardware-encoder leest Program rechtstreeks van het GPU-oppervlak. Cliqer 3 toont daarnaast continu de framerate van Program en de GPU- en CPU-belasting in de statusregel van Studio, zodat je de framerate tijdens de show zelf kunt controleren. Wil je naast het latentiewerk ook de kwaliteit afstemmen op de bandbreedte? De instellingen voor schermdelen behandelen codeckeuze, resolutie en bitrate, en desktop 2.2.0 voegde de optie toe om systeem- of microfoonaudio direct in een share op te nemen.

Voor hybride opstellingen waar de vertraging het meest zichtbaar was, vooral bij een spreker op afstand die naar een gedeeld scherm kijkt en live reageert, sluit dit aan bij onze gids over latentie bij schermdelen in hybride vergaderingen oplossen en onze uitleg over waarom clickerlatentie in milliseconden aan de bedieningskant net zo belangrijk is als aan de videokant.

Waar de rest van de latentie zit

Schermdelen is één deel van de reis. Het andere deel is het netwerkpad zelf: of de verbinding tussen presentator en kijker direct is of via een relay loopt, en wat er gebeurt op netwerken die direct peer-to-peerverkeer blokkeren. Die kant behandelen we, inclusief waarom die latentie op sommige netwerken nooit volledig te elimineren is, in TURN-servers uitgelegd en is WebRTC veilig.

Veelgestelde vragen

Probeer het zelf

De snelste manier om het verschil te voelen, is een scherm delen en naar het gezicht van iemand anders kijken op het moment dat die het ziet. Download Cliqer gratis en probeer een schermdeling op je eigen opstelling, of bekijk alle functies bij schermdelen en vergelijk abonnementen op prijzen.