YouTube Live пише «No data is being received» — що це означає і як виправити
У цього повідомлення є чотири різні причини, і власний API YouTube точно визначає, про що саме воно звітує. Цей гайд розділяє випадки замість того, щоб перелічувати всі можливі виправлення підряд.
Ви відкриваєте YouTube Studio, панель stream health каже, що дані не надходять, а прев'ю лишається чорним. У самому повідомленні немає ані натяку, яка саме ланка зламалася — енкодер, мережа, налаштування чи сам відеофайл. У цьому й полягає головна проблема з ним.
YouTube Live Streaming API визначає ці стани дуже точно, і це робить повідомлення значно менш загадковим, ніж здається. Нижче — офіційні визначення, а далі чотири причини в тому порядку, в якому їх варто перевіряти, з діагностикою для кожної. Кожне твердження має посилання на джерело.
Що YouTube насправді має на увазі під «no data»
YouTube Studio показує спрощений badge, але під ним YouTube Live Streaming API віддає справжнє значення. Стрім має health status із чотирьох можливих станів, і визначення варто читати буквально.
Чотири стани health status, цитата з довідника Google:
- good — «Немає конфігураційних проблем із рівнем серйозності warning або гіршим».
- ok — «Немає конфігураційних проблем із рівнем серйозності error».
- bad — «У стріма є проблеми з рівнем серйозності error».
- noData — «Бекенд-сервери live-стрімінгу YouTube не мають жодної інформації про health status цього стріма».
Різниця, яку майже всі статті плутають
Перечитайте останнє визначення. noData не означає, що ваш стрім зламаний. Воно означає, що YouTube нема про що звітувати — немає вимірювань, немає діагнозу, нічого. Це інший стан, ніж стрім, який приходить погано: той звітує як bad.
Є ще одне, окреме поле — stream status. Його стан active означає «користувач отримує дані через цей стрім», а inactive — «користувач не отримує дані через цей стрім». Тобто стрім може бути inactive, поки його health показує noData, і ці два факти надходять від різних підсистем. Health говорить про якість, status — про наявність. Коли кажуть «YouTube показує no data», зазвичай мають на увазі обидва одночасно: нічого не приходить, тому й вимірювати нема чого.
Це має практичне значення. Якщо ви бачите bad, а не noData — пакети до YouTube доходять, і проблема в якості: bitrate, dropped frames, keyframes. Якщо ви справді бачите noData — пакети не доходять взагалі, і жодне налаштування енкодера цього не змінить. Ці випадки лікуються протилежно, тому універсальні чеклісти лише марнують ваш час.
Чотири місця, де може обірватися стрім
Між відеофайлом і глядачем YouTube є чотири ланки, і повідомлення не підказує, яка з них відмовила. Перевірка в такому порядку займає близько двох хвилин і одразу відкидає більшість випадків.
Чи енкодер узагалі щось відправляє?
Відкрийте статистику самого енкодера, перш ніж чіпати щось на боці YouTube. OBS показує поточний bitrate у рядку стану внизу; якщо там 0 kbps — з вашої машини нічого не виходить, і YouTube звітує абсолютно точно.
- В OBS подивіться на нижній рядок стану: вихідний bitrate і лічильник dropped frames.
- Bitrate 0 kbps означає, що проблема цілком локальна — YouTube тут ще ні до чого.
- Нормальний bitrate разом із noData на боці YouTube вказує на зʼєднання або ключ, а не на енкодер.
Чи ключ відповідає саме цій трансляції?
Ключ від іншої трансляції або згенерований наново після того, як ви його скопіювали, дає рівно цей симптом: енкодер спокійно підключається, а YouTube не показує нічого.
- Звірте ключ в енкодері символ у символ із Live Control Room.
- Перегенерація ключа в YouTube Studio миттєво робить старий недійсним.
- Офіційна порада YouTube щодо помилок запуску енкодера — отримати новий ключ і оновити енкодер.
Чи зʼєднання стабільне, а не просто швидке?
Швидкість віддачі й стабільність віддачі — різні речі, і стрімінг карає саме за другу. Канал, який у тесті показує 100 Mbps, цілком може зависати на дві секунди поспіль.
- Дивіться на відсоток dropped frames в енкодері, а не на результат спідтесту.
- Постійні dropped frames означають, що відмовляє маршрут до YouTube, а не ваше залізо.
- Корпоративні мережі, готельний Wi-Fi і деякі роутери блокують або ріжуть RTMP на порту 1935.
Чи взагалі є відео, яке грає?
Причина, яку перевіряють останньою, а варто часто першою: закінчилося саме джерело. Енкодеру нема що кодувати — він нічого й не відправляє, і YouTube звітує саме про це.
- Плейлист, що дійшов до кінця, перестає давати кадри, хоча енкодер лишається підключеним.
- Файл, який став нечитабельним посеред відтворення, дає той самий ефект.
- Це домінуюча причина на цілодобових стрімах без нагляду.
Неправильний stream key або endpoint
Це найчастіша причина й найпростіша для перевірки — тому їй місце на початку, а не у виносці. YouTube приймає RTMP-зʼєднання незалежно від того, чи дійсний ключ для тієї трансляції, яку ви дивитесь: handshake проходить успішно, і лише потім дані йдуть у нікуди.
Дві ситуації дають це регулярно. Перша — перегенерований ключ: ви створили новий у Live Control Room, а енкодер досі тримає попереднє значення. Друга — розбіжність між запланованою подією й постійним ключем, коли енкодер віддає в одне, а ви дивитесь інше.
Про сам ingest URL і значення кожної його частини є окремий гайд по RTMP для YouTube. Коротко: URL публічна й однакова для всіх, тому вона майже ніколи не буває причиною. Ідентифікує вас саме ключ.
Мережа: dropped frames і зависання
Коли енкодер очевидно відправляє, а ключ очевидно правильний — наступним підозрюваним стає канал між вами та ingest-серверами YouTube. Саме тут діагностика зазвичай зривається: людина запускає спідтест, бачить велике число й викреслює мережу зі списку.
Гілка на форумі OBS Studio показує цю пастку наочно. У користувача було 150 Mbps на завантаження й понад 100 Mbps на віддачу — і стрім усе одно не тримався. У логах зафіксовано 21 876 dropped frames, тобто 65,6% від усіх, через брак пропускної здатності або зависання зʼєднання. Модератори дійшли висновку, що збій десь на шляху до серверів YouTube, а не в енкодері чи залізі.
Корисний висновок такий: пропускна здатність і стабільність — різні вимірювання, і живим стрім тримає лише друге. Канал, який у середньому дає 100 Mbps, але зависає на дві секунди щохвилини, втрачатиме кадри безперервно, тоді як усі спідтести показуватимуть чудовий результат.
Що перевіряти, коли підозра на мережу:
- Відсоток dropped frames саме під час зависання, а не в середньому за сесію.
- Чи не збігаються провали з чимось запланованим — бекапи, оновлення, інший пристрій у мережі.
- Чи не фільтрується порт 1935. Якщо так, перехід на RTMPS через порт 443 часто проходить без проблем — це той самий порт, яким уже користується HTTPS.
- Чи не стоїть між енкодером та інтернетом VPN або захисний пристрій.
На сторінці усунення несправностей YouTube пропонує сортування, яке варто запозичити: якщо на проблеми скаржиться один глядач — швидше за все, це його зʼєднання; якщо кілька глядачів в одній мережі — справа в тій мережі; якщо глядачі з різних мереж — винен енкодер або ваш канал.
Налаштування, які YouTube відхиляє мовчки
Частина конфігурацій енкодера приймається на рівні протоколу, а потім дає непридатний стрім. Про проблему ніхто не попереджає — зʼєднання просто не перетворюється на трансляцію, яку можна дивитись.
Найчастіше на цьому спотикаються через keyframe interval. Офіційні налаштування енкодера YouTube рекомендують keyframe кожні 2 секунди й прямо зазначають: не перевищуйте 4 секунди. Перевищите — YouTube не зможе коректно нарізати стрім на сегменти, і це виглядає як трансляція, що не стартує або зависає на першому кадрі.
Офіційні налаштування YouTube — ті значення, які справді мають значення:
- Відеокодек: H.264 як обовʼязкова база; HEVC та AV1 — підтримувані альтернативи.
- Аудіокодек: AAC або MP3. Для 5.1 surround через RTMP/RTMPS працює лише AAC.
- Аудіо bitrate: 128 kbps для стерео, 384 kbps для 5.1 surround.
- Keyframe interval: рекомендовано 2 секунди, 4 секунди — жорстка стеля.
- Bitrate, 1080p 30 fps: рекомендовано 10 Mbps; на 60 fps — 12 Mbps.
- Bitrate, 720p 60 fps: 6 Mbps; 720p і нижче на 30 fps — 4 Mbps.
- Bitrate, 1440p: 15 Mbps на 30 fps, 24 Mbps на 60 fps.
- Bitrate, 2160p: 30 Mbps на 30 fps, 35 Mbps на 60 fps.
Якщо хочеться порахувати ці числа під власну роздільність і швидкість каналу, а не брати з таблиці, це напряму робить калькулятор бітрейту. А якщо стрім працює цілодобово, а не годину, ставтеся до рекомендованих значень як до стелі, а не як до цілі — чому саме так, розібрано в гайді про bitrate для цілодобових стрімів.
Коли зупиняється джерело, а не зʼєднання
Усе вище припускає, що є відео, яке можна відправляти. На стрімі без нагляду, який працює добами, значно ймовірніший інший збій: джерело перестало давати кадри, поки енкодер спокійно тримав зʼєднання.
Саме цей сценарій відрізняє цілодобовий стрім від двогодинної трансляції, і саме він погано описаний деінде — бо більшість порад пишуть для людини, яка сидить біля машини й бачить усе на власні очі.
Чотири способи, якими джерело зупиняється при живому зʼєднанні:
Плейлист закінчився
Найбуденніша й найчастіша причина. Плейлист без увімкненого зациклення доходить до кінця й зупиняється. Енкодер тримає зʼєднання відкритим, не відправляє нічого, і YouTube звітує про відсутність даних — цілком справедливо.
- Переконайтеся, що зациклення увімкнене, а не припускайте це — і що воно пережило останню зміну налаштувань.
- Порівняйте загальну тривалість плейлиста з тим, скільки стрім протримався до зупинки. Якщо числа збігаються — відповідь знайдена.
- Надійніше один довгий файл або справді циклічний плейлист, ніж черга, яка завершується.
Файл став нечитабельним посеред відтворення
Джерело на мережевій шарі чи зовнішньому диску може зникнути під працюючим енкодером. Енкодер не завжди падає з помилкою — він може зависнути в очікуванні байтів, які вже не прийдуть.
- Перевірте, чи було сховище з файлом доступним у той момент, коли стрім зупинився.
- Не переміщуйте, не перейменовуйте й не переконвертовуйте файл, який зараз стрімиться.
- На мережевому монтуванні розрив і дуже повільне читання для енкодера виглядають однаково.
Джерело читається надто повільно
Тонший різновид того самого. Якщо читання відео повільніше за його відтворення, енкодер голодує. Зʼєднання лишається, вихід стає переривчастим, а health псується ще до того, як зникне зовсім.
- Зверніть увагу, чи картинка почала запинатися перед зупинкою — така послідовність вказує на джерело, а не на мережу.
- Читання кількох файлів із високим бітрейтом з одного диска чи одного мережевого зʼєднання може його наситити.
- Копіювання файлу на локальний диск перед стрімом прибирає цю змінну повністю.
Машина заснула або процес помер
Банально, але трапляється часто. Комп'ютер пішов у сон, оновлення ОС перезавантажило систему, енкодер убив планувальник — трансляція лишилася налаштованою й порожньою.
- Вимкніть сон і автоматичні перезавантаження на машині, яка має стрімити без нагляду.
- Подивіться в системний журнал, чи не було перезапуску в момент зупинки стріма.
- Стріму, який має жити добами, не місце на робочому комп'ютері, яким ви користуєтесь для інших задач.
Чому швидке перепідключення робить гірше
Коли стрім падає, очевидна реакція — перепідключитися негайно, і більшість енкодерів пропонують автоматичну повторну спробу з коротким інтервалом. На цілодобовому стрімі це здатне перетворити один короткий збій на постійний.
YouTube не звільняє ingest-слот трансляції тієї ж миті, коли ваш енкодер зник. Перепідключіться до того, як попередню сесію згорнули, — і нове зʼєднання можуть відхилити. Це запускає ще одну спробу, яка приходить так само зарано. Виходить цикл, який виглядає так, ніби YouTube взагалі відмовляється приймати стрім, хоча насправді проблема в повторі, який ніколи не чекає достатньо. Ми знайшли це на власній інфраструктурі важким шляхом: затримка повтору стояла рівно на межі того, як YouTube згортає сесію, і це давало нескінченний цикл перепідключень. Збільшення затримки виправило все.
Якщо ви тримаєте власний енкодер, задайте повтору backoff, який зростає після кожної невдачі, замість фіксованого короткого інтервалу. Перша спроба через кілька секунд, далі — довші паузи: так система відновиться після справжнього збою й не довбатиме endpoint, який ще не готовий.
Це ж і чесний аргумент проти того, щоб тримати енкодер самому. Помітити зупинку, витримати правильну паузу, перепідключитися й продовжити з потрібної позиції — це робота, яку треба виконати о четвертій ранку, коли ніхто не дивиться. TheLoops робить це як частину сервісу: стрім під постійним наглядом і перезапускається автоматично, коли падає, без чиєїсь безсонної ночі.
Досить лагодити стріми о четвертій ранку
Завантажте відео один раз. Ми тримаємо його в ефірі цілодобово, стежимо безперервно й перезапускаємо автоматично, коли щось ламається.
Часті питання
Не обовʼязково, хоча це найчастіша окрема причина. API YouTube визначає noData як стан, коли сервери не мають жодної інформації про health стріма — а так буває і при неправильному ключі, і коли енкодер зупинився, і коли відмовила мережа, і коли закінчилося джерело. Спершу подивіться вихідний bitrate в енкодері: якщо там 0 kbps, ключ ні до чого, бо нічого й не відправляється.
Бо швидкість і стабільність — різні речі, а стрімінг залежить саме від другої. У задокументованому випадку на форумі OBS у людини було понад 100 Mbps віддачі, і при цьому 65,6% кадрів губилися через брак пропускної здатності та зависання зʼєднання. Дивіться на лічильник dropped frames під час збою, а не на спідтест після нього.
На стрімі без нагляду відповідь зазвичай у джерелі, а не в зʼєднанні. Плейлист дійшов до кінця, файл перестав читатися, або машина заснула чи перезавантажилась. Порівняйте загальну довжину плейлиста з тим, скільки стрім протримався: якщо збігається — плейлист просто закінчився.