Потокове мультимедіа

Перші спроби відображення мультимедіа інформації на комп'ютерах почалися в середині XX століття. Однак, прогрес у цій сфері був дуже малим, внаслідок високої вартості та обмежених можливостей комп'ютерів тих часів.

З кінця 1980-х і до 1990-х комп'ютери, доступні споживачам, вже були здатні відображати різні види інформації.

Тим не менш, комп'ютери мережі залишалися обмеженими, а потокове мультимедіа поступалося традиційному (CD-ROM).

У період з 1990 до 2000 користувачі інтернету отримали:

• Високу пропускну здатність мереж, зокрема, на останній милі
• Зросла кількість абонентів мереж, особливо Інтернету
• Стали використовуватися стандартизовані протоколи та формати, такі як TCP/IP, HTTP і HTML
• З'явилася комерція в Інтернеті

Ці досягнення в області мереж в сукупності з високопродуктивними домашніми комп'ютерами і сучасними операційними системами зробили потокову мультимедійну інформацію доступною широкому колу простих користувачів. Автономні приймачі інтернет-радіо пропонували користувачам можливість прослуховування потокового звуку без наявності комп'ютера.

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

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

Реалізація сервера потокового мовлення за принципом 1 клієнт — 1 з'єднання

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

Розмір сховища (в мегабайтах) = тривалість (у секунда х) * бітрейт (у кбіт/с) / (8 * 1024)

(Якщо вважати, що 1 мегабайт = 8 * 1024 кбіт)

Приклад з життя: Одна година відео, закодованого зі швидкістю 300 кбіт/с (типове відео за станом на 2005 рік, що має розмір 320 × 240 пікселів), буде займати:

(3600 с * 300 кбіт/с) / (8 * 1024) = порядку 130 Мб місця на диску

Якщо файл, що зберігається на сервері з режимом передачі за запитом, буде проглядатися 1000 людей одночасно за протоколом Unicast (1 клієнт — 1 з'єднання), то сервер повинен мати таку пропускну здатність:

300 кбіт / с * 1000 = 300.000 кбіт / с = 300 Мбіт/с мережевого інтерфейсу

Це еквівалент близько 125 Гб інформації на годину. Зрозуміло, при використанні протоколу Multicast навантаження на сервер набагато нижче, так як для передачі інформації всім клієнтам використовується єдиний потік. Отже, такий потік буде займати всього 300 кбіт / с мережевого інтерфейсу сервера. Детальніша інформація про ці протоколи дається нижче.

Розробка мережевих протоколів потокового мовлення викликає наступні проблеми:

• Датаграмні протоколи, такі як User Datagram Protocol (UDP), відправляють потік медіаінформації як потік окремих маленьких пакетів. Він простий і ефективний; в той же час, у специфікації протоколу немає гарантії доставки даних одержувачу. Це дуже сильно ускладнює пошук і виправлення одержуваних даних приймаючим інформацію додатком. При втраті даних потік може бути відключений.
• Протоколи RTSP, RTP і RTCP спеціально розроблялися для передачі мультимедійної інформації по мережі. Останні два побудовані на основі UDP.
• Надійні протоколи, такі як TCP, гарантують коректність одержуваних даних клієнтів потокового мовлення. Однак при великій кількості помилок при з'єднанні / підтвердженні одержуваної інформації передана інформація може стати неактуальною. Це також може викликати значні затримки при передачі інформації на час, витрачений на пересилання пошкодженої інформації. Одним з рішень даної проблеми є буферизація інформації на стороні клієнта.
• Протоколи Unicast відправляють окрему копію даних кожного клієнта. Unicast підходить для більшості користувачів мережі Інтернет, але сильно утрудняє масштабування сервера для більшої кількості клієнтів.
• 

  При широкомовній передачі одна копія даних передається всім клієнтам сервера
  Протоколи Multicast розроблені для зниження навантаження з серверів на підключення / ширину каналу при отриманні потокового мультимедіа великою кількістю клієнтів. Ці протоколи відсилають одну порцію даних цілій групі клієнтів. Залежно від типу мережевої інфраструктури, групова передача даних може бути доступна, а може і не бути. Одним з потенційних недоліків групової передачі є відсутність можливості реалізувати функцію відео за запитом. Безперервне мовлення потокової інформації також робить неможливим управління відтворенням користувачем. Проте, ця проблема може бути вирішена впровадженням у мережу передачі даних кешуючих серверів і буферизує приймається потік програмного забезпечення.
• Multicast дозволяє передавати один потік інформації групі клієнтів по мережі. Однією з проблем при реалізації подібної схеми потокового мовлення є коректне налаштування маршрутизаторів для передачі широкомовних пакетів з одного сегмента мережі в іншій. Якщо організація, що надає потокове мовлення, має контроль над мережею між сервером і клієнтами (наприклад, в освітній, урядовій або корпоративній мережі), то протоколи маршрутизації, такі як IGMP і PIM, можуть бути використані для доставки мультимедіа кільком клієнтам з різних сегментів LAN.
• Протоколи P2P можуть використовуватися при поширенні попередньо записаної мультимедіа між комп'ютерами. Це знімає навантаження з сервера, проте мережу передачі даних між сервером і одним з клієнтів стає вузьким місцем даного варіанта реалізації потокового мовлення інформації.

• IPTV
• Список систем потокового мультимедіа
• Цифрове телебачення
• Відеопотік
• Користувач мережі передавання даних