Мультимедіа поверх ip
Потоковий протокол реального часу (Real Time Streaming Protocol, RTSP). прикладний протокол, призначеним для використання в системах, що працюють з мультимедіа даними, і дозволяє клієнтові віддалено управляти потоком даних з сервера, надаючи можливість виконання команд, таких як «Старт», «Стоп», а також доступу за часом до файлів, розташованим на сервері .
[Ред] Приклад
Приклад роботи алгоритму показаний на малюнку праворуч. За HTTP ми отримуємо не посилання на ролик, а метафайл, який містить інформацію про ролику, в тому числі і посилання (найчастіше він містить тільки її). Наприклад: "rtsp: //example.com/movie.mp4". Далі ми передаємо цей метафайл медіаплєєру, який робить запит медіафайлу. RTSP-повідомлення надсилаються окремо від мультимедійного потоку. Для них використовується спеціальний порт з номером 554.
[Ред] Формат RTSP запитів
Приклад запиту: "rtsp: //example.com/movie.mp4 RTSP / 1.0"
[Ред] Список команд
- DESCRIBE - запит опису контенту
- OPTIONS - запит підтримуваних методів
- PLAY - запит початку мовлення контенту
- PAUSE - запит тимчасової зупинки мовлення
- RECORD - запит на записування контенту сервером
- REDIRECT - перенаправлення на інший контент
- SETUP - запит установки транспортного механізму для медіа-контенту
- ANNOUNCE - оновлення даних опису контенту
- GET_PARAMETER - запит зазначених параметрів у сервера
- SET_PARAMETER - установка параметрів сервера
- TEARDOWN - зупинка потоку і звільнення ресурсів
Протокол RTP (англ. Real-time Transport Protocol) працює на прикладному рівні і використовується при передачі трафіку реального часу. Найчастіше даний протаколе реалізується над UDP. Протокол TCP так само стандартизований для передачі RTP, але як правило не використовується, так як надійність передачі в TCP формує тимчасові затримки.
[Ред] Структура пакета
0-1 - Ver. (2 біта) вказує версію протоколу. Поточна версія - 2.
2 - P (один біт) використовується у випадках, коли RTP-пакет доповнюється порожніми байтами на кінці.
3 - X (один біт) використовується для вказівки розширень протоколу, задіяних в пакеті.
4-7 - CC (4 біта) містить кількість CSRC-ідентифікаторів, що настають за постійним заголовком.
8 - M (один біт) використовується на рівні додатку та визначається профілем. Якщо це поле встановлено, то дані пакета мають якесь особливе значення для додатка.
9-15 - PT (7 біт) вказує формат корисного навантаження і визначає її інтерпретацію додатком.
64-95 - SSRC вказує джерело синхронізації.
EHL (Extension Header Length) - - кількість 32-бітних слів в блоці даних розширення заголовка.
L - останній байт в пакеті, який визначає довжину області набивання в байтах (використовується для вирівнювання в останньому пакеті).
[Ред] Відновлення втрачених пакетів
[Ред] FEC
[Ред] інтерлівінг
interleaving (чергування) - цей підхід базується на змішуванні (інтерлівінг) порядку медіа перед передачею і сортування (деінтерлівінге) при його отриманні. Таким чином, завдяки змішуванню НЕ буде втрачено наступних один за одним пакетів, і один великий розрив при програванні медіа не утворюється. Наприклад, пакет може містити 5 мс програвання музики. Якщо вони були послані по порядку, втрата пакета спричинить перерву в програванні на 5 мс. Замість цього всі парні семпли інтервалу в 10 мс надсилаються в одному пакеті, а непарні в другому. Тепер втрата третього пакета означає не пропуск в музиці в 5 мс, а чергування порожніх і заповнених музикою коротких проміжків протягом 10 мс. З втратою можна легко впоратися, якщо плеєр використовує інтерполяцію, враховуючи попередній і наступний зразки. В результаті ми отримаємо тимчасову втрату в дозволі на 10 мс, але значного переривання не буде. Ця схема интерливинга працює тільки при відсутності стиснення. Однак схема интерливинга може також застосовуватися після стиснення, якщо є можливість виявити кордону семплів в стислому потоці.