Привіт! Мене звати Микола Аврамук. Я QA та Streaming Engineer в Switcher.ai.
Хочу поділитись своїм досвідом тестування лайв відеострімінгу, а також отримати поради від комьюніті. І як сказав мені один із досвідчених QA: "Пиши про те що хотів би прочитати коли починав."
По моїм спостереженням, коли десь бачу якісь статті про тестування потокового відео, на думку одразу спадають статті типу цієї або цієї. Дуже добре коли система вже стабільна і працює відповідно очікуванням, тоді вже можна тестувати обєктивні метрики типу VMAF чи SSIM. Але що відбувається до цієї стадії? Ось про цей етап я спробую розповісти.
Дісклеймер:
Цей матеріал описує поверхневий огляд не вдаючись в деталі. Глибоке занурення будемо робити в наступних статтях.
Стратегія
Архітектура
Перш ніж перевіряти щось, важливо розуміти, які проблеми вирішує продукт, як він працює, з яких частин складається та як вони взаємодіють. Ця інформація допоможе приймати рішення щодо тестування.
Чим раніше почати планувати QA, тим краще. Де ще знайти краще використання підходу "shift left"?
Багато стрімінгових сервісів базуються на транскодер сервері або кластері таких серверів.
На цьому сервері є програма, яка включає в себе енкодери, декодери, мультиплексери, фільтри та інші модулі, які виконують певні завдання з перетворення сирого відео і аудіо в щось, що можна було б передати вам на ютуб.
Зазвичай процес передачі відеопотоку включає такі етапи:
1. Кодування (Encoding): Першим кроком є енкодування аудіо та відео даних у цифровий формат. Енкодер перетворює аналогові сигнали або сигнали з камер в цифровий формат, такий як H.264 або H.265 (також відомий як AVC і HEVC відповідно), який ефективно зберігає відео та аудіодані при відносно низькому обсязі даних.
2. **Упаковка у контейнер (Containerization)**: Після енкодування відео та аудіо дані упаковуються в контейнерний формат. MPEG-TS (MPEG Transport Stream) може бути одним з варіантів для контейнеру, особливо якщо ви маєте справу з традиційними телекомунікаційними технологіями. Інші популярні контейнери включають MP4, FLV, WebM, а також спеціалізовані контейнери для різних протоколів стрімінгу.
3. Адаптивна або однорівнева передача (Adaptive or Single Bitrate Streaming): Залежно від обраної стратегії передачі, ви можете вибрати адаптивну або однорівневу передачу. В адаптивній стратегії, відео дані енкодуються у різні роздільні здатності та бітрейти, і плеєр вибирає найбільш підходящий потік для конкретних умов мережі та відомостей про пристрій. В однорівневій передачі ви передаєте один конкретний потік.
4. Транспортування (Transport): Після енкодування та упаковки в контейнер відео дані готові до передачі по мережі. Залежно від обраного протоколу, можуть використовуватися різні механізми для транспортування. Протоколи, такі як RTMP, SRT, HLS, MPEG-DASH та WebRTC, надають специфічні механізми для передачі даних.
5. Мережева передача (Network Transmission): Відео дані передаються по мережі до серверів, які можуть бути розташовані в різних регіонах або на серверах доставки контенту (CDN - Content Delivery Network). Це забезпечує оптимальну швидкість та доступність стріму для глядачів з усього світу.
6. Декодування та Відтворення (Decoding and Playback): На стороні глядача відео дані декодуються і відтворюються. Плеєр розпізнає формат контейнера та вибирає відповідний декодер для розкодування відео та аудіо даних.
Готовий декодований потік ми спробуємо прийняти, перевірити його параметри.
Спочатку нам потрібно дізнатись чи можемо ми ізолювати цю програму для того щоб перевірити правильність її роботи без втручання будь чого зі сторони. Якщо це можливо - це дуже добре і потрібно обовʼязково цим скористатися, бо це зекономить багато часу для того щоб ізолювати проблеми, які зʼявляються. Якщо такої можливості немає, то використовуємо те що доступно, але краще щоб тестове середовище було копією виробничого або було виробничим.
Дізнайтеся на якій операціійній системі працює додаток, щоб підготувати інструменти для логування і збору артефактів які допоможуть швидше відтворювати і ізолювати проблеми.
Що перевіряти?
Плануючи що ви будете тестувати, потрібно дослідити вимоги і задати ключові питання про те які особливості має система і якої роботи від неї очікують.
Потокове відео передається з допомогою протоколів передачі. Це набір правил які визначають як відео і аудіо передаються мережею. Наприклад ті що частіше зустрічаються RTMP, SRT, HLS, MPEG-DASH, WebRTC.
Кожен з них має свої особливості і перед тестуванням, варто розуміти як вони працюють.
Ось тут добре описано основи їх роботи.
Будь яка передача починається із встановлення зʼєднання. Тому потрібно протестувати коректне встановлення з'єднань виходячи з реалізацій різних протоколів. Всі вони використовують зʼєднання типу клієнт-сервер. А webRTC може і client-client.
Обовʼязково потрібно перевірити і негативні сценарії коли зʼєднання не повинно бути встановлене та різні випадки повʼязанні з контролем доступу.
Для тестування потоку, нам потрібно його прийняти (як клієнт), декодувати і зберегти в контейнер, щоб подивись на дані які там лежать. Або якщо у вас є інструменти які можуть показати достовірні параметри сигналу на льоту - це дуже круто, варто ними скористатись.
Візьмемо як приклад SRT. Для перевірки встановлення зʼєднання можна використати Wireshark, щоб перехоплювати весь трафік і проаналізувати як встановлення зʼднань так і подальшу передачу. Ось в цьому відео гарно пояснено як це зробити.
Приймаємо цей стрім доступним вам декодером (як приклад ffmpeg або vlc) і направляємо вихід у файл (контейнер). Гарний гайд по контейнерам можна почитати тут.
Коли зʼєднання успішно встановлено, передача відео почалась, і вивід збережено до фалу, можемо перейти до перевірок параметрів транспортного потоку. А саме відео, аудіо, метаданих і всього що може помістити в собі потік.
Переглянемо ці параметри:
(на прикладі mpeg ts який прийнято по SRT)
Відео:
- PID: використовується в MPEG-2 транспортному потоці, який зазвичай використовується для передачі відео та аудіо в мережах та системах трансляції. Він використовується для ідентифікації різних типів даних, таких як відео, аудіо, субтитри тощо, і допомагає забезпечити їх коректну передачу та синхронізацію. Я зустрічався з системами які очікували відео та аудіо на конкретних номерах PIDs, тому як мінімум ви маєте перевірити які номери присвоюються вашим потокам. Перевірити кілька PIDs з різним вмістом.
- Кодек: перевіряємо лище ті що підтримуються вашим енкодером. Найпопулярніші зараз H.264, H.265, VP9, AV1, MPEG-4. Звертайте увагу на те що деякі кодеки потребуть багато ресурсів, тому, а ще гірше якщо мультипоточність не підтримується або не налаштована, і все навантаження ляже на одне ядро, і воно буде завантажене більше ніж на 70-80% то сервер може тротлити і потік може стати пошкоджений, а тести будуть необʼєктивними.
- Profile: Вони оголошуються за допомогою коду профілю (profile_idc), а іноді набору додаткових обмежень, що застосовуються в кодері. Код профілю та зазначені обмеження дозволяють дешифратору розпізнати вимоги до декодування цього конкретного бітового потоку.
- Level: це певний набір обмежень, які вказують на ступінь необхідної продуктивності декодера для профілю. Наприклад, рівень підтримки в профілі визначає максимальну роздільну здатність зображення, частоту кадрів і швидкість потоку, які може використовувати декодер. Декодер, який відповідає даному рівню, повинен мати можливість декодувати всі бітові потоки, закодовані для цього рівня, і всі нижчі рівні.
- chroma format: практика кодування зображень шляхом реалізації меншої роздільної здатності для хромаінформації, ніж для інформації Luma, використовуючи переваги нижчої гостроти зорової системи людини для відмінностей кольорів, ніж для яскравості.
- resolution: розміри фреймів у вашому потоці. Один з головних параметрів потоку. Якість вашого відео буде краще зі збільшенням resolution. Але чим він вище, тим більший бітрейт потрібен. І не забувайте споглядадти на рівень завантаження системи на 2,4,8K
1. SD (Standard Definition):
- 480p: Around 500 Kbps to 1.5 Mbps
2. HD (High Definition):
- 720p: Around 1.5 Mbps to 4 Mbps
- 1080p: Around 3 Mbps to 6 Mbps
3. Full HD:
- 1080p: Around 3 Mbps to 6 Mbps
4. 2K:
- 1440p: Around 6 Mbps to 10 Mbps
5. 4K:
- 2160p: Around 12 Mbps to 25 Mbps
6. 8K:
- 4320p: Can vary significantly, but generally upwards of 30 Mbps
- bitrate: це кількість даних, яка передається за одиницю часу при відтворенні або передачі відео. Він вимірюється в бітах на секунду (bps). Відтворіть отримані відео та оцініть якість кожного варіанта бітрейту. Для цього можна використовувати візуальну оцінку або об'єктивні метри якості, такі як PSNR (Peak Signal-to-Noise Ratio) чи SSIM (Structural Similarity Index).
Він може бути CBR (Constant Bit Rate): CBR означає, що бітрейт залишається постійним протягом всього відео. Незалежно від складності контенту, однаковий обсяг даних використовується на всіх етапах кодування.
VBR (Variable Bit Rate): VBR означає, що бітрейт варіюється в залежності від складності вмісту. Чим складніша сцена тим більше даних треба передати:
- framerate: частота кадрів з якою передається відеосигнал. Бувають 24, 25,30,50,60,120.
Перевірити частоту кадрів можна такими інструметами як ffprobe, mediainfo або VLC (не рекомендую бо іноді він обманює). Для перевірки варто використати якісні вхідні дані щоб можна було бачити номер кожного кадру і переглянувши кожен фрейм, бути впевненим що втрат кадрів немає.
Частота кадрів як і бітрейт може мати або **CFR (Constant Frame Rate)**: В цьому режимі кожен кадр кодується з однаковою швидкістю, і весь відеоролик використовує однакову кількість кадрів на секунду (fps). Або **VFR (Variable Frame Rate)**: В цьому режимі частота кадрів може варіюватися в залежності від складності контенту. Це може бути корисним для ситуацій, коли певні частини відео менш складні та можуть використовувати менше кадрів на секунду для економії обсягу даних, а більш складні сцени можуть мати більше кадрів для забезпечення кращої якості.
- GOP: Group of Pictures (Група кадрів): У відеокодуванні GOP - це послідовність відеокадрів, що включає в себе ключовий кадр (I-кадр) та один або декілька передбачуваних кадрів P та B, які використовують інформацію з попередніх або майбутніх кадрів для стиснення даних.
1. I-кадр (ключовий кадр): Це кадр, який не залежить від інших кадрів у GOP. Він містить повну інформацію про відеосцену і може використовуватися для декодування сам по собі. Оскільки I-кадр не залежить від інших кадрів, він зазвичай має більший розмір, ніж інші типи кадрів.
2. P-кадр (передбачуваний кадр): Ці кадри передбачаються на основі I-кадрів та інших P-кадрів в попередніх GOP. Вони містять тільки зміни відносно попередніх кадрів, що дозволяє зберігати їх з меншим об'ємом даних.
3. B-кадр (кадр між I та P): Ці кадри містять інформацію, яка базується на двох інших кадрах - I та P. Вони можуть ще більше зменшити об'єм даних.
Як правило B frame не використовують в відеотрансляції з низькою затримкою з наступних причин.
1. Затримка обчислень: Відеокодеки вимагають більше обчислень для декодування B-кадрів, оскільки їх потрібно побудувати на основі інших кадрів. Це може призвести до збільшення загальної затримки відеостріму.
2. Затримка передачі: Використання B-кадрів може збільшити обсяг даних, які потрібно передати для відтворення відео. Це може вплинути на пропускну здатність мережі та збільшити затримку при передачі даних.
3. Якість інтерполяції: Використання B-кадрів вимагає інтерполяції між референтними кадрами (I або P) для побудови B-кадрів. Це може призвести до певного рівня додаткової артефактності або зниження якості відтворення.
4. Можливий розрив зв'язку: У випадку втрати B-кадра може виникнути проблема з декодуванням наступних кадрів, які можуть бути залежні від нього. Це може призвести до погіршення якості відтворення або затримок у відеострімі.
Тестуйте чи вірно ваш енкожер задає структуру GOP та правильно decoder розуміє та декодує цю структуру. Підготуйте різні варіанти тестових даних, з різним розміром та наповненням GOP.
Перевірити структуру GOP в потоці можна спеціальними інструментами.
- key frame interval: показує відстань між ключовими I кадрами. Задається або в кількості кадрів або в секундах. Можна підготувати різні тестові дані. Починаючи від того що відео має абсолютно всі кадри ключові і до 10 секунд між ключовими кадрами. Дивимось як поведе себе енкодер який кодує такі відстані та декодер який буде це декодовувати. Оцінюємо якість зображення на різних інтервалах ключових кадрів.
- color space: Колірний простір описує, як масив значень пікселів повинен відображатися на екрані. Він надає таку інформацію, як значення пікселів зберігаються у файлі, а також діапазон та значення цих значень. Перевіряємо чи коректно декодер розуміє закодоване відео при різних значеннях, наприклад:
- [BT.601](https://en.wikipedia.org/wiki/Rec._601) ("Стандартна чіткість" або SD)
- [BT.709](https://en.wikipedia.org/wiki/Rec._709) ("високої чіткості" або HD)
- [BT.2020](https://en.wikipedia.org/wiki/Rec._2020) ("Ultra-High-Definition" або UHD)
- bit depth: Бітова глибина в відео відноситься до кількості бітів, використаних для представлення інформації про кольори кожного пікселя на зображенні або кадрі. Зазвичай в відео використовуються такі бітові глибини, як 8 біт, 10 біт та 12 біт. Перевіряємо кожне значення.
- Scan type: Progressive та interlaced - це два різних підходи до відображення зображення на екрані, зокрема у відео.
1. Progressive (прогресивне сканування): У цьому режимі кожний кадр відео відображається повністю, і всі рядки зображення обробляються одразу. Всі пікселі на екрані оновлюються одразу ж, що робить зображення більш чітким та плавним. Відео у форматі 720p, 1080p, 4K тощо використовують progressive сканування.
2. Interlaced (черезрядкове сканування): У цьому режимі кадр поділяється на дві половини - парні та непарні рядки. Спочатку відображаються всі парні рядки, а потім - непарні. Це було винайдено для зменшення кількості інформації, яку потрібно передати через обмежені канали зв'язку.
- aspect ratio: співвідношення сторін відеофрейму. Ваша система має коректно розуміти кожен тип і додавати чорні полоси коли це необхідно або ж передавати лише корисне навантаження згідно вашого співвідношення сторін. Перевіряємо популярні значення і ті які задані у вимогах.
- A/V syncronization: синхронізаці аудіо та відео. Відома як lipsync. Готуємо відповідний контент в якому можна легко зрозуміти зсув звуку та зображення.
- NTP sync: якщо ваш сервіс підтримує синхронізацію потоків по таймкоду, то потрібно перевірити що це працює коректно. NTP працює над синхронізацією ваших потоків через відеокодери та відеодекодери. NTP - це абревіатура від протоколу мережевого часу, інтернет-стандарту, який функціонує шляхом синхронізації ваших серверів і пристроїв з всесвітнім координованим часом (UTC). NTP працює шляхом синхронізації ваших пристроїв (в даному випадку кодерів і декодерів) з NTP-сервером, який, у свою чергу, синхронізується з годинником «grandmaster» (часто одним з атомних годинників, або GPS-годинником). NTP точний з точністю до десятків мілісекунд через Інтернет, а за ідеальних обставин може бути точним до субмілісекундних рівнів. І ця точність - від годинника гросмейстера до вашого пристрою. Таким чином, ваші пристрої (які всі повинні бути підключені до одного NTP-сервера) будуть дуже близькі один до одного з точки зору точності часу.
- PTS/DTS: PTS (Presentation Time Stamp) вказує на час, коли певний кадр або аудіофрагмент повинен бути показаний на екрані або відтворений на аудіо виході. DTS (Decoding Time Stamp) вказує на час, коли даний кадр або аудіофрагмент повинен бути декодований. Тут добре описано як перевірити правильність цих міток в відеопотоці.
- Latency: затримка між це затримка, яка виникає між моментом створення відеосигналу на стороні джерела та моментом відтворення цього відеосигналу на стороні кінцевого користувача.
Як і в будь-яких інших методологіях вимірювання, існують більш і менш точні способи зробити це. Звичайний метод, який багато хто використовує, - це поставити високоточний цифровий секундомір перед камерою і зробити фотографію під час відтворення секундоміра уже декодованого потоку на екрані. Але якщо для вас цього недостатньо, то є наукові роботи в яких можна поміряти точніше.\
Аудіо:
- PID: перевірте що піди мають очікувані ідентифікаційні номери і що вони коректно декодуються і відтворюються.
- Codec: як і у відео, у аудіо є свої кодеки AAC, MP3, AC3, DTS, а також нестиснений звук PCM, він використовується для точного відтворення аудіосигналу, не застосовуючи стиснення даних.
- Bitrate: 96, 128, 192,256 перевіряємо що енкодер правильно кодує значення і звук проходить без спотворень
- Channel layout: перевіряємо різні схеми каналів звуку, такі як mono, stereo (2.0), 2.1, 5.1, 7.1, 7.1.2, 9.1. Підготуйте багато комбінаці різних тестови даних, для того щоб перевіряти чи правильно транскодер правильно їх обробляє.
- Sample rate: (частота дискретизації) - це параметр, який визначає, скільки разів за секунду збираються дані з аналогового звуку для перетворення їх в цифровий формат. Це є однією з ключових характеристик цифрового аудіо. Sample rate вимірюється в герцах (Гц) і вказує на кількість аудіо семплів, які записуються за одну секунду. Cтандартним sample rate є 44100 Гц або 48000 Гц.
- Bit depth: параметр, який визначає точність зберігання або передачі звукової інформації у цифровому форматі. Вона вимірюється в бітах і показує, скільки різних значень може бути представлено для кожного аудіо семпла. Чим вища бітова глибина, тим більше можливих значень може бути записано для кожного звукового семпла, що спричиняє більшу точність і деталізацію звуку. Перевіряємо поширені значення: 8,16, 24, 32 біт.
Використовуйте тестові дані різного вмісту: людський голос, музика, шум, різні рівні аудіо тону. Перевіряйте також пікові та кліпуючі (>0dB) значення.
Метадата:
Далі варто перевірити метадані транспортного потоку, а для цього потрібно розуміти що це:
1. Program Association Table (PAT): Ця таблиця надає інформацію про доступні програми у потоці MPEG-TS. Вона включає ідентифікатор таблиці відображення програми (PMT) для кожної програми, що дозволяє приймачам знаходити відповідну PMT для додаткової інформації.
2. Program Map Table (PMT): PMT надає деталі про компоненти конкретної програми, такі як аудіопотоки, відеопотоки, субтитри та інші дані. Кожен компонент ідентифікується ідентифікатором пакета (PID), а PMT допомагає приймачам розуміти, як обробляти та декодувати різні компоненти.
3. Service Information (SI): Метадані SI містять інформацію про послуги, такі як назви програм, описи та інформацію про постачальників послуг. Ці метадані допомагають користувачам визначити вміст, який вони хочуть переглядати.
4. Conditional Access Table (CAT): Ця таблиця містить інформацію, пов'язану з системами умовного доступу, які керують шифруванням та розшифруванням вмісту для авторизованих глядачів.
5. Event Information Table (EIT): Метадані EIT надають деталі про заплановані події, зокрема час початку, тривалість та назви програм. Вони особливо корисні для електронних програмних довідників (EPG), які допомагають користувачам навігувати серед доступного вмісту.
6. Network Information Table (NIT): Метадані NIT містять інформацію про саму мережу, таку як параметри налаштування, частота та деталі модуляції. Це особливо важливо для приймачів, щоб правильно настроїтися на бажані канали.
7. Time and Date Table (TDT): Метадані TDT передають поточну інформацію про час та дату у потоці MPEG-TS. Вони допомагають забезпечити синхронізацію між передавачем та приймачем.
8. Descriptors: Дескриптори — це невеликі частини метаданих, які надають додаткову інформацію про вміст або компоненти у потоці MPEG-TS. Вони можуть містити деталі, такі як аудіо- та відеоформати кодування, інформацію про мову та інше.
Деякі великі стрімімнг платформи, що будуть приймати ваші стріми (наприклад youtube), обовʼязково скажуть вам що якщо хочете мати сертифікацію від нас, то будь ласка в кожен ваш потік вкладіть правильні метадані (наприклад з назвою компанії або енкодера), щоб ми потім легко могли визначити хто це якщо виникнуть якісь проблеми.
Тому дуже важливо перевірити що туди вкладається.
Статистика потоку в реальному часі
Оскільки ми взяли потоковий протокол SRT як приклад, необхідно зазначити, що SRT надає потужний набір статистичних даних про сокет. Ці дані можна використовувати для спостереження за станом сокета і відстеження несправної поведінки. Статистика обчислюється незалежно на кожній стороні (одержувач і відправник) і не обмінюється між одноранговими партнерами, якщо тільки це не вказано явно. Для тестування наші розробники створили плеєр, який може відображати цю статистику в режимі реального часу, і ви можете спостерігати значення багатьох параметрів. Незабаром ми плануємо зробити його відкритим. Але про тестування SRT поговоримо іншим разом.
Test Environment:
- Internet connection: Перед тестуванням стрімінгу, переконайтеся що у вас стабільний інтернет із високою пропускною здатністю. Краще використовувати Ethernet зʼєднання з 1 Gbps. І тільки для тестування різних варіантів пропускної здатності використовуйте wifi (щоб змоделювати реального звичайного юзера) або інструменти які допомагають гнучко налаштувати вашу пропускну здатність, latency, delay, lost packets і так далі. Для перевірки вашої мережі можна використати інструмент від Netflix https://fast.com, або speedtest чи тулу твіча https://r1ch.net/projects/twitchtest
Test Data:
Підготуйте багато тестових даних. Краще всього взяти якісно відзняте відео (нестиснуте) і самому закодувати його в потрібні кодеки, контейнери і тд. Тут потрібно вибрати золоту середину всіх параметрів які описано вище, в залежності від того які з них частіше використовуються. Добре коли є записані тестові відео, а також живі, як от стрім з вашої камери чи hardware енкодера. Вибирайте як складний тестовий контент так і простий, це допоможе змоделювати різні тестові умови.
Ось деякі лінки на відкриті тестові відео:
streams:
- https://ottverse.com/free-hls-m3u8-test-urls/
- https://github.com/bengarney/list-of-streams
files:
- https://mango.blender.org/download/
- http://download.tsi.telecom-paristech.fr/gpac/dataset/dash/uhd/
- https://medialab.sjtu.edu.cn/tag/dataset/
- https://ultravideo.fi/#testsequences
- https://www.murideo.com/test-pattern-library.html
Види тестування:
Юніт-тести
На першому етапі моліться Богу, щоб розробник написав кілька юніт-тестів і перевірив найдрібніші частини системи.
Component testing
Це перший рівень тестування, де окремі компоненти вашої системи перевіряються на правильну роботу. Саме тут було б круто щоб ви окремо перевірили як працюють енкодер, декодер, мультиплексори, фільтри і тд. Ниряти тут кудись глибше (якщо ви не лютий сі плюс плюсник - не бачу сенсу), тому просто моліться Богу що у дева в цих компонентах є юніт тести.
Integration testing
- Component Integration Testing: Тут можна почати проектувати кейси де ваші модулі могли б уже взаємодіяти один з одним і моделювати кейси де хтось і них не виконає свої задачі так як очікується.
- System Integration Testing: На цьому рівні ви перевіряєте інтеграцію системи в цілому. Це включає перевірку взаємодії між різними компонентами, серверами, клієнтами та іншими частинами системи.
- Hardware Software Integration Testing: Цей вид тестування орієнтований на перевірку взаємодії між апаратними та програмними компонентами системи. Наприклад Використовувати
- Software Integration Testing: Тут ви зосереджуєтеся на інтеграції програмних компонентів, таких як програми, бібліотеки, сервіси та інші програмні модулі, що використовуються для стрімінгу.
System Testing:
На цьому етапі ви вже маєте цілу систему, і ви перевіряєте, чи відповідає вона специфікаціям, чи працює коректно та чи задовольняє вимогам користувачів.
ПІсля цього можна перейти до:
- Stability
- Load
- Stress
- Recovery
- Scalabillity
- Volume
- Reliability
- Failover and Recovery
Але про ці види поговоримо пізніше, бо я так ніколи не закінчу цю статтю.
# Інструменти:
Обовязково підготуйте інстурменти які будете використовувати для конвертації, передачі, прийому та аналізу потоків. Серед них є open source або trial якого буде достатньо. Ось ті що використовую я:
- ffmpeg
- ffprobe
- mediainfo
- ffplay
- ffmetrics
- ffbitrate
- Elecard:
- Stream Eye
- Quality Estimator
- Stream Analyzer
- Quality Gates
- HandBrake
- VidCOder
- VQProbe
- NetBalancer
- NetLimiter
- OBS
- vMix
- VLC
- SRTSTressTools
- https://dvbsnoop.sourceforge.net/
- https://github.com/tsduck/tsduck
- https://www.digitalekabeltelevisie.nl/dvb_inspector/
Репортінг:
Всі баги що ви знаходите, важливо максимально підкріпити степами, логами, тестовими даними, скріншотами та відео. Тоді ваші деви будуть щасливі а вас не будуть спамити проханнями допомогти.
Висновки:
1. Щоб доставити до користувача продукт високої якості, потрібно визначитись що саме ви робите і виходячи з цього створювати грамотну стратегію тестування яка зможе попередити і запобігти більшості проблем.
2. Починати тестування ще до реалізації функціоналу (shift-left), бо потрібно багато ресурсів (особливо часу) на тестування.
3. Вивчити і розуміти як працює ваша система, з яких компонентів складається і як вони взаємодіють.
4. Правильно розставити пріоритети в залежності від використання вашого продукту.
5. Бути уважним спостерігачем.
