Що таке HTTP Live Streaming та як його тестувати

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Всім привіт! Я Сергій Романов, SDET Manager у Brightgrove, також я співпрацюю з Pluto TV — однією з провідних безкоштовних відеострімінгових платформ з мільйонами активних глядачів у США, Канаді, багатьох країнах Європи та Латинської Америки.

Оскільки я вже кілька років спеціалізуюсь на тестуванні відеострімінгових сервісів та маю досвід роботи з різними стрімінговими протоколами, сьогодні хотів би розповісти про найпопулярніший — HTTP Live Streaming (HLS).

Огляд HLS

HLS — це протокол потокової передачі даних з адаптивним бітрейтом на основі HTTP, розроблений Apple Inc. та представлений на WWDC 2009 разом з iOS 3.0. Компанія Apple регулярно займається модернізацією цього протоколу, тому тут можна побачити, що було додано у 2024 році.

Хоча HLS спочатку був розроблений для Apple-пристроїв, сьогодні його підтримують і багато інших платформ, починаючи від Android і закінчуючи приставками та Smart TV різних брендів. Станом на 2024 рік щорічне дослідження відеоіндустрії незмінно показує, що це найпопулярніший формат потокової передачі.

HLS використовує просту архітектуру, яка не вимагає спеціального обладнання. Процес починається з кодування відео за допомогою кодеків H.264 або H.265. Ці кодеки забезпечують ефективну компресію, дозволяючи зменшити розмір відео без значних втрат у якості. Потім закодоване відео сегментується на короткі сегменти, зазвичай від 5 до 10 секунд, хоча ця довжина може бути змінена для оптимізації відповідно до типу контенту чи умов мережі.

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

Master Playlist та його роль

HLS використовує два типи плейлистів: Master Playlist і Media Playlist. Master Playlist є своєрідним «контролюючим списком», який містить посилання на один або кілька Media Playlist-ів і надає інформацію про різні варіанти потоків, такі як якість відео, бітрейт та кодеки. Це дозволяє програвачам динамічно перемикатися між потоками залежно від умов мережі. На наступному зображенні ви можете бачити співвідношення між Master Playlist та Media Playlist.

Так виглядає зразок Master Playlist:

#EXTM3U 
#EXT-X-VERSION:3 
#EXT-X-STREAM-INF:BANDWIDTH=1280000,RESOLUTION=640x360,CODECS="avc1.42e01e,mp4a.40.2" 
http://example.com/360p.m3u8 
#EXT-X-STREAM-INF:BANDWIDTH=2560000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2" 
http://example.com/720p.m3u8 
#EXT-X-STREAM-INF:BANDWIDTH=5120000,RESOLUTION=1920x1080,CODECS="avc1.4d401f,mp4a.40.2" 
http://example.com/1080p.m3u8

Давайте розберемо директиви Master Playlist:

• #EXTM3U — Вказує, що Master Playlist базується на розширеному форматі M3U
• #EXT-X-VERSION:3 — Версія протоколу HLS, яку підтримує цей плейліст. Чим вища версія, тим більше розширених можливостей HLS можна використовувати
• #EXT-X-STREAM-INF — містить атрибути потоку:
  • BANDWIDTH — десяткове ціле число в бітах в секунду, що вказує пікову швидкість передачі (бітрейт) для сегментів конкретного варіанту потоку.
  • RESOLUTION — це значення у форматі «ширина × висота», що вказує на оптимальну роздільну здатність у пікселях для відображення всього відео в межах обраного варіанту потоку.
  • CODECS — використовувані кодеки для відео та аудіо.
• Після цієї директиви вказано URL Media Playlist, який відповідає конкретному варіанту потоку.

Master Playlist дозволяє реалізувати адаптивну потокову передачу, де клієнт автоматично вибирає найкращий варіант потоку залежно від умов мережі та можливостей пристрою.

Media Playlist та його роль

Media Playlist детально описує сегменти одного потоку, які відтворюються послідовно. Основна функція Media Playlist — забезпечити клієнта інформацією про кожен сегмент відео, включаючи його тривалість, URL і можливі метадані.

Давайте розглянемо, як виглядає зразок Media Playlist

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:10.000,
http://example.com/segment1.ts
#EXTINF:10.000,
http://example.com/segment2.ts
…
#EXT-X-ENDLIST

Media Playlist включає директиви, що являють собою набір спеціальних інструкцій. Вони надають інформацію про загальний формат плейлиста, структуру потоку, характеристики сегментів та інші параметри, необхідні для коректної обробки та відтворення відеоконтенту. Давайте розберемо деякі з них:

• #EXTM3U та #EXT-X-VERSION:3 ми розглядали раніше
• #EXT-X-MEDIA-SEQUENCE:0 — вказує на порядковий номер медіафайлу першого медіасегмента, який з’являється в Media Playlist.
• #EXT-X-TARGETDURATION:10 — це десяткове ціле число, що вказує максимальну тривалість медіасегменту в секундах.
• #EXT-X-PLAYLIST-TYPE:VOD — вказує режим роботи плейліста та регулює можливість внесення змін до нього:
  • VOD (Video on Demand): Playlist повинен бути статичним і не може змінюватися після створення.
  • EVENT: Playlist може змінюватись і нові сегменти можуть бути додані до кінця списку
• #EXTINF:10.000, — тривалість медіа сегмента, за якою слідує URL-адреса сегмента.
• #EXT-X-ENDLIST — вказує, що в Media Playlist більше не додаватимуться нові сегменти. Він може зустрічатися в будь-якому місці плейлиста, але найчастіше використовується в плейлистах для VOD (Video on Demand), де контент є статичним і не змінюється.

Загалом цих директив дуже багато і їх всі можна знайти в офіційній специфікації від Apple.

Компоненти систем на базі протоколу HLS

Система на базі протоколу HLS зазвичай включає три ключові компоненти:

• Packager: це програмне забезпечення розбиває відео на сегменти та компілює Master Playlist та Media Playlist, деталізуючи порядок і особливості кожного медіасегмента.
• Server: виконує роль сховища сегментованих медіафайлів і відповідних плейлистів, та надає їх за запитом. Він використовує стандартну технологію вебсервера для розповсюдження HLS контенту.
• Player або Client: це пристрій або додаток, який завантажує та відтворює відео. Він починає відтворення з отримання плейлистів, потім послідовно завантажує та відтворює медіасегменти.

На цьому зображенні можна побачити взаємодію всіх частин системи.

Потокову передачу можна розділити на кілька типів, основні з яких — це пряма трансляція (Live Streaming) та відео на замовлення (Video on Demand або VOD).

Пряма трансляція (Live Streaming).

У разі прямої трансляції, клієнт запитує m3u8-плейлист, який містить метадані та URL-адреси сегментів медіа. Медіаплеєр читає m3u8-плейлист і починає завантажувати та відтворювати медіасегменти у зазначеному у плейлисті порядку. При прямій трансляції файл .m3u8 постійно оновлюється з новими медіасегментами у міру їхньої доступності. Медіаплеєр періодично потребує оновленого файлу .m3u8, аби гарантувати, що він має останні сегменти. Цей процес дозволяє у реальному часі транслювати події.

Відео на замовлення (VOD)ю

Давайте перейдемо до тестування HLS.

Тестування серверної частини

Тестування серверної частини починається з валідації m3u8-плейлистів. Валідація плейлистів у HLS — це важливий крок для забезпечення правильного відтворення відеопотоків. Як згадувалося раніше, плейлисти (.m3u8) в HLS поділяються на Master Playlist та Media Playlist, кожен з яких виконує свою роль у доставці потокового контенту. Перевірка цих файлів допомагає уникнути помилок відтворення та збою роботи системи під час потокової передачі відео.

Щоб перевірити коректність Master Playlist, потрібно виконати кілька кроків, починаючи з аналізу його структури та вмісту. Ось основні аспекти, на яких можна сконцентрувати увагу:

• Формат та синтаксис: Файл повинен починатися з директиви #EXTM3U.
• Коректні посилання на медіаплейлісти: Переконайтеся, що всі посилання на медіаплейлісти валідні та вказують на наявні ресурси.
• Метадані потоків: Перевірте, чи директиви #EXT-X-STREAM-INF містять правильні атрибути, такі як BANDWIDTH, RESOLUTION, CODECS.
• Наявність всіх варіантів стрімів: У майстер-плейлисті мають бути вказані всі необхідні варіанти для різних варіантів роздільної здатності та бітрейтів.

Щоб забезпечити правильність роботи Media Playlist, варто звернути увагу на його основні елементи, які впливають на відтворення відео:

• Директиви синтаксису: плейлист повинен починатися з директиви #EXTM3U, а потім слідувати директиви сегментів, такі як #EXTINF для вказівки тривалості сегментів та посилання на сегменти.
• Коректність посилань на сегменти: переконайтеся, що всі сегменти (посилання на файли з розширенням .ts) доступні та можуть бути завантажені.
• Послідовність сегментів: директиви #EXT-X-MEDIA-SEQUENCE та #EXT-X-ENDLIST повинні коректно керувати порядком сегментів та завершенням плейлиста.
• Правильне визначення тривалості сегментів: директиви #EXTINF повинні містити правильні значення часу, щоб клієнт правильно розраховував часові проміжки відтворення.

Також додатково потрібно звернути увагу на:

• Адаптивність бітрейтів: перевірте, що плейлисти включають потоки з різними бітрейтами та дозволами для підтримки адаптивного стрімінгу.
• Підтримку DRM: якщо використовується DRM (Управління цифровими правами), переконайтеся, що плейлисти містять необхідні директиви для шифрування та захисту вмісту.
• Прямі трансляції: для прямих трансляцій важливо перевіряти правильність оновлення медіаплейлістів, щоб вони включали нові медіасегменти в режимі реального часу.
• Директиви для ідентифікації типу контенту, безпосередньо реклами.

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

Наприклад, для написання тестів на Java я прихильник проекту m3u8-parser. Він дозволяє парсити m3u8-плейлисти в Java об’єкти згідно з RFC 8216 HTTP Live Streaming. Автор цього проекту стверджує, що «m3u8-parser does not try to validate playlists. You are responsible for creating valid playlists.», тому написання перевірок має лягати на команду тестування.

Ось приклад того, як можна розпарсити Master Playlist за допомогою m3u8-parser і виконати для нього перевірки:

public class HlsStreamTest {
 private static final String STREAM_PATH = "https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s-fmp4/";
 private static final String MASTER_PLAYLIST = "f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8";
 private final MasterPlaylistParser masterPlaylistParser = new MasterPlaylistParser();
 private final MediaPlaylistParser mediaPlaylistParser = new MediaPlaylistParser();
 @Test
 public void testSimpleMasterPlaylistParsing() throws IOException {
   // Fetch and parse the Master Playlist
   String playlistContent = fetchPlaylistContent(STREAM_PATH + MASTER_PLAYLIST);
   MasterPlaylist masterPlaylist = masterPlaylistParser.readPlaylist(playlistContent);
   // Validate the MasterPlaylist object is not null
   assertNotNull(masterPlaylist, "MasterPlaylist should not be null");
   // Validate version
   assertTrue(masterPlaylist.version().isPresent(), "Version should be present and is critical to the playlist's metadata.");
   assertEquals(6, masterPlaylist.version().get().intValue(), "Expected version is 6");
   // Additional checks that could be implemented:
   // 1. Validate the number of variants in the playlist:
   // 2. Validate each variant's attributes such as URI, bandwidth, resolution, and codecs:
   // 3. Validate alternative renditions, such as audio tracks:
   // 4. Check for custom tags or comments, if needed.
   // Other validations
 }
}

А це приклад того, як можна розпарсити Media Playlist за допомогою m3u8-parser і виконати необхідні перевірки:

@Test
public void testSimpleMediaPlaylistParsing() throws IOException {
 // Fetch and parse the Master Playlist
 String playlistContent = fetchPlaylistContent(STREAM_PATH + MASTER_PLAYLIST);
 MasterPlaylist masterPlaylist = masterPlaylistParser.readPlaylist(playlistContent);
 //Fetch and parse the Media Playlist
 String mediaPlaylistContent = fetchPlaylistContent(STREAM_PATH + masterPlaylist.variants().get(0).uri());
 MediaPlaylist mediaPlaylist = mediaPlaylistParser.readPlaylist(mediaPlaylistContent);
 assertEquals(mediaPlaylist.targetDuration(), 4, "Target duration should be 4");
 // 1. Validate that the media sequence starts at the expected value
 // 2. Validate that the playlist type is VOD or EVENT
 // 3. Validate independent segments flag
 // 4. Validate that all media segments have a positive duration
 // 5. Validate that all segment URIs are not null
 // 6. Validate the total number of segments matches an expected count
 // 7. Validate that there are no discontinuities unless expected
 // 8. Validate the duration of the final segment
 // 9. Validate that partial segments (if any) are processed correctly
 // Other validations
}

Так само можна написати тести за допомогою Python. Для Python також існує безліч бібліотек для роботи з плейлистами і одним з найпопулярніших прикладів є бібліотека m3u8. Вона дозволяє завантажувати, парсити та перевіряти плейлисти, забезпечуючи простий інтерфейс для роботи з різними атрибутами.

Ось приклад, як може виглядати тест, написаний на Python за допомогою парсера m3u8:

class TestMasterPlaylist(unittest.TestCase):
   MASTER_PLAYLIST_URL = "https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s-fmp4/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8"
   @classmethod
   def setUpClass(cls):
       """
       Fetch and parse the playlist content once for all tests.
       """
       response = requests.get(cls.MASTER_PLAYLIST_URL, timeout=5)
       response.raise_for_status()
       cls.playlist_content = response.text
   def test_general_metadata(self):
       """
       Validate general metadata of the playlist.
       """
       playlist = m3u8.loads(self.playlist_content)
       self.assertEqual(playlist.version, 6, "Playlist version should be 6.")
       self.assertTrue(hasattr(playlist, 'media'), "Playlist should contain media attributes.")
   def test_audio_tracks(self):
       """
       Validate audio tracks in the playlist.
       """
       playlist = m3u8.loads(self.playlist_content)
       self.assertEqual(len(playlist.media), 1, "Playlist should have one audio track.")
       audio = playlist.media[0]
       self.assertEqual(audio.type, "AUDIO", "Media type should be AUDIO.")
# Other validations

Загалом до перевірки серверної частини так само можна віднести перевірку роботи пакувальника (packager) та коректність самих медіафайлів, особливо коли транскодування контенту теж належить до обов’язків команди тестувальників.

Тестування медіафайлів, таких як .ts (Transport Stream) та .vtt (WebVTT), часто виконується такими інструментами як FFprobe або MediaInfo. Ці інструменти дозволяють виявити помилки у файлах, які можуть вплинути на якість та стабільність потокової передачі.

Нижче я навів ключові аспекти, які можна перевірити та проаналізувати за допомогою FFprobe:

1. Інформація про потоки

• Відеопотоки: тип кодека (наприклад, H.264), роздільна здатність, частота кадрів, формат пікселів та співвідношення сторін.
• Аудіопотоки: тип кодека (наприклад, AAC), частота дискретизації, кількість каналів та метадані мови.
• Потоки субтитрів: формат та мова, якщо вони є.

Щоб отримати інформацію про потоки, можна виконати команду:

ffprobe -v error -show_streams input.ts

2. Загальна цілісність медіафайлу .ts:

• Загальна тривалість медіасегмента, бітрейт та розмір.
• Метадані на рівні контейнера, такі як кодувальник та час створення.

Команда для отримання інформації про цілісність медіафайлу:

ffprobe -v error -show_format input.ts

3. Аналіз на рівні кадрів

• Тимчасові мітки (PTS) та тимчасові мітки декодування (DTS).
• Типи кадрів (I-frames, P-frames, B-frames) та їх послідовність.

Команда для отримання детальної інформації про кадри:

ffprobe -v error -select_streams v:0 -show_frames input.ts

4. Аналіз на рівні пакетів:

• Розміри пакетів та тимчасові мітки.
• Ефективність пакетування потоків.

Команда для перевірки пакетів:

ffprobe -v error -show_packets input.ts

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

В автоматизованих тестах FFprobe можна використовувати двома способами: написати власний екзекутор для виклику консольної утиліти та парсингу її виведення, або скористатися готовими вреперами, що надають зручний інтерфейс для роботи з FFprobe.

Ось приклад врапера на ім’я ffmpeg-cli-wrapper, який можна використовувати при написанні тестів на Java. Він дозволяє робити все те ж саме, що і консольний додаток.

Ось приклад його використання:

FFprobe ffprobe = new FFprobe("/path/to/ffprobe");
FFmpegProbeResult probeResult = ffprobe.probe("input.mp4");
FFmpegFormat format = probeResult.getFormat();
System.out.format("%nFile: '%s' ; Format: '%s' ; Duration: %.3fs", 
 format.filename,
 format.format_long_name,
 format.duration
);
FFmpegStream stream = probeResult.getStreams().get(0);
System.out.format("%nCodec: '%s' ; Width: %dpx ; Height: %dpx",
 stream.codec_long_name,
 stream.width,
 stream.height
);

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

Аналіз Playlists та медіафалів за рахунок інтеграції з ChatGPT

Ще на початку минулого року, як тільки я відвідав одну з конференцій з AI, мені спала на думку ідея відправляти маніфести на перевірку в ChatGPT. Я створив проект під назвою hls-ai-analyzer, який нещодавно вивантажив у GitHub. За допомогою цього проекту я хочу показати як можна інтегруватися з ChatGPT API і надсилати йому m3u8-плейлисти та результат виконання FFprobe для медіафайлів щоб перевірити їх на аномалії.

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

«You are a video streaming analysis program for HLS and DASH. You have to analyze streaming files and find all sorts of anomalies. Use standard RFC-8216 for validation. If you do not find anomalies, then I expect a response: {«status»: «OK», «message»: «Manifest is correct»}. If you found anomalies, then I expect a response: {«status»: «FAIL», «message»: «[Add here information about what is wrong in a stream in 200 symbols]»

Для мене було важливо зробити, щоб ChatGPT повертав відповідь у форматі JSON, аби мені було зручно його мапити в об’єкт в Java, тому в інструкції я вказав явно, яку відповідь я очікую. Далі подібні аналізатори можна підлаштувати під будь-які потреби та завдання. Наприклад, його можна спробувати направити на LIVE стрім і модифікувати код, який завантажуватиме m3u8-плейлисти кожні 5 секунд, при цьому завантажуючи медіафайли і відправляючи всі ці дані в ChatGPT API для перевірки на аномалії. Такий підхід може дозволити аналізувати стріми в реальному часі, що може допомогти відловлювати складні дефекти або аномалії.

Але навіть маючи автоматизовані тести або інтеграцію з AI для перевірки стріму, я б так само рекомендував перевіряти відтворення за допомогою різних плеєрів, про що ми поговоримо далі.

Тестування відтворення

Тестування відтворення включає перевірку відтворення HLS стрімів на різних пристроях та браузерах. Основна мета, це забезпечити стабільність відтворення, адаптивність до змін умов мережі та коректне відображення контенту відповідно до специфікацій HLS.

Давайте розглянемо основні аспекти тестування програвання HLS стріму:

• Відтворення на різних пристроях та платформах
  • Тестування на веб-браузерах (Chrome, Firefox, Safari, Edge).
  • Тестування на мобільних пристроях (iOS, Android).
  • Тестування на Smart TV, ігрових приставках тощо.
• ABR (Adaptive Bitrate Streaming)
  • Перевірка, як відеоплеєр адаптує якість потоку при зміні швидкості інтернет-з’єднання.
  • Вимірювання часу перемикання між бітрейтами та його впливу на користувацький досвід.
• Час запуску та завантаження буфера
  • Вимірювання часу відображення першого кадру під час запуску відео (TTFF).
  • Перевірка буферизації при різних умовах нетворку та навантаженні.
  • Підрахунок відставання від оригінального стріму у випадку з Live Streaming.
• Стабільність відтворення та стійкість до помилок
  • Відновлення відтворення після втрати з’єднання або тимчасової деградації мережі.
  • Перевірка поведінки під час невдалого завантаження сегмента або помилок при HTTP-запиті.
• Робота з субтитрами та альтернативними аудіодоріжками
  • Перевірка коректного відображення WebVTT (.vtt) субтитрів.
  • Аналіз якості розміщення субтитрів на екрані.
  • Перевірка перемикання між різними мовами/аудіотреками.
• Тестування DRM (Digital Rights Management)
  • Перевірка процесу отримання та обробки ліцензійних ключів, включаючи перевірку часу відгуку DRM-серверів.
  • Перевірка обмежень відтворення (наприклад, заборона скріншотів або запису екрана) відповідно до політик безпеки контенту.
  • Аналіз поведінки програвача у випадках помилок DRM, таких як відсутність ліцензії або закінчення терміну її дії.

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

1. hls.js — це безкоштовний онлайн інструмент для тестування HLS-відтворення в браузері за допомогою hls.js, широко відомої JavaScript-бібліотеки для роботи з HLS. За допомогою нього можна аналізувати адаптивне перемикання бітрейтів, перевіряти стабільність відтворення та переглядати докладні логи буферизації та помилок. Наприклад, при відтворенні HLS стрімів, можна відстежувати заповнення буфера у вкладці Timeline.

Якщо перейти на наступну вкладку «Quality-levels», то можна вибрати бітрейт, в якому ви хочете програвати ваш HLS стрім.

Вкладка Audio-tracks дозволяє отримати інформацію про всі доступні аудіодоріжки для вашого HLS-стріму. А наступна вкладка «Real-time metrics» є найінформативнішою і дозволяє аналізувати метрики про бітрейти, буфер, відео або аудіо івенти і так далі.

Остання вкладка «Buffer & Statistics» більше відображається статистика та містить таку корисну інформацію як: Dropped frames, Corrupted frames, TTFB Estimate, Bandwidth Estimate та іншу загальну статистику.

2. Akamai Player and Stream Validator — це інструмент для тестування та аналізу HLS стріму, який працює у поєднанні з Akamai HLS.js Player. Він дозволяє перевіряти якість стрімів у реальному часі, виявляти проблеми з буферизацією, затримками та адаптивним бітрейтом. На наступному зображенні можна побачити, як виглядає плеєр і які опції у нього є.

Stream validator дозволяє не тільки відловлювати помилки у стрімі та невідповідності згідно з специфікацією HLS, а також додатково відображати загальну інформацію щодо плейлистів та медіафайлів.

3. Shaka Player — потужний плеєр для DASH розроблений Google, але також може використовуватися для програвання та тестування HLS.

4. Native HLS Playback — Це розширення для браузера, яке є оболонкою для плеєра hls.js. Це розширення дає змогу відтворювати будь-який HLS стрім, вбудований як елемент HTML на поточній сторінці.

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

Так само я б хотів відзначити, що будь-яке тестування відтворення має супроводжуватися записом HTTPs трафіку, що зібрати якомога більше інформації про HLS стрім у разі виникнення якоїсь аномалії. Для запису трафіку з нативних пристроїв можна використовувати Charles Proxy, а при програванні стріму в браузері можна обійтися DevTools

Тестування продуктивності

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

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

Налаштування дозволяють вибрати протокол, пропускну здатність, аудіодоріжки, субтитри тощо.

А так виглядає результат виконання цього семплера. Важливо помітити, що семплер робить завантаження не тільки .m3u8 файлів, а також завантажує медіафайли з розширенням .ts або .vtt

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

Першим кроком є завантаження m3u8-плейлистів, які містять інформацію про доступні варіанти потоку з різною якістю відео та аудіо. Важливо враховувати час відповіді сервера на запити плейлистів, оскільки це безпосередньо впливає швидкість початку відтворення відео стрімінгу або TTFF. Якщо тестування проводиться з невеликою кількістю користувачів, це допоможе встановити базовий час відповіді за умов низького навантаження. Ці дані можна використовувати як відправну точку для порівняння результатів за різних рівнів навантаження. Але для швидкого старту рекомендований час відгуку має бути в межах 200 мілісекунд.

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

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

• Час відповіді сервера (Server Response Time): Вимірює час, потрібний серверу для реагування на запит клієнта. Він вимірюється в мілісекундах і є важливим фактором для взаємодії між клієнтом та серверною частиною.
• Пропускна здатність (Throughput): Це процес вимірювання кількості запитів, які система може обробити протягом заданого періоду часу для обробки даних. Простіше кажучи, пропускна здатність — це кількість транзакцій, які система може обробити за певний період часу.
• Час завантаження медіасегментів (Segment Download Time): Вимірює, скільки часу потрібно для завантаження кожного відеосегменту. Оптимальний час завантаження є критичним для забезпечення плавного відтворення без затримок і буферизації.
• Максимальна кількість одночасних користувачів (Maximum Concurrent Users): Показує, скільки користувачів може одночасно обслуговувати система, перш ніж почнуться помітні проблеми з продуктивністю. Це ключовий показник масштабування сервера HLS.
• Частота помилок HTTP-запитів: Відсоток помилок у HTTP-запитах, успішно оброблених сервером. Високий рівень помилок може вказувати на проблеми в серверній частині або надмірне навантаження.
• Час початку відтворення (Startup Time): Час, необхідний для початку відтворення відео після запиту користувача. Це важливо для забезпечення відмінного досвіду користувача, особливо в умовах прямої трансляції.

Також під час тестування продуктивності зазвичай звертають увагу на використання ресурсів сервера включаючи моніторинг використання ЦП, пам’яті, дискового простору та навантажень на мережу. Забезпечення оптимального використання ресурсів дозволяє уникнути перевантаження та падіння серверів.

Підсумовуючи, можна сказати, що тестування продуктивності HLS є важливим етапом для забезпечення стабільної роботи стрімінгових сервісів під різними умовами навантаження.

Заключне слово

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

Сподіваюся вам було цікаво, дякую за увагу.