Jaki bitrate ustawić do transmisji na żywo

Transmisja leci, wszystko gra, kamera stoi na statywie i nagle operator robi zwykły najazd na mówcę. I w tym momencie obraz sypie się w klocki jak Tetris po dwóch głębszych. Mówca mówi dalej, dźwięk jest czysty, tylko twarz ma teraz rozdzielczość znaczka pocztowego.

Wtedy człowiek robi jedyną rzecz, jaka przychodzi do głowy: wchodzi w ustawienia i podbija bitrate. Czasem pomaga. A czasem po pięciu minutach transmisja zaczyna się zacinać już całkiem — i wtedy robi się naprawdę wesoło, bo właśnie własnoręcznie zamieniło się brzydki obraz na żaden.

Zanim pójdziemy dalej: bitrate to po prostu ile danych na sekundę wypuszczasz w świat. Podaje się to w kilobitach na sekundę, kb/s, i taką liczbę wpisujesz w OBS-ie w Ustawienia → Wyjście → Przepływność. W vMiksie siedzi to w ustawieniach streamu przy wyborze jakości, w sprzętowych enkoderach pod nazwą „bitrate” albo „video bitrate”. Wszędzie to samo pole, wszędzie jedna liczba.

Dlaczego nie ma jednej dobrej liczby

Bo ta liczba nie zależy od ciebie. Zależy od trzech różnych rzeczy naraz, każda ma innego właściciela i każda potrafi ci powiedzieć „nie”.

Pierwszy właściciel to twoje łącze — ono ma fizyczną granicę, ile jest w stanie wysłać w górę. Drugi to platforma: YouTube, Twitch czy Facebook mają własne limity i wyżej po prostu cię nie wpuszczą. Trzeci to sam obraz: statyczna gadająca głowa potrzebuje znacznie mniej danych niż mecz, na którym połowa kadru rusza się bez przerwy.

Każdy z nich ustawia własny sufit. Ty pracujesz pod najniższym z nich — nie pod średnią, nie pod tym, który ci się najbardziej podoba. Nazywam to sobie regułą trzech sufitów i szczerze mówiąc, odkąd tak to poukładałem, przestałem zgadywać.

Sufit pierwszy: twoje łącze, czyli weź połowę i nie dyskutuj

Zrób test prędkości i popatrz wyłącznie na wysyłanie. Nie na pobieranie — to jest ta duża, ładna liczba, którą sprzedawca wypisał na umowie i która do transmisji nie służy do niczego. Wysyłanie bywa kilkanaście razy mniejsze i to ono cię ogranicza.

A potem weź połowę tego wyniku. Nie 80 procent, nie „prawie tyle” — połowę.

Wiem, jak to brzmi. Przy pierwszym razie miałem odruch, żeby jednak wpisać więcej, bo przecież test wyraźnie pokazał, ile łącze daje radę. Otóż test pokazał, ile daje radę przez te osiem sekund, kiedy trwał. Transmisja trwa dwie godziny, a w międzyczasie ktoś w tym samym budynku puści aktualizację systemu, ktoś inny wrzuci film na dysk w chmurze i twoja piękna liczba przestaje być prawdą dokładnie wtedy, kiedy najbardziej jej potrzebujesz.

Ta druga połowa to nie jest ostrożność. To jest miejsce, w którym transmisja przeżywa to, że internet ma gorsze dni.

Sufit drugi: platforma i tak zrobi po swojemu

Tu jest najprościej, bo liczby są podane wprost, tylko nikt ich nie czyta.

Twitch przyjmuje najwyżej 6000 kb/s i to jest twarda ściana, powyżej której nie ma sensu nawet próbować. YouTube jest znacznie bardziej pojemny i dla obrazu 1080p przy 60 klatkach podaje 12 Mb/s w H.264, czyli mniej więcej dwa razy tyle co Twitch. Facebook trzyma się najniżej z całej trójki i akurat jego liczbę warto sprawdzić bezpośrednio w pomocy przed samą transmisją, bo bywa zmieniana.

Co się dzieje, jeśli wpiszesz więcej, niż platforma przyjmuje? Nie dostajesz lepszego obrazu. Dostajesz obraz przycięty po ich stronie albo, częściej, transmisję, która się rwie — i pół wieczoru szukania winnego w kablach i routerze, podczas gdy winny siedzi w jednym polu w twoich własnych ustawieniach.

Jeszcze jedno, o czym łatwo zapomnieć przy nadawaniu na kilka platform naraz: skoro idzie jeden sygnał w kilka miejsc, to obowiązuje cię najniższy limit z nich wszystkich. Puszczasz jednocześnie na Twitcha i YouTube’a? Twoim sufitem jest Twitch.

Sufit trzeci: obraz, czyli ruch kosztuje, nie piksele

To jest ten, który wszyscy liczą źle, łącznie ze mną przez dobrych kilka lat.

Intuicja podpowiada, że im większa rozdzielczość, tym więcej danych potrzeba. To prawda, ale w mniejszym stopniu, niż się wydaje. Znacznie ważniejsze jest, ile w kadrze się rusza. Kompresja wideo działa w uproszczeniu tak, że zapisuje jedną klatkę porządnie, a przez chwilę potem notuje już tylko różnice — co się zmieniło względem poprzedniej.

Jeżeli w kadrze siedzi mówca na tle ściany, tych różnic jest tyle co nic: ruszają się usta i od czasu do czasu ręka. Ale kiedy operator zrobi najazd, zmienia się każdy piksel w kadrze naraz i nagle trzeba zapisać wszystko od nowa. Dlatego obraz najczęściej sypie się w klocki dokładnie przy ruchu kamery, a nie w spokojnych ujęciach.

Praktycznie: gadająca głowa, konferencja, webinar w 1080p przy 30 klatkach wyglądają dobrze już przy jakichś 5000 kb/s. Koncert, sport, kamera z ręki, tło z ruchomą grafiką albo dym ze sceny potrzebują wyraźnie więcej — i to jest moment, w którym warto raczej zejść z rozdzielczości, niż udawać, że jest dobrze.

Jak rozpoznać, że wpisałeś złą liczbę

Zanim zaczniesz cokolwiek zmieniać, sprawdź, którą stronę zawaliłeś. Objawy są dwa, są przeciwne, a lekarstwo na jeden pogarsza drugi.

Obraz się zacina, przeskakuje, dźwięk ucieka do przodu. Otwórz w OBS-ie Widok → Statystyki i popatrz na „klatki pominięte z powodu sieci”. Jeśli ta liczba rośnie w trakcie transmisji, wpisałeś za dużo — twoje łącze tego nie unosi i program wyrzuca za burtę to, czego nie zdążył wysłać. Schodzisz z bitrate’u, nie podnosisz.

Obraz leci płynnie, ale przy ruchu rozpada się w kwadraty i twarze robią się z plasteliny. Nic się nie zacina, licznik pominiętych klatek stoi. To jest objaw za małej liczby jak na to, co pokazujesz. Tu masz wybór: albo podnosisz bitrate, jeśli sufit łącza i platformy na to pozwalają, albo — i to jest zwykle lepsze wyjście — zostawiasz liczbę i schodzisz z rozdzielczości.

Bo tu jest sedno, którego długo nie łapałem: uczciwe 720p przy 60 klatkach wygląda lepiej niż zagłodzone 1080p60 przy tej samej przepływności. Widz nie ogląda etykietki z rozdzielczością. Widz ogląda, czy twarz jest twarzą, czy plamą.

Dwa pola, które trzeba ustawić raz i zapomnieć

Przy bitrate stoją w OBS-ie dwa ustawienia, które robią połowę roboty, a prawie nikt ich nie rusza.

Pierwsze to tryb kontroli przepływności. Ustaw CBR, czyli stałą. Nie zmienną, nie „jakość”. Platformy transmisyjne lubią równy strumień i przy zmiennej przepływności potrafią się krztusić w najmniej wygodnym momencie. Zmienna jest świetna do nagrywania na dysk — do nadawania na żywo nie.

Drugie to odstęp klatek kluczowych. Wpisz 2 sekundy. YouTube podaje to wprost jako zalecenie, Twitch tak samo, i to nie jest kaprys: klatka kluczowa to ta jedna zapisana porządnie, od której zaczyna się odtwarzanie. Jeśli zostawisz to na „auto”, odstęp potrafi urosnąć — i wtedy każde drobne potknięcie kończy się zamrożeniem obrazu na kilkanaście sekund zamiast na dwie.

To, co bym wpisał, gdybym miał dziesięć sekund

Bez testów, bez liczenia, jedno ustawienie, które nigdzie nie przegrywa: 1080p, 30 klatek, 6000 kb/s, CBR, klatka kluczowa co 2 sekundy, dźwięk 128 kb/s. Mieści się pod limitem Twitcha, jest daleko pod sufitem YouTube’a, a przy typowym wydarzeniu z gadającymi ludźmi wygląda porządnie.

Potem, jak już masz chwilę, robisz test wysyłania i sprawdzasz, czy połowa wyniku nie jest przypadkiem niższa niż te 6000. Jeśli jest — schodzisz. Jeśli jest wyraźnie wyższa, a puszczasz coś ruchliwego, możesz podejść wyżej, ale tylko na YouTubie i tylko po sprawdzeniu, że statystyki nie zaczynają gubić klatek.

I na koniec uczciwie: nawet to nie jest odporne na wszystko. Robiłem transmisję, na której policzyłem wszystkie trzy sufity, wpisałem ładną bezpieczną liczbę i obraz i tak zaczął przycinać, bo w budynku obok ruszyła impreza, a siedzieliśmy na wspólnym łączu. Cokolwiek to znaczy — na takie rzeczy żadne pole w ustawieniach nie pomoże. Pomaga własny modem LTE w torbie i świadomość, że to się zdarza.

Ale to już inna opowieść.

Tematy: streaming · warsztat · OBS