Привіт! Мене звати Микола Аврамук, я QA та Streaming Engineer у Mixa.live.
Моя місія — надавати користувачам якісний продукт вчасно та в межах наявних ресурсів.
Я хочу поділитися своїм досвідом тестування прямих відеотрансляцій і отримати поради від спільноти. Один досвідчений QA якось сказав мені: “Пиши про те, що ти хотів би прочитати, коли починав.”
Коли ми читаємо статті про тестування стрімінгового відео, ми часто розглядаємо PSNR, VMAF і SSIM. Найкраще, коли система стабільна і працює відповідно до очікувань, тоді ми можемо почати тестування об’єктивних метрик, таких як VMAF.
Або коли ви вже працюєте в Netflix:
Netflix Video Quality at Scale with Cosmos Microservices
Toward a Better Quality Metric for the Video Community
Але ніхто не розповідає, що відбувається до цього етапу. Тут я поясню цей етап з точки зору інженера з якості.
Дисклеймер:
Цей матеріал надає короткий огляд без заглиблення в конкретику. Детальна інформація буде охоплена в наступних статтях.
Стратегія
Архітектура
Перед тим як тестувати щось, важливо зрозуміти призначення продукту, його структуру, компоненти та їх взаємодію. Ця інформація допоможе вам у прийнятті рішень щодо тестування.
Починайте планування QA якомога раніше. Підхід “Shift left” є ідеальним.
Більшість стрімінгових сервісів мають сервер транскодування або кластер таких серверів у своїй основі. Кожен сервер запускає програму з кодеками, декодерами, мультиплексорами, фільтрами та іншими модулями для виконання конкретних завдань.
Процес стрімінгового відео зазвичай включає такі етапи:
Кодування: Конвертація аудіо та відеоджерел у цифровий формат за допомогою кодера. Аналогові або камерні сигнали перетворюються в ефективні формати, такі як H.264 або H.265 (AVC та HEVC), які зберігають дані на низьких швидкостях.
Контейнеризація: Пакування закодованих відео та аудіо даних у контейнерний формат. MPEG-TS підходить для традиційних телекомунікацій, тоді як MP4, FLV, WebM та спеціалізовані контейнери використовуються для різних стрімінгових протоколів.
Адаптивне або однобітове стрімування: Вибір між адаптивним або однобітовим стрімуванням. Адаптивна стратегія кодує відео в різних роздільностях та швидкостях передачі, а програвач вибирає найбільш підходящий потік на основі умов мережі та інформації про пристрій. Однобітове стрімування передає конкретний потік.
Транспорт: Передача закодованих та упакованих відео даних через мережу. Різні механізми транспорту використовуються в залежності від обраного протоколу, такого як RTMP, SRT, HLS, MPEG-DASH і WebRTC.
Мережева передача: Передача відео даних на сервери, розташовані в різних регіонах, або на сервери мережі доставки контенту (CDN), забезпечуючи оптимальну швидкість та доступність для глядачів по всьому світу.
Декодування та відтворення: Декодування та відтворення відео даних на стороні глядача. Програвач вибирає відповідний декодер на основі контейнерного формату.
Готовий декодований потік ми будемо намагатися отримати та перевірити ці параметри.
Спочатку визначте, чи можна програму ізолювати для точної перевірки. Ізоляція програми економить час на виявлення проблем. Якщо ізоляція неможлива, використовуйте доступне середовище, але бажано, щоб тестове середовище відповідало виробничому.
Визначте операційну систему, на якій працює додаток, щоб підготувати інструменти для журналювання та збирання артефактів для швидшого відтворення та ізоляції проблем.
Що тестувати?
При плануванні тестування вам потрібно дослідити вимоги та задати ключові питання про особливості системи та що від неї очікується.
Стрімінгове відео передається за допомогою протоколу передачі. Це набір правил, які визначають, як відео та аудіо передаються через мережу. Наприклад, найпоширенішими є RTMP, SRT, HLS, MPEG-DASH та WebRTC.
Більшість систем підтримують декілька протоколів передачі, тому кожен з них потрібно тестувати окремо.
Будь-яка передача починається з встановлення з’єднання. Тому необхідно перевірити правильність встановлення з’єднань на основі реалізацій різних протоколів. Усі вони використовують клієнт-серверне з’єднання. WebRTC може бути також клієнт-клієнт.
Необхідно перевірити негативні сценарії, коли з’єднання не повинно встановлюватися, та різні випадки, пов’язані з контролем доступу.
Детальний аналіз можливий лише якщо частина транспортного потоку записана, щоб її можна було розібрати пізніше. Ця техніка відома як тестування у відкладеному часі.
Для тестування потоку нам потрібно отримати, декодувати та зберегти його в контейнері. Візьмемо SRT як приклад. Для перевірки встановлення з’єднання можна використовувати Wireshark для захоплення всього трафіку та аналізу як встановлення з’єднання, так і подальшої передачі. Ось гарне пояснення, як це зробити:
Ми отримуємо цей потік за допомогою доступного декодера та зберігаємо його в контейнері. Можна прочитати гарний гайд про контейнери тут.
Ми можемо перейти до перевірки параметрів транспортного потоку. Це включає відео, аудіо, субтитри та метадані.
Для перевірки роботи вашого кодера згідно з вимогами ви закодуєте потік, передасте його та отримаєте як користувач, щоб перевірити параметри потоку та порівняти їх з тими, що ви вказали на кодері.
Наприклад, розглянемо ці параметри потоку MPEG TS, отриманого за допомогою SRT:
Відео:
PID: використовується в транспортних потоках MPEG-2, які зазвичай використовуються для передачі відео та аудіо в мережах та мовних системах. Він використовується для ідентифікації різних типів даних, таких як відео, аудіо, субтитри тощо, та допомагає забезпечити їх правильну передачу та синхронізацію. Я зустрічав системи, які очікували відео та аудіо на певних номерах PID, тому мінімум, що ви повинні перевірити, це які номери присвоєні вашим потокам. Перевірте кілька PID з різним вмістом.
Codec: апаратне або програмне забезпечення, що стискає та розпаковує цифрове відео, щоб зменшити розмір файлів та полегшити їх зберігання та розповсюдження. Перевірте лише ті, які підтримуються вашим кодером. Найпопулярнішими на даний момент є H.264, H.265, VP9, AV1, MPEG-4. Зауважте, що деякі кодеки можуть вимагати багато ресурсів, тому гірше, якщо не підтримується або не налаштоване багатопоточність, і все навантаження припадає на одне ядро, яке буде перевантажене більш ніж на 70-80%. У цьому випадку сервер може приглушити потік, потік може пошкодитися, і тести будуть ненадійними.
Profile: Вони декларуються за допомогою коду профілю (profile_idc), а іноді й набору додаткових обмежень, застосованих у кодері. Код профілю та вказані обмеження дозволяють декодеру розпізнавати вимоги до декодування цього конкретного потоку.
Level: Це набір обмежень, що вказують на необхідний рівень продуктивності декодера для профілю. Наприклад, рівень підтримки у профілі визначає максимальну роздільність, частоту кадрів та бітрейт, які декодер може використовувати. Декодер, який відповідає певному рівню, повинен мати можливість декодувати всі потоки, закодовані для цього рівня та всіх нижчих рівнів.
Chroma format: практика кодування зображень, використовуючи нижчу роздільність для інформації про хромацію, ніж для лумації, враховуючи нижчу гостроту людської зорової системи для відмінностей кольорів, ніж для яскравості.
Resolution: розмір кадрів у вашому потоці. Один з основних параметрів. Якість вашого відео буде кращою при збільшенні роздільності. Але чим вища роздільність, тим вищий необхідний бітрейт. І не забувайте враховувати навантаження на систему для 2, 4, 8K. Рекомендовані бітрейти для різних роздільностей:
SD (Стандартна чіткість): 480p: Близько 500 Кбіт/с до 1.5 Мбіт/с
HD (Висока чіткість):
720p: Близько 1.5 Мбіт/с до 4 Мбіт/с
1080p: Близько 3 Мбіт/с до 6 Мбіт/с
Full HD: 1080p: Близько 3 Мбіт/с до 6 Мбіт/с
2K: 1440p: Близько 6 Мбіт/с до 10 Мбіт/с
4K: 2160p: Близько 12 Мбіт/с до 25 Мбіт/с
8K: 4320p: Може варіюватися, але зазвичай більше 30 Мбіт/с
Bitrate: кількість даних, що передається за одиницю часу під час відтворення або передачі відео. Вимірюється у бітах на секунду (біт/с). Відтворіть отримані відео та оцініть якість кожного варіанту бітрейту. Це можна зробити за допомогою візуальної оцінки або об’єктивних метрик якості, таких як PSNR (Пікове співвідношення сигнал/шум) або SSIM (Індекс структурної подібності).
Може бути CBR (Constant Bit Rate): CBR означає, що бітрейт залишається постійним протягом всього відео. Незалежно від складності контенту, однакова кількість даних використовується на всіх етапах кодування.
VBR (Variable Bit Rate): VBR означає, що бітрейт варіюється залежно від складності контенту. Чим складніша сцена, тим більше даних потрібно передавати.
- Частота кадрів: частота, з якою передаються відео кадри. Є 24, 25, 30, 50, 60 і 120 кадрів за секунду.
Частоту кадрів можна перевірити за допомогою таких інструментів, як ffprobe, mediainfo або VLC (хоча VLC іноді може вводити в оману). Для перевірки частоти кадрів бажано використовувати високоякісні вхідні дані, щоб ви могли бачити номер кожного кадру та переконатися, що жоден кадр не втрачено, переглянувши кожен кадр.
Частота кадрів та бітрейт можуть мати або CFR (Constant Frame Rate): У цьому режимі кожен кадр кодується на постійній швидкості, і все відео використовує однакову кількість кадрів за секунду. VFR (Variable Frame Rate): У цьому режимі частота кадрів може змінюватися залежно від складності контенту. Це може бути корисно для ситуацій, коли деякі частини відео менш складні і можуть використовувати менше кадрів за секунду для економії даних, тоді як більш складні сцени можуть мати більше кадрів для забезпечення кращої якості.
- GOP (Group of Pictures): У відеокодуванні GOP — це послідовність відеокадрів, яка включає ключовий кадр (I-кадр), один або більше передбачених кадрів (P-кадрів) та бінаправлені кадри (B-кадри), які використовують інформацію з попередніх або майбутніх кадрів для стиснення даних.
I-кадр (ключовий кадр): Це кадр, який не залежить від інших кадрів у GOP. Він містить повну інформацію про відеосцену і може бути декодований самостійно. Оскільки I-кадри не залежать від інших кадрів, вони зазвичай мають більший розмір, ніж інші типи кадрів.
P-кадр (передбачений кадр): Ці кадри передбачені на основі I-кадрів та інших P-кадрів у попередніх GOP. Вони містять лише зміни відносно попередніх кадрів, що дозволяє зберігати їх з меншими даними.
B-кадр (між I та P кадрами): Ці кадри містять інформацію на основі двох інших кадрів - I та P. Вони можуть додатково зменшити розмір даних.
B-кадри зазвичай не використовуються в потоковому відео з низькою затримкою з наступних причин:
Затримка обробки: Відеокодеки потребують більше обчислень для декодування B-кадрів, оскільки вони повинні бути створені на основі інших кадрів. Це може призвести до збільшення загальної затримки відеопотоку.
Затримка передачі: Використання B-кадрів може збільшити кількість даних, які потрібно передати для відтворення відео. Це може вплинути на пропускну здатність мережі та збільшити затримку передачі даних.
Якість інтерполяції: Використання B-кадрів потребує інтерполяції між референсними кадрами (I або P) для створення B-кадрів. Це може призвести до деякого рівня додаткових артефактів або зниження якості відтворення.
Можлива втрата синхронізації: У разі втрати B-кадру може виникнути проблема з декодуванням наступних кадрів, які можуть залежати від нього. Це може призвести до зниження якості відтворення або затримки відеопотоку.
Перевірте, чи правильно ваш кодер налаштовує структуру GOP. Підготуйте різні варіанти тестових даних з різними розмірами та вмістом GOP.
Структуру GOP у потоці можна перевірити за допомогою спеціальних інструментів.
Інтервал ключових кадрів: показує відстань між ключовими I кадрами. Він вказується або у кількості кадрів, або у секундах. Можна підготувати різні варіанти тестових даних, починаючи з відео, де всі кадри є ключовими, і до 10 секунд між ключовими кадрами. Ми спостерігаємо, як поводиться кодер, який кодує такі відстані, і декодер, який їх декодує. Оцінюємо якість зображення при різних інтервалах ключових кадрів.
Колірний простір: Описує, як масив піксельних значень повинен відображатися на екрані. Він надає інформацію про те, як піксельні значення зберігаються у файлі, а також діапазон та значення цих значень. Ми перевіряємо, чи правильно декодер розуміє закодоване відео при різних значеннях, наприклад:
[BT.601]("Standard Definition" або SD)
[BT.709]("High Definition" або HD)
[BT.2020]("Ultra-High-Definition" або UHD)
Глибина кольору: Глибина кольору у відео відноситься до кількості бітів, що використовуються для представлення кольорової інформації кожного пікселя на зображенні або кадрі. Звичайні глибини кольору у відео становлять 8-біт, 10-біт та 12-біт. Ми перевіряємо кожне значення.
- Тип сканування: Прогресивне та Черезрядкове — це два різні підходи до відображення зображення на екрані, особливо у відео.
Прогресивне сканування: У цьому режимі кожен кадр відео відображається повністю, і всі лінії зображення обробляються одночасно. Усі пікселі на екрані оновлюються відразу, що робить зображення чіткішим і плавнішим. Відео у форматах, таких як 720p, 1080p, 4K тощо, використовують прогресивне сканування.
Черезрядкове сканування: У цьому режимі кадр ділиться на дві половини - парні та непарні лінії. Спочатку відображаються всі парні лінії, а потім непарні. Це було винайдено для зменшення кількості інформації, яку потрібно передавати через обмежені канали зв’язку.
- Співвідношення сторін: співвідношення ширини до висоти відеокадру. Ваша система повинна правильно розуміти кожен тип і додавати чорні смуги за необхідності або передавати лише корисний вміст відповідно до вашого співвідношення сторін. Ми перевіряємо популярні значення та ті, що вказані у вимогах.
- Синхронізація аудіо/відео: синхронізація аудіо та відео. Відома як lipsync. Ми готуємо відповідний контент, у якому легко зрозуміти затримку між звуком та зображенням.
NTP синхронізація: Якщо ваш сервіс підтримує синхронізацію потоків на основі таймкодів, потрібно перевірити, що вона працює правильно. NTP працює на синхронізації ваших потоків через відеокодери та декодери. NTP означає Протокол мережевого часу, стандарт інтернету, який функціонує, синхронізуючи ваші сервери та пристрої з координованим універсальним часом (UTC). NTP працює, синхронізуючи ваші пристрої (у цьому випадку кодери та декодери) з NTP сервером, який у свою чергу синхронізується з “головним” годинником (часто атомним або GPS годинником). NTP точний до десятків мілісекунд через інтернет і може бути точним до субмілісекундних рівнів в ідеальних умовах. І ця точність від головного годинника до вашого пристрою. Тому ваші пристрої (усі, які повинні бути підключені до одного NTP сервера) будуть дуже близькі одне до одного за точністю часу.
PTS/DTS: PTS (Presentation Time Stamp) вказує час, коли конкретний кадр або аудіофрагмент повинен бути відображений на екрані або відтворений на аудіовиході. DTS (Decoding Time Stamp) вказує час, коли даний кадр або аудіофрагмент повинен бути декодований. Ось гарний опис, як перевірити правильність цих часових міток у відеопотоці.
Затримка: Затримка — це затримка між моментом створення відеосигналу на джерелі та моментом його відтворення на стороні кінцевого користувача.
Як і в будь-яких інших методологіях вимірювання, є більш або менш точні способи зробити це. Звичайний метод, який багато хто використовує, це поставити високоточний цифровий секундомір перед камерою та зробити фотографію під час декодування потоку на екрані. Але якщо цього вам недостатньо, є наукові праці, де можна зробити точніші вимірювання.
Аудіо:
PID: Перевірте, що PID мають очікувані номери і що вони відтворюються правильно.
Codec: Як і відео, аудіо має свої кодеки AAC, MP3, AC3, DTS, а також незжатий PCM аудіо, який використовується для точної передачі аудіосигналу без стиснення даних.
Bitrate: 96, 128, 192, 256 перевірте, що кодер правильно кодує значення та що звук передається без спотворень.
Channel layout: Перевірте різні схеми звукових каналів, такі як моно, стерео (2.0), 2.1, 5.1, 7.1, 7.1.2, та 9.1. Підготуйте різні комбінації тестових даних, щоб переконатися, що транскодер правильно їх обробляє.
Sample rate: Частота дискретизації — це параметр, що визначає, скільки разів на секунду дані збираються з аналогового аудіо для його перетворення в цифровий формат. Це одна з ключових характеристик цифрового аудіо. Частота дискретизації вимірюється в герцах (Гц) і вказує кількість аудіозразків, записаних за секунду. Стандартна частота дискретизації — 44100 Гц або 48000 Гц.
Bit depth: Глибина біта — це параметр, що визначає точність збереження або передачі аудіоінформації в цифровому форматі. Вимірюється в бітах і вказує, скільки різних значень можна представити для кожного аудіозразка. Чим вища глибина біта, тим більше можливих значень можна записати для кожного звукового зразка, що призводить до більшої точності та деталізації звуку. Перевірте загальні значення: 8, 16, 24, 32 біти.
Використовуйте тестові дані різного вмісту: людський голос, музика, шум, і різні рівні аудіотону. Також перевірте пікові значення та кліпування (>0dB).
Метадані:
Ви повинні перевірити метадані транспортного потоку, і для цього вам потрібно як мінімум зрозуміти, що це таке:
Program Association Table (PAT): Ця таблиця надає інформацію про доступні програми в потоці MPEG-TS. Вона включає ідентифікатор таблиці програм (PMT) для кожної програми, дозволяючи приймачам знайти відповідну PMT для додаткової інформації.
Program Map Table (PMT): PMT надає деталі про компоненти конкретної програми, такі як аудіопотоки, відеопотоки, субтитри та інші дані. Кожен компонент ідентифікується за допомогою ідентифікатора пакета (PID), і PMT допомагає приймачам зрозуміти, як обробляти та декодувати різні компоненти.
Service Information (SI): Метадані SI містять інформацію про сервіси, такі як назви програм, описи та інформацію про провайдерів сервісів. Ці метадані допомагають користувачам визначити вміст, який вони хочуть переглянути.
Conditional Access Table (CAT): Ця таблиця містить інформацію, пов’язану з системами умовного доступу, які контролюють шифрування та дешифрування вмісту для авторизованих глядачів.
Event Information Table (EIT): Метадані EIT надають деталі про заплановані події, включаючи час початку, тривалість та назви програм. Вони особливо корисні для електронних програмних гідів (EPG), які допомагають користувачам орієнтуватися у доступному контенті.
Network Information Table (NIT): Метадані NIT містять інформацію про саму мережу, такі як параметри конфігурації, частоту та деталі модуляції. Це особливо важливо для приймачів, щоб правильно налаштуватися на бажані канали.
Time and Date Table (TDT): Метадані TDT передають поточну інформацію про час та дату в потоці MPEG-TS. Вони допомагають забезпечити синхронізацію між передавачем та приймачем.
Descriptors: Описувачі — це невеликі частини метаданих, які надають додаткову інформацію про вміст або компоненти в потоці MPEG-TS. Вони можуть містити деталі, такі як формати аудіо та відео, інформацію про мову тощо.
Деякі великі стрімінгові платформи, такі як YouTube, повідомлять вам, що якщо ви хочете отримати сертифікацію від нас, будь ласка, включайте правильні метадані в кожен з ваших потоків (такі як назва компанії або кодера), щоб ми могли легко ідентифікувати вас у разі виникнення проблем.
Статистика в реальному часі
Оскільки ми взяли протокол стрімінгу SRT як приклад, необхідно зазначити, що SRT надає потужний набір статистичних даних на сокеті. Ці дані можна використовувати для моніторингу здоров’я сокета та відстеження несправної поведінки. Статистика розраховується незалежно на кожній стороні (приймач та відправник) і не обмінюється між партнерами, якщо це не вказано явним чином. Наші розробники створили програвач для тестування, який може відображати ці статистичні дані в реальному часі, і ви можете спостерігати значення багатьох параметрів. Незабаром ми плануємо зробити його відкритим кодом. Але давайте поговоримо про тестування SRT в інший раз.
Тестове середовище:
Інтернет-з’єднання: Перед тестуванням стрімінгу переконайтеся, що у вас стабільне інтернет-з’єднання з високою пропускною здатністю. Найкраще використовувати Ethernet-з’єднання зі швидкістю 1 Гбіт/с. І використовуйте Wi-Fi лише для тестування різних сценаріїв пропускної здатності (щоб змоделювати типового користувача) або інструментів, які дозволяють гнучко налаштовувати пропускну здатність, затримку, втрату пакетів тощо.
Ви можете використовувати інструменти, такі як Netflix’s Fast або Speedtest або інструмент Twitch, щоб перевірити вашу мережу.
Тестові дані:
Підготуйте багато тестових даних. Тут потрібно знайти золоту середину для всіх описаних вище параметрів, залежно від того, які використовуються частіше. Добре мати записані тестові відео, а також живі, такі як потік з вашої камери або апаратного кодера. Вибирайте як складний, так і простий тестовий контент, оскільки це допоможе змоделювати різні умови тестування.
Ось деякі посилання на відкриті тестові відео:
потоки:
файли:
Типи тестування:
Юніт тестування
На першому етапі моліться Богу, щоб розробник написав якісь юніт тести та перевірив найменші частини системи.
Тестування компонентів
Це перший рівень тестування, де перевіряються окремі компоненти вашої системи на правильне функціонування. Було б чудово, якби ви могли окремо тестувати, як працюють кодер, декодер, мультиплексори, фільтри тощо.
Інтеграційне тестування
Тестування інтеграції компонентів: Тут ви можете почати розробляти випадки, де ваші модулі можуть взаємодіяти один з одним та моделювати випадки, коли хтось не виконує своє завдання як очікується.
Тестування інтеграції системи: На цьому рівні ви перевіряєте інтеграцію системи в цілому. Це включає перевірку взаємодії між різними компонентами, серверами, клієнтами та іншими частинами системи.
Тестування інтеграції апаратного та програмного забезпечення: Цей тип тестування зосереджений на перевірці взаємодії між апаратними та програмними компонентами системи.
Тестування інтеграції програмного забезпечення: Тут ви зосереджуєтесь на інтеграції програмних компонентів, таких як програми, бібліотеки, сервіси та інші програмні модулі, що використовуються для стрімінгу.
Системне тестування
На цьому етапі у вас вже є вся система, і ви перевіряєте, чи відповідає вона специфікаціям, працює коректно та відповідає вимогам користувачів.
Після цього ви можете перейти до:
Stability
Load
Stress
Failover and Recovery
Scalability
Volume
Reliability
Але давайте поговоримо про ці типи пізніше, бо я ніколи не закінчу цю статтю.
Інструменти:
Переконайтеся, що ви підготували інструменти, які будете використовувати для конвертації, передачі, прийому та аналізу потоків. Серед них є відкриті або пробні версії, які будуть достатні.
Ось ті, які я використовую:
ffmpeg
ffprobe
mediainfo
ffplay
ffmetrics
ffbitrate
Elecard:
Stream Eye
Quality Estimator
Stream Analyzer
Quality Gates
HandBrake
VidCoder
VQProbe
NetBalancer
NetLimiter
OBS
vMix
VLC
Звітування:
Важливо підкріплювати всі знайдені вами баги кроками, логами, тестовими даними, скріншотами та відео. Тоді ваші розробники будуть щасливі, і вас не засипатимуть запитами про допомогу.
Висновки:
Щоб надати користувачеві якісний продукт, вам потрібно визначити, що саме ви робите, та створити добре продуману стратегію тестування на основі цього, що може запобігти та зменшити більшість проблем.
Починайте тестування до реалізації функціональності (shift-left), оскільки тестування вимагає багато ресурсів(особливо часу).
Вивчайте та розумійте, як працює ваша система, з яких компонентів вона складається та як вони взаємодіють.
Правильно пріоритезуйте залежно від використання вашого продукту.
Будьте уважним спостерігачем.