Який бітрейт потрібен вашому стриму?

Якщо вам потрібна лише цифра — вона в таблиці нижче, у розділі «Що нам надсилати». Усе інше пояснює, чому після певного порогу ця цифра перестає допомагати і що змінювати натомість, коли ваш вихідний канал її не тягне.

Що відбувається з вашим потоком, коли він доходить до нас

Коли потік надходить у dcast, він перекодовується в драбину рівнів якості — 360p, 480p, 640p, 720p, 1080p, 1440p, 2160p, — щоб і глядач із телефоном у ліфті, і глядач на оптоволокні отримали картинку, яку можна дивитися. Кожен рівень кодується не вище власної стелі бітрейту, і ці стелі — налаштування платформи, а не те, що надсилаєте ви.

З цього випливають дві речі, і саме їх найчастіше розуміють навпаки.

Стелі — наші, а не ваші. Не можна підняти рівень, надсилаючи більше, і не можна опустити, надсилаючи менше. Ваш вхідний бітрейт визначає, скільки реальної деталізації є в драбини на вході, — це зовсім інше питання, і на нього відповідає наступний розділ.

Стелі не залежать від підписки. Тариф купує висоту верхнього рівня, а не бітрейт будь-якого рівня. Рівень 720p кодується однаково — чи він верхній у безкоштовного акаунта, чи десь посередині драбини у великого.

Ми переналаштовуємо ці стелі в міру того, як змінюються сервери та кодувальники, тому в цій статті навмисно немає таблиці їхніх значень: будь-яка цифра, надрукована тут, застаріла б задовго до того, як її перестануть цитувати. Структура стабільна, цифри — ні. І, як доводить решта статті, ваша картинка насправді залежить не від цифр на нашому боці.

Що нам надсилати

Ваш кодувальник надсилає один потік. З нього ми будуємо драбину. Отже, єдине, що ви насправді вирішуєте, — яким буде цей єдиний вхідний потік. І думати про це корисно так: надсилайте стільки, щоб верхній рівень мав реальну деталізацію для роботи, і не більше.

Ці діапазони — відправна точка, а не закон. Єдине правило, яке діє завжди: що б ви не надсилали, ваш вихідний канал має тримати це безперервно, а не лише в удалу хвилину.

Чому більший бітрейт перестає допомагати

Бітрейт — це бюджет даних за секунду, а не повзунок якості. Кодувальник отримує цей бюджет і мусить умістити в нього опис кожного кадру. Коли картинка майже не змінюється — людина говорить на статичному тлі, — описати наступний кадр дешево, і більший бюджет просто залишається невитраченим. Коли картинка змінюється скрізь одночасно — панорама по натовпу, гол, конфеті, — кодувальник не встигає описати все й починає спрощувати: замість вмісту блоку пікселів він надсилає один усереднений колір на весь блок. Це і є «квадрати». Це видима межа бюджету.

Ось чому та сама цифра дає двом людям різну картинку. Ваш знайомий із точнісінько такими самими налаштуваннями стримить статичний оверлей і вебкамеру; ви — сцену, де все рухається. Бюджет однаковий, рахунок зовсім різний.

Цим же пояснюється і форма рекомендацій вище. Підвищення бітрейту допомагає рівно до моменту, коли бюджет перестає бути обмеженням, а далі воно з’їдає запас вихідного каналу й нічого не дає. Немає такого налаштування, за якого статична голова, що говорить, виглядала б краще, ніж вона вже виглядає на 6000 kbps.

Запас — ось чому рівень має буфер, а не лише швидкість

Кожен рівень кодується не лише зі стелею, а й із буфером — вікном, у яке кодувальник може ненадовго вийти за стелю, а потім повернути борг. У нашій живій драбині це вікно зараз удвічі більше за стелю рівня. Це не слабина — це саме те, що зберігає дорогі моменти цілими.

Справжнє відео не однаково дороге по всій довжині. Різка склейка на нову сцену коштує значно більше, ніж секунда статичного кадру перед нею. Якби кодувальник мусив триматися стелі в кожну мить, він понівечив би саме ці моменти — склейки, спалахи, швидкі панорами, — а саме на них глядач і дивиться. Буфер обсягом у дві секунди даних дає йому змогу на мить витратити більше за стелю й повернутися під неї, тож середнє тримається, а піки виживають.

Та сама логіка працює й для вашого вихідного каналу — і саме тут ламається більшість зламаних трансляцій. Якщо виміряний вихідний канал у вас 10 Mbps, а кодувальник виставлений на 10 000 kbps, ви не залишили нічого ні для піків, ні для всіх інших у будівлі, хто сидить на тій самій лінії. Потік, виставлений точно в стелю свого підключення, — це потік, який почне втрачати кадри на першій же різкій склейці. Залишайте запас. Якщо спідтест показує 10 Mbps на віддачу, 6000 kbps — це не перестраховка, а налаштування, яке витримає всю трансляцію.

Слабкий канал — знижуйте роздільність, а не бітрейт

Це найкорисніший розворот у всій темі, і він протилежний тому, що більшість пробує насамперед.

Припустімо, ваш вихідний канал надійно тримає лише 3000 kbps. Уміститися можна двома способами: надіслати 1080p на 3000 kbps або 720p на 3000 kbps. Даних за секунду однаково. Але в кадрі 1080p пікселів більш ніж удвічі більше, ніж у 720p, тож за того самого бюджету кожному пікселю дістається менше половини уваги. Версія 1080p — це не чіткіша картинка за меншої смуги, а розмитіша картинка більшого розміру. Версія 720p, отримавши всі 3000 kbps на значно меншу кількість пікселів, виглядає чисто.

Тому, коли проблема в каналі, порядок дій такий: спершу знизьте роздільність і лише потім підженіть бітрейт так, щоб він із запасом уміщався в те, що лінія тягне в погану хвилину, а не в добру.

Частоту кадрів вирішуємо ми, а не ваш тариф

У живому тракті частота кадрів драбини — налаштування платформи, а не окремого акаунта, і на момент написання статті кожна пряма трансляція кодується в 30 fps, що б ви не надсилали. Підписка в цьому рішенні не бере участі взагалі: безкоштовний акаунт і акаунт на найвищому тарифі отримують з одного джерела однакову частоту кадрів.

Це корисно знати до того, як щось налаштовувати, бо це задає вашому бюджету вихідного каналу цілком певний напрямок: у живому тракті немає жодного сенсу викручувати кодувальник на 60 fps. Зайві кадри далі не проходять, а за фіксованого вхідного бітрейту вони забирають деталізацію в тих кадрів, які проходять. Якщо у вас швидкий рух, витрачайте бюджет на бітрейт, а не на частоту кадрів.

Завантажені відео йдуть окремим шляхом зі своїми правилами частоти кадрів, і ніщо з цього до них не стосується.

Що змінює ваш тариф, а що ні

Варто сказати прямо, бо саме тут найчастіше помиляються. У живому тракті тариф визначає висоту верхнього рівня — максимальну якість, яку може обрати глядач, — і більше нічого в картинці. Безкоштовні акаунти обмежені 720p, а платні тарифи піднімають цю стелю до 1080p, 1440p і 2160p.

Чого тариф не змінює: бітрейт будь-якого рівня, буфер, частоту кадрів, структуру ключових кадрів і налаштування кодувальника. Рівень 720p кодується однаково — чи він верхній у безкоштовного акаунта, чи третій у великого. Версії кодувальника з урізаною якістю не існує.

Сітка ключових кадрів і чому з нею не варто боротися

Одне налаштування вашого кодувальника справді взаємодіє з нашим — інтервал ключових кадрів. dcast нарізає живий потік на сегменти по 4 секунди, і в кожному сегменті 2 ключові кадри — один на межі й один посередині. Отже, внутрішній інтервал ключових кадрів — 2 секунди, і він обчислюється від підсумкової частоти кадрів, а не прив’язаний до фіксованої кількості кадрів.

Підлаштовуватися під це не потрібно. Кодувальник перекодовує те, що ви надсилаєте, і будує власну сітку. Але якщо ви виставите в себе незвичний інтервал ключових кадрів, сподіваючись знизити затримку далі ланцюжком, цього не станеться, а дуже довгий інтервал на вході погіршить перші миті після перепідключення. Інтервал ключових кадрів 2 секунди у вашому кодувальнику — надійний і нудний вибір.

П’ятихвилинна діагностика, коли картинка виглядає не так

«Квадрати», які з’являються лише в русі й зникають на статичних планах, — проблема бітрейту: бюджет скінчився там, де контент став дорогим. Підніміть вхідний бітрейт на щабель або опустіть роздільність на щабель.

«Квадрати», що накочують хвилями незалежно від того, що в кадрі, часто разом з артефактами звуку й зростаючим лічильником пропущених кадрів у кодувальнику, — це не проблема бітрейту: це ваш канал не доставляє того, що ви йому пообіцяли. Знижуйте бітрейт, доки лічильник пропущених кадрів не протримається на нулі цілих десять хвилин.

Картинка, м’яка скрізь і весь час, зокрема на статичних планах, — зазвичай проблема джерела, а не кодування: камера знімає в меншій роздільності, ніж ви думаєте, карта захоплення узгодила нижчий режим або сцена десь у вашому ланцюжку розтягується. Жоден бітрейт не виправить апскейл — збільшена картинка додає дані, а не деталі.

І якщо глядачі скаржаться на проблеми, яких ви у себе не бачите, пам’ятайте: ви дивитеся власний попередній перегляд, а не власний потік. Попередній перегляд ніколи не залишав вашої будівлі.