Анотація: В цій статті проаналізовані основні методи технології MetidaBSE з передачі медіа даних з подальшим розщепленням на відео та аудіо-потоки. Проведені суб’єктивні оцінки експертів, та зроблене фізичне моделювання системи з використанням вищезазначеної технології. На основі результатів дослідження двох варіантів розробки системи було показано який варіант краще.
Ключеві слова: Експертна оцінка, WebRTC, RTSP, MetidaBSE.
УДК 621.397
Степанюк Андрій Ігорович
Студент
НТУУ «КПІ»
ДОСЛІДЖЕННЯ СЕРВІСУ ПЕРЕДАЧІ МЕДІА ДАНИХ З РОЗЩЕПЛЕНИМИ АУДІО ТА ВІДЕО ПОТОКАМИ
Анотація: В цій статті проаналізовані основні методи технології MetidaBSE з передачі медіа даних з подальшим розщепленням на відео та аудіо-потоки. Проведені суб’єктивні оцінки експертів, та зроблене фізичне моделювання системи з використанням вищезазначеної технології. На основі результатів дослідження двох варіантів розробки системи було показано який варіант краще.
Ключеві слова: Експертна оцінка, WebRTC, RTSP, MetidaBSE.
Summary: In this article analyze the basic methods of MetidaBSE technology transfer media data and then splitting to the video and audio streams. Conducted subjective experts and made physical simulation system using the above technologies. Based on the research of two variants development of the system was shown which option is better.
Tags: Expert opinion, WebRTC, RTSP, MetidaBSE.
Вступ
В наш час, сучасні інформаційні технології майже стирають кордони світових держав, а спілкування стає дедалі простішим. Сьогодні вже немає проблеми поспілкуватися з людиною на іншому кінці земної кулі. Існує незліченна кількість сервісів де люди діляться своїми знаннями в тій чи іншій сфері. Отримати знання це лише питання бажання. Але існує досить суттєва проблема – знання мови. Тому виникає необхідність в розробці сервісу яка допоможе ліквідувати цю перешкоду та безперешкодно обмінюватися знаннями один з одним.
В наш час існує багато систем які дозволяють вести стріми, де люди в режимі реального часу діляться один з одним знаннями. Деякі з цих систем потребують значних знань для створення подібної конференції, деякі з них потребують спеціального клієнтського ПЗ для того щоб була можливість спілкуватись. Інші просто не мають можливості розщепити медіа потік, з підміною аудіо потоку. Наприклад: Skype – клієнтська програма яка дозволяє великій кількості людей спілкуватися один з одним, вести онлайн стріми, але вимагає встановлення дуже неповороткого клієнтського ПЗ. Інший схожий сервіс який базується на платформі WoWza Media Server потребує значних знань для розгортання даної платформи в себе на сервері, а також потребує використання Java player чи flash media player.
Технологія WebRTC це інтернет протокол із відкритим кодом призначений для організації голосового та відеозв'язку через інтернет у режимі реального часу.[1] На базі цього інтернет протоколу буде вестись подальше дослідження систем із синхронно розщепленим медіа потоком, а саме - аудіо та відео.
Мета дослідження
Метою дослідження є покращення ефективності розщеплення медіа потоку з підміною аудіо-потока та подальшою синхронізацією з відео-потоком.
Математична модель
Моя технологія надасть змогу усунути проблему пов’язану з нерозумінням мови. Для цього користувачу необхідно буде зайти на сайт, обрати бажану відео трансляцію, вибрати мову і слухати спікера вже на обраній мові. Ідея полягає в тому що до онлайн трансляції буде долучатися професійний перекладач який в режимі реального часу буде переводити цю трансляцію на необхідну мову, а користувач в свою чергу зможе прослуховувати цей стрім обраною мовою. Ця система зображена на рисунку 1. Основним елементом є сервер на якому проходить синхронізація та розщеплення потоків, але не зображений на цій схемі.
Рис. 1 – Досліджувана система
В ході дослідження такого сервісу постала задача як виконувати розщеплення та синхронізацію медіа потоків.
Варіант 1. Заглушати основну аудіо доріжку спікера непродуктивно, тому що доріжка все одно є, відповідно розмір пакета пересланих даних з двома аудіо доріжками займає вже значно більше, а це буде суттєво завантажувати канал, і створювати додаткові проблеми при передачі \ отриманні пакетів.
Варіант 2. Передача розщеплення та синхронізація медіа даних відбувається в один етап. Тобто перед безпосередньою відправкою до аудиторії чи навпаки. Дана схема роботи зображена рисунку 2.
Рис. 2 – Варіант 2 досліджуваної системи
Варіант 3. Передача розщепленого медіа потоку на відео та аудіо потік відбуваться після передачі медіа даних від доповідача серверу. Далі аудіо-потік підміняється на доріжку перекладача і синхронізується вже після обробки сервером аудіо доріжки перекладача. Процес синхронізації відбувається вже перед відправкою медіа даних до аудиторії. Дана схема роботи зображена рисунку 3.
Рис. 3 – Варіант 3 досліджуваної системи
Було вирішено провести фізичне дослідження щоб обрати оптимальний з запропонованих варіантів. Дослідження проводились таким чином щоб всі користувачі знаходились територіально в Україні, тобто були підключені до українських інтернет провайдерів, це дасть змогу збільшити швидкість підключення респондентів та спікерів. Всього сервісом користувалось 10 реальних користувачів, які створювали між собою конференції та спілкувались в режимі реального часу, використовуючи наведені вище варіанти.
В випадку з досліджуваним сервісом, який займається роздачею медіа даних в режимі реального часу налаштовуємо на сервері RAID масив 10 з чотирьох дисків. Обрали саме 10-й рейд масив адже він являється надійним варіантом для зберігання даних, це зумовлено тим що запис даних на цю систему відбувається послідовно на декілька дисків. Швидкість зчитування, та запису даних на диск є високою [2].
Конфігурація тестового серверу обрано з доступних варіантів і наведений в таблиці 1.
Табл. 1 – Набір характеристик тестового сервера.
|
Характеристика |
Значення параметру |
|
Процессор |
3.2 Ггц 4 потоки |
|
ОЗУ |
32 GB |
|
Пам'ять |
4xSATA 128 GB |
|
Рейд |
10 |
|
Швидкість підключення |
1 гб\с |
Технологія WebRTC з RTSP Media server яку ми використовуємо в якості основи та авторська розробка MetidaBSE було встановлено на чистий сервер, без додаткових сервісів які могли створювати навантаження
Встановивши на нашу систему необхідні для роботи ПЗ, а саме: досліджувану платформу та сконфігурувавши її відповідно її налаштувавши, приступаємо до підключення досліджуваного сервісу. Наш спікер який виконує роль стрімера знаходиться в Україні в місті Киеві та підключений до мережі по технології Ethernet зі швидкісним каналом 100 мб\с. Всі користувачі які зайшли дивитись трансляцію на сервісі використовують таке ж саме з’єднання з такою ж самою швидкістю, але знаходяться не тільки в Києві але в межах України. Загальна кількість користувачів 10. На сервері додатково встановлені програми для збору інформації, а саме: кількість втрачених пакетів, завантаженість каналу, джитер.
Критерієм оцінки якості обрано групу технічних параметрів, таких як: джитер, затримка та втрати пакетів. Як критерій якості роботи досліджуваної системи, адже ці три критерії являються найкращими показниками якості зв’язку тому що з погіршеннями цих показників, тобто збільшенням джитеру(мс), втратою пакетів чи затримкою(мс) якість зв’язку погіршуються, а саме втрата чіткості зображення, розсинхронізація медіа потоків, шуми.
Наші респонденти давали експертну оцінку якості, відповідно до їх суб’єктивних вподобань якості зв’язку – критерії були наступні, чіткість зображення, запізнення аудіо та відео потоків, сторонні шуми, якість мовлення та гучність спікера. Наша мета обрати систему яка при сталих показниках дає більш чітке зображення згідно експертної оцінки. [3]
Для перевірки критерію було вирішено провести ряд експериментів з використанням системи моделювання мережевих перешкод мультимедійних потоків.
Таблиця 2 – Характеристики освітнього відео файлу
|
Параметр |
Значення |
|
Розширення |
640x360 |
|
Кодек |
H.264 |
|
Частота ключових кадрів |
5 секунд |
|
Кількість кадрів в секунду |
25 кадрів |
|
Тривалість |
182 секунди |
Для проведеного дослідження було встановлена авторська розробка системи MetidaBSE яка базується на технології WebRTC та RTSP протоколу.
Усі експерименти проводяться для двох варіантів з однаковими бітовими швидкостями, які представлені нижче. При цьому максимальна смуга пропускання мережевого каналу для цих експериментів обмежена величиною 1048 Кбіт/с.
– 1048 Кбіт/с (1000 Кбіт/с відео та 48 Кбіт/с аудіо).
Проведені експерименти з емуляцією різних мережевих перешкод, таблиці. 3.
|
Умови експеримента |
Значення параметрів |
Кількість експериментів |
Число неспівпадань |
|
Основні експерименти (тривалістю 2 хвилини) |
|||
|
Потік 1048 кбіт/с |
Затримка: 2, 12, 25, 37 мс; Джиттер: 1, 50, 100, 150 мс; Втрати пакетів: 0, 2, 4, 6, 8 %. |
46 |
1 |
|
Додаткові виміри в точках невідповідності (тривалістю 3 хвилини) |
|||
|
1048 кбіт/с |
– |
18 |
1 |
Таблиця 3 – Результати проведених експериментів
На основі критерію оцінки якості мультимедійних потоків були оцінені результати 46 експериментів. Отримані значення за допомогою цього критерію оцінки були порівняні з візуальною оцінкою якості мультимедійних потоків проведених експериментів. З 46 експериментів в 45 порівняння показало збіг результатів обох використовуваних підходів оцінки якості, а саме - за допомогою критерію оцінки і візуального. Візуально експериментатор спостерігав зупинки і завмирання відео, а також у разі, якщо відтворення відео-потоку не починалося через 20 секунд після натиснення кнопки програвання, якість потоку вважалася поганою. Для перевірки точок неспівпадання були проведені додаткові 18 експериментів, збільшених по тривалості до трьох хвилин. За підсумками яких залишилася тільки одна точка неспівпадання. Залежності параметра Tstart від втрати пакетів, затримки і джитеру для бітрейту 1048 Кбит/з представлені в таблиці.
Результати проведеного нами дослідження наведені в таблицях 2 та 3.
Таблиця 2 – Залежність часу початку відтворення від мережевих характеристик для системи з суцільним медіа потоком.
|
Бітрейт: 1048 Кбіт/с |
Джитер, мс |
||||||||||||||||
|
1 |
50 |
100 |
150 |
||||||||||||||
|
Затримка, мс |
2 |
12 |
25 |
37 |
2 |
12 |
25 |
37 |
2 |
12 |
25 |
37 |
2 |
12 |
25 |
37 |
|
|
Втрати пакетів, % |
0 |
14 |
14 |
14 |
12 |
12 |
14 |
14 |
16 |
15 |
14 |
17 |
18 |
18 |
18 |
18 |
19 |
|
2 |
14 |
16 |
20 |
32 |
20 |
32 |
32 |
34 |
32 |
38 |
– |
– |
– |
– |
– |
– |
|
|
4 |
16 |
22 |
32 |
38 |
36 |
32 |
38 |
28 |
32 |
– |
– |
– |
– |
– |
– |
– |
|
|
6 |
33 |
28 |
62 |
64 |
30 |
32 |
– |
– |
– |
– |
– |
– |
– |
– |
– |
– |
|
|
8 |
36 |
34 |
66 |
54 |
56 |
– |
– |
– |
– |
– |
– |
– |
– |
– |
– |
– |
|
|
|
– відеопотік відтворювався без затримок та зупинок |
||||||||||||||||
|
|
– відеопотік відтворювався із затримками або зупинками |
||||||||||||||||
|
|
– вимір не проводився, оскільки якість відтворення була поганою при менших мережевих перешкодах |
||||||||||||||||
|
|
– відеопотік відтворювався без затримок та зупинок, хоча респонденти оцінили якість як погане |
||||||||||||||||
Таблиця 3 – Залежність часу початку відтворення від мережевих характеристик для медіа потоку з розщепленням після запису стрімера
|
Бітрейт: 1048 Кбіт/с |
Джитер, мс |
||||||||||||||||
|
1 |
50 |
100 |
150 |
||||||||||||||
|
Затримка, мс |
2 |
12 |
25 |
37 |
2 |
12 |
25 |
37 |
2 |
12 |
25 |
37 |
2 |
12 |
25 |
37 |
|
|
Втрати пакетів, % |
0 |
12 |
14 |
14 |
12 |
14 |
14 |
14 |
18 |
16 |
12 |
18 |
16 |
16 |
17 |
17 |
18 |
|
2 |
14 |
16 |
18 |
24 |
18 |
28 |
32 |
32 |
32 |
32 |
38 |
– |
– |
– |
– |
– |
|
|
4 |
14 |
20 |
32 |
34 |
34 |
32 |
36 |
28 |
34 |
36 |
– |
– |
– |
– |
– |
– |
|
|
6 |
26 |
24 |
54 |
52 |
32 |
34 |
40 |
– |
– |
– |
– |
– |
– |
– |
– |
– |
|
|
8 |
28 |
30 |
64 |
54 |
56 |
60 |
– |
– |
– |
– |
– |
– |
– |
– |
– |
– |
|
|
|
– відеопотік відтворювався без затримок та зупинок |
||||||||||||||||
|
|
– відеопотік відтворювався із затримками або зупинками |
||||||||||||||||
|
|
– вимір не проводився, оскільки якість відтворення була поганою при менших мережевих перешкодах |
||||||||||||||||
|
|
– відеопотік відтворювався без затримок та зупинок, хоча респонденти оцінили якість як погане |
||||||||||||||||
Згідно проведених досліджень усі учасники експерименту змогли надати суб’єктивні експертні оцінки щодо обох варіантів дослідження. Як видно з рисунку 5 варіант 3 показав кращу загальну середню оцінку на відміну від першого варіанту.
Рис. 5 Експертна оцінка для проведених досліджень
Висновок
Як видно з проведеного дослідження, в системі передачі медіа даних з синхронно розщепленими аудіо та відео потоками, з подальшою заміною аудіо-потоків, та синхронізацією після заміни, з технологією MetidaBSE, кращим є варіант 3. А також згідно експертних оцінок якість послуги стала краща. При незначних втратах пакетів та показниках затримки у варіанті 3, якість зв’язку значно краща ніж показує варіант 2.
Згідно з таблицями 2 та 3 які наведені вище, в досліджуваній системі де використовується варіант 3 навіть при втраті пакетів у 4% з затримкою в 2-12 мс та джитері в 1 мс якість зв’язку краща ніж при тих самих показниках в варіанті 2.
Перелік посилань
