Jak przyspieszyliśmy udostępnianie ekranu czterokrotnie

Opóźnienie udostępniania ekranu to jeden z tych problemów, które zauważasz dopiero wtedy, gdy jest źle. Prezenter przełącza na kolejny slajd, a widzowie oglądający udostępniony ekran dostrzegają to z wyczuwalnym poślizgiem. Nic się nie psuje, po prostu coś jest nie tak. W ciągu kilku wydań dokładnie przyjrzeliśmy się temu, skąd bierze się to opóźnienie w udostępnianiu ekranu w Cliqer, i zmniejszyliśmy stałe opóźnienie z ponad dwóch sekund do około pół sekundy, czyli mniej więcej czterokrotnie. Oto, jak to zrobiliśmy, opisane prostym językiem.

Nie będziemy ukrywać się za nazwami kodowymi ani udawać, że istniało jedno cudowne rozwiązanie. Były trzy osobne poprawki, każda wymierzona w inne miejsce, w którym kryło się opóźnienie, a ich efekty się sumowały.

Skąd w ogóle biorą się opóźnienia przy udostępnianiu ekranu

Gdy udostępniasz ekran, zanim widz zobaczy klatkę, muszą się wydarzyć trzy rzeczy: Twój komputer musi ją przechwycić, zakodować do postaci wideo i wysłać. Każdy z tych kroków może po cichu dodawać opóźnienie, a efekty się kumulują. Wolny enkoder, ostrożny bufor i czekanie na kolejną pełną klatkę mogą łatwo dać razem dwie lub trzy sekundy, nawet przy szybkim łączu.

Najtrudniejsze jest to, że żaden z tych etapów z osobna nie wygląda na zepsuty. Przechwytywanie działa. Kodowanie działa. Strumień dociera. Po prostu dociera za późno, a „po prostu za późno” trudno zdiagnozować bez mierzenia każdego etapu osobno.

Poprawka pierwsza: koniec z kodowaniem tego samego obrazu dwa razy

Pierwszym źródłem opóźnienia była zmarnowana praca. Udostępnianie ekranu i NDI było w tle kodowane dwukrotnie, osobno dla każdej ścieżki wyjściowej, a nieruchomy slajd był kodowany w kółko, mimo że na ekranie nic się nie zmieniało. To podwajało obciążenie enkodera bez żadnej korzyści wizualnej i sprawiało, że potok był zawsze bardziej zajęty, niż musiał, co przesuwa każdą klatkę dalej w kolejce.

Usunięcie zdublowanego przebiegu kodowania i pomijanie ponownego kodowania, gdy obraz się nie zmienił, od razu zwolniło sporo mocy procesora. Mniejsza rywalizacja o enkoder oznacza, że każda klatka, która faktycznie wymaga zakodowania, jest przetwarzana szybciej.

Poprawka druga: ciaśniejszy bufor bez utraty odporności

Drugim źródłem był bufor między enkoderem a siecią, czyli element, który pochłania krótkie zakłócenia sieci, żeby przycięcie na łączu nie zamieniło się w przycięcie na ekranie. Takie bufory to z natury kompromis: za mały sprawia, że drobne zakłócenie powoduje widoczne zniekształcenia, a za duży dodaje opóźnienie do każdej pojedynczej klatki na wypadek, gdyby coś poszło nie tak później.

Bufor miał hojnie ustawiony rozmiar, przez co w typowej sytuacji dodawał opóźnienie do każdej klatki, żeby zabezpieczyć się przed rzadkim przypadkiem. Zmniejszenie go skróciło najgorsze opóźnienie z kilku sekund do znacznie poniżej jednej, a jednocześnie nadal pozwala przetrwać krótkie zakłócenia sieci bez widocznych zniekształceń. To typ poprawki, która w diffie wygląda jak zmiana jednej małej liczby, a w rzeczywistości jest świadomą decyzją o tym, który rodzaj awarii wolisz.

Poprawka trzecia: nowi widzowie nie czekają już na kolejną klatkę kluczową

Trzecia poprawka dotyczyła konkretnego, bolesnego momentu: tego, co się dzieje, gdy ktoś dołącza do już trwającego udostępniania. Kompresja wideo polega na tym, że pełne klatki, zwane klatkami kluczowymi, wysyłane są tylko co jakiś czas, a pomiędzy nimi idą tańsze klatki typu „co się zmieniło od ostatniego razu”. Widz, który dołącza w trakcie strumienia, nie jest w stanie odczytać tych klatek pośrednich, dopóki nie otrzyma klatki kluczowej, od której może zacząć, a wcześniej oznaczało to czekanie na kolejną zaplanowaną, nawet do trzech sekund.

Rozwiązaniem było przechowywanie najnowszej klatki kluczowej w pamięci podręcznej i przekazywanie jej nowemu subskrybentowi w chwili dołączenia, zamiast kazać mu czekać na następną według harmonogramu. W połączeniu z taktowaniem klatek opartym na interwałach, opisanym w naszej dokumentacji udostępniania ekranu, nowi widzowie widzą teraz obraz w ciągu milisekund od dołączenia, zamiast czekać nawet trzy sekundy na kolejną klatkę kluczową.

Po zsumowaniu wszystkich trzech poprawek ponad dwusekundowe stałe opóźnienie, któremu większość osób nigdy do końca nie ufała, zmieniło się w mniej więcej pół sekundy, czyli około czterokrotną poprawę, przy mniejszym zużyciu procesora i przepustowości niż wcześniej. Liczy się tu też pełna liczba klatek na sekundę: wideo Programu było po cichu ograniczone do około 31 klatek na sekundę niezależnie od źródła, więc udostępnianie w 60 fps wygląda teraz po stronie odbiorcy równie płynnie jak na ekranie prezentera.

Co to oznacza, jeśli prezentujesz już teraz

Nic z tego nie wymaga zmiany ustawień. Działa w potoku udostępniania ekranu aplikacji desktopowej i obowiązuje niezależnie od tego, czy udostępniasz jeden monitor niewielkiej widowni, czy prowadzisz pełną produkcję w Studio z wieloma źródłami, w tym w workflow vMix, które opierają się na szybkim, przewidywalnym sygnale. W Cliqer 3 wideo w Studio na komputerach Mac działa w trybie zero copy: klatki z kamery, źródła i Program pozostają w pamięci GPU, a sprzętowy enkoder odczytuje Program bezpośrednio z powierzchni GPU. Cliqer 3 przez cały czas pokazuje też liczbę klatek Programu oraz obciążenie GPU i CPU w pasku stanu Studio, więc możesz samodzielnie sprawdzić liczbę klatek w trakcie wydarzenia. Jeśli oprócz pracy nad opóźnieniem chcesz dostroić jakość względem przepustowości, ustawienia udostępniania ekranu obejmują wybór kodeka, rozdzielczość i bitrate, a wersja desktopowa 2.2.0 dodała możliwość dołączenia dźwięku systemowego lub z mikrofonu bezpośrednio do udostępniania.

W konfiguracjach hybrydowych, w których opóźnienie było najbardziej widoczne, zwłaszcza gdy zdalny prezenter ogląda udostępniony ekran i reaguje na żywo, warto połączyć to z naszym poradnikiem o eliminowaniu opóźnień udostępniania ekranu w spotkaniach hybrydowych oraz z artykułem wyjaśniającym, dlaczego opóźnienie pilota do prezentacji w milisekundach ma po stronie sterowania równie duże znaczenie jak po stronie wideo.

Gdzie podziewa się reszta opóźnienia

Udostępnianie ekranu to jeden etap podróży. Drugim jest sama ścieżka sieciowa: czy połączenie między prezenterem a widzem jest bezpośrednie, czy przekazywane, i co się dzieje w sieciach, które blokują bezpośredni ruch peer-to-peer. Tę stronę omawiamy, łącznie z tym, dlaczego w niektórych sieciach tego opóźnienia nigdy nie da się całkowicie wyeliminować, w artykułach czym są serwery TURN i czy WebRTC jest bezpieczny.

FAQ

Wypróbuj sam

Najszybciej poczujesz różnicę, udostępniając ekran i obserwując twarz osoby, która go widzi. Pobierz Cliqer za darmo i wypróbuj udostępnianie ekranu we własnej konfiguracji, poznaj pełne możliwości udostępniania ekranu albo porównaj plany w cenniku.