Потокове передавання медіа із внутрішніх HTML-сторінок за прикладом

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

• Потоковий носій дійсно зводиться до формату контейнера та протоколу потокового передавання :
  • Всі аудіодані кодуються (через аудіокодек) в аудіопотоки
  • Всі дані відео кодуються (знову ж таки, через кодек) у бітовий потік відео
  • Два потоки об'єднуються ( мультиплексовані? ) Разом у контейнер, який зрештою стає файлом (наприклад, MP4 тощо)
  • Потім спеціальний медіа-сервер подає цей контейнер (файл MP4 або якийсь інший формат) клієнту (можливо, відеоплеєр HTML5, який працює у чиємусь браузері) через стандартний протокол потокового передавання, наприклад, RTSP
    • Що стосується клієнта браузера, я припускаю, що у самого браузера є клієнт RTSP, який потім якимось чином представляє користувачам HTML5 Video Player
• Я міг би розмістити файл MP4 з веб- сервера, такого як nginx або httpd, але оскільки ці сервери не є серверами RTSP, я можу розглядати запити для MP4 лише як запити на завантаження , і, таким чином, не зможе передавати потік медіафайли
  • Так само, якби я мав використовувати curlдля отримання файлів із сервера nginx, оскільки curlні nginx не говорять RTSP, це вважатиметься завантаженням файлу
• Але, коли я розміщую файл MP4 з сервера потокового медіа (VideoLAN, Red5, Wowza тощо), і я використовую клієнт RTSP (або будь-який підтримуваний потоковий медіа-клієнт), щоб запитувати потік з цього сервера, що тоді і тільки потім робить будь-який фактичний потокове відбувається
  • Отже, незважаючи на те, що "відеоролики" YouTube або Vimeo розміщуються на сторінках HTML, що над HTTP-серверами обслуговуються HTTP-серверами, я припускаю, що вбудовані відеоплеєри на цих сторінках (з яких відео насправді відтворюються) насправді починаються секунди , подальше з'єднання з потоковим сервером та потокове потоки відбувається через RTSP або якийсь інший протокол, який не є HTTP

Отже, це моє розуміння, і, мабуть, я спершу попрошу, що якщо щось, про що я говорив вище, невірно, почніть, виправляючи мене! Якщо припустити, що я більш-менш правильний:

Як потокові медіаплеєри, що працюють на сторінках HTML і обслуговуються HTML-серверами, встановлюють потокові (RTSP тощо) зв’язки із потоковими медіа-серверами (обслуговуючи RTSP-запити)?

Як потокові медіаплеєри, що працюють на сторінках HTML і обслуговуються HTML-серверами, встановлюють потокові (RTSP тощо) зв’язки із потоковими медіа-серверами (обслуговуючи RTSP-запити)?

Загальні програми

Наразі RTSP, як видається, більше використовується для додатків / інтерфейсів пристроїв, які безпосередньо живуть (наприклад, IP-камера) або ретрансляції (як двигун), ніж це для потокової передачі збережених медіа-файлів з фізичного місця через веб-інтерфейс відтворення HTTP з вбудований програвач.

Здається, що RTSP є протоколом, що складається з надзвичайних ситуацій , і він використовує UDP більше, ніж TCP під час потокової передачі, і він більше використовується як серверний пристрій (як IP-камера), який підключений до мережі TCP / IP і подає потоки через UDP тощо. Потім ви підключаєтесь до цих каналів (сервера) як клієнта в тій самій мережі і можете надсилати RTSP-запити для відповідного використання.

^{Протокольні директиви}

^{Хоча деяким чином схожий на HTTP, RTSP визначає керуючі послідовності, корисні для управління відтворенням мультимедіа. Хоча HTTP без стану , RTSP має стан; ідентифікатор використовується, коли потрібно для відстеження паралельних сеансів. Як і HTTP, RTSP використовує TCP для підтримки кінцевого зв'язку і, хоча більшість повідомлень управління RTSP клієнтом надсилає на сервер, деякі команди рухаються в іншому напрямку (тобто з сервера на клієнта).}

^{Тут представлені основні RTSP-запити. Також доступні деякі типові HTTP-запити, такі як запит OPTIONS. Типовий номер порту транспортного рівня 554 [3] для TCP та UDP, останній рідко використовується для запитів управління.}

^{_{джерело}}

^{Без громадянства}

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

^{Недоліком без громадянства є те, що може знадобитися включення додаткової інформації до кожного запиту, і цю додаткову інформацію потрібно буде інтерпретувати сервер.}

^{_{джерело}}

Логічний потік

Те, як я розумію потік потокових носіїв у цій формі:

• сервер, на якому знаходиться медіа-контент, буде інкапсулювати, стискати, кодувати тощо вміст відео / аудіо даних у відповідних форматах та сегментах для доставки потоку
• веб-сервер, який прослуховує з'єднання для доступу до потокового носія, доставить усі ресурси, необхідні для передачі носія
• клієнт запитує та завантажує відповідні ресурси та файли, а потім збирає їх безперервно для відтворення за допомогою URL-покажчика як налаштовано та інших параметрів. Програмне забезпечення для відтворення на рівні клієнта збирає пакети, передані послідовно, щоб забезпечити належне відтворення вмісту.

Будь ласка, дивіться розділ Streaming Technologies нижче для загального порівняння HTTP та RTSP.

Крім того

У наведеному нижче розділі 10 причин, чому ви ніколи не хочете розміщувати власні відеоролики, я наводив цитати частин, які допомогли відповісти на ваше запитання "загалом", не надто конкретно.

По суті, це говорить про те, що веб-сайт, який має вбудований елемент управління медіаплеєром:

• ⁽¹⁾ виявити налаштування веб-браузера клієнта при "підключенні та запиті" від клієнта та
• ⁽²⁾ це встановить кодек та будь-які інші налаштування виявлення на стороні клієнта на відповідні значення параметрів, а потім
• ⁽³⁾ воно передаватиме відео безпосередньо з потокового сервера, на якому розміщуються відео- та аудіофайли, на основі подальшого коду у ваших вбудованих мультимедійних програвачах, що вказують на URL-адресу медіа-файлу на розміщеному сервері.

^{Потокові технології}

^{Клієнтський браузер повинен отримати дані від сервера та передати їх потоковому додатку для обробки. Програма для потокового передавання перетворює дані у зображення та звуки. Важливим фактором успіху цього процесу є здатність клієнта швидше отримувати дані, щоб програма могла відображати інформацію. Зайві дані зберігаються в буфері - області пам'яті, відведеної для зберігання даних у програмі. Якщо дані затримуються при передачі між двома системами, буфер спорожняється, а подання матеріалу не буде рівним.}

^{Протокол HTTP}

^{HTTP є основним способом зв’язування документів в Інтернеті. Клієнт встановлює з'єднання з сервером, що містить файл, який підлягає передачі, файл витягується та з'єднання закривається. Сервер HTTP повідомляє браузеру тип файлу, який потрібно перенести.}

^{Переваги використання HTTP}

^{Під час передачі файлів за допомогою HTTP спеціальний потоковий сервер не потрібен. Поки ваш браузер розуміє типи MIME, він може отримувати потоковий файл з HTTP-сервера. Однією з відмінних переваг потокової передачі файлів за допомогою HTTP є те, що вони можуть проходити через брандмауері та використовувати проксі-сервери.}

^{Деякі недоліки}

^{HTTP-потоки використовують TCP / IP (протокол управління передачею та протокол Internet) для забезпечення надійної доставки файлів. Цей процес перевіряє відсутність пакетів і просить їх повторно передати. Це стає проблематичним в сценарії потокового передавання, коли ви хочете, щоб дані не враховувалися, якщо вони втрачені в доставці, тому динамічні файли продовжують відтворюватися. HTTP не може виявити швидкість модему, тому адміністратори серверів повинні цілеспрямовано виробляти файли з різною швидкістю стиснення для користувачів сервера з різними типами з'єднань. Потокове передавання файлів з HTTP-серверів не рекомендується в ситуаціях з високим попитом.}

^{Протокол RTSP}

^{RTSP - це стандартний протокол, який використовується більшістю постачальників потокового сервера. Сервери RTSP використовують UDP (User Datagram Protocol) для передачі мультимедійних файлів. UDP не постійно перевіряє, чи файли надійшли до місця призначення. Це перевага для потокових програм, оскільки воно дозволяє переривати передачу файлів до тих пір, поки затримка не буде занадто довгою. Результатом цього методу є те, що час від часу відбувається втрата даних, але файли продовжують відтворюватися, якщо затримка невелика.}

^{джерело}

^{10 причин, чому ніколи не слід розміщувати власні відео}

^{Ми говоримо про вбудовування та самостійне розміщення відео}

^{По-перше, ви завантажуєте свій відеофайл у сторонні послуги відеохостингу, такі як YouTube, Vimeo чи Wistia.}

^{Потім ви копіюєте невеликий шматочок коду, який вони вам надають, і вставляєте його у свою посаду чи сторінку на свій власний сайт WordPress. Відео з’явиться на вашому веб-сайті в тому місці, куди ви вставили вбудований код, але саме відео передається з серверів відеохостингу, на відміну від вашого власного веб-сервера, де розміщується ваш сайт WordPress.}

^{4. Немає єдиного стандарту формату файлів для веб-відео}

^{Поточна специфікація проекту HTML5 не визначає, які веб-переглядачі повинні підтримувати формати відео. В результаті основні веб-браузери розійшлися, кожен з яких підтримує інший формат. Internet Explorer і Safari відтворюватимуть відео H.264 (MP4), але не WebM або Ogg. Firefox відтворюватиме відео Ogg або WebM, але не H.264. На щастя, Chrome відтворюватиме всі основні формати відео, але якщо ви хочете переконатися, що ваше відео буде відтворюватися у всіх основних веб-браузерах, вам доведеться конвертувати ваше відео у декілька форматів: .mp4, .ogv та .webm}

^{5. Сподіваюсь, вам подобається конвертувати відео. Багато.}

^{Більшість вашої аудиторії, швидше за все, переглядатимуть ваші відео зі свого робочого столу чи ноутбука, використовуючи швидкісне підключення до Інтернету. Цим людям ви захочете доставити великий файл високої якості HD, щоб вони могли переглянути його на весь екран, якщо вони захочуть. Як правило, це означає 1080p або 720p файл при високому потоковому бітрейті (5000 - 8000 kbps).}

^{Але ви також хочете кодувати меншу версію з меншою роздільною здатністю для доставки на мобільні пристрої, такі як телефони та планшети, а також доставку глядачам із більш повільним підключенням до Інтернету.}

^{6. Відеопрогравачі}

^{Відеоплеєр - це невеликий фрагмент веб-програмного забезпечення, встановленого на вашому сайті, який автоматично визначатиме, який пристрій запитує ваше відео, разом зі швидкістю його з'єднання, а потім доставляє відповідній версії цій особі.}

^{7. Напружений код [або шорт-коди]}

^{Якщо ви використовуєте сторонній плагін або вбудовані відео-можливості WordPress, вам потрібно створити трохи коду, щоб повідомити відеоплеєру, які формати ви створили, а також про їх розташування на сервері. Це виглядає приблизно так ...}

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

То яке найкраще рішення для додавання відео на ваш сайт?

Просто скористайтеся стороннім службою відеохостингу, а потім просто вставте своє відео у свій WordPress пост або сторінку.

Перший крок: Завантажте своє відео в одну з популярних, налагоджених сервісів відеохостингу, наприклад Vimeo PRO.

Крок другий: Після завантаження вашого відео та готовності до перегляду скопіюйте його URL-адресу. Поверніться на свій сайт WordPress та вставте URL-адресу у свою публікацію чи сторінку, де ви хочете відобразити відео.

---

^{Коли люди переглянуть вашу сторінку, відео з’явиться в тому місці, де ви вставили URL-адресу. Але сам відео файл передаватиметься з серверів відеохостингу, на відміну від вашого власного сервера, на якому розміщений ваш сайт WordPress.}

_{Вбудований відеоплеєр автоматично визначатиме пристрій користувача, браузер та швидкість підключення до Інтернету, а потім подає їм відповідну версію відеофайлу. Нічого для встановлення на вашому сайті. Немає плагінів для оновлення. Без хитрого коду.}

_{джерело}

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

HTML5 представив <VIDEO>тег, який вирішив проблему інтеграції відображуваного відео в браузер при використанні JavaScript та CSS. Попередній <OBJECT>тег вимагав зовнішнього програмного забезпечення та був погано інтегрований зі сторінкою. Насправді новий тег вимагав, щоб браузер став також і відеоплеєром, хоча ніяких стандартів не встановлювали. Результатом стала тотальна фрагментація стандартів, єдиним рішенням якої є те, що відеосервер надасть декілька відеоформатів і всі ці альтернативні джерела будуть вказані в <VIDEO>тезі, з якого браузер вибере той, який він підтримує.

Приклад тегу з кількома джерелами:

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

Сам <VIDEO>тег є протокольно-агностичним, тому може використовувати будь-який протокол, підтримуваний браузером, включаючи RTSP. Підтримка протоколу MPEG-DASH (Dynamic Adaptive Streaming over HTTP) останнім часом стала дуже всеосяжною, тому вона відтворюватиметься на більшості пристроїв та браузерів, або на HTML5, що означає, що додаткові плагіни не потрібні. Дивіться цю схему сумісності пристроїв та веб-переглядачів . Дивіться також цю статтю Mozilla щодо підготовки вашого сервера до обслуговування MPEG-DASH. DASH працює через HTTP, тому це буде працювати до тих пір, поки ваш HTTP-сервер підтримує запити байтового діапазону і налаштований на обслуговування .mpd-файлів mimetype="application/dash+xml".

Нормальна взаємодія між клієнтом і сервером виглядає наступним чином. Для HTML5 VIDEO браузер також є програвачем, хоча він може відкрити нове з'єднання для відтворення.

Початкове з'єднання надає метадані, які клієнт використовує для відображення відео. Якщо для отримання цих метаданих використовувався протокол RTSP, пізніше створюється RTP-з'єднання для передачі відео + аудіоданих. Протокол RTCP використовується для передачі додаткових команд серверу.

RTP, RTCP і RTSP працюють на різних портах. Зазвичай, коли RTP знаходиться на порту N, RTCP знаходиться на порту N + 1. Сеанс RTP може містити кілька потоків, які потрібно об'єднати в кінці приймача; наприклад, аудіо та відео можуть бути на окремих каналах.

Щоб ніхто не заблокував ваш вміст, вам слід зробити доступними як кодеки, безоплатні роялті, webM чи Theora, так і відео H.264, а також аудіо Vorbis та MP3. (Легко сказати, важко зробити.)

Ось що детально відбувається для RTSP:

1. Клієнт встановлює TCP-з'єднання з серверами, як правило, на TCP-порту 554, відомому порту для RTSP.

2. Потім клієнт розпочне випуск серії команд RTSP-заголовків, що мають формат аналогічний HTTP, кожна з яких підтверджена сервером. У межах цих команд RTSP клієнт опише на сервері деталі вимог сеансу, такі як версія RTSP, яку він підтримує, транспорт, який буде використовуватися для потоку даних, та будь-яку пов’язану інформацію про порт UDP або TCP. Ця інформація передається за допомогою заголовків DESCRIBE та SETUP і доповнюється у відповідь сервера за допомогою ідентифікатора сесії, який клієнт та будь-які перехідні проксі-пристрої можуть використовувати для ідентифікації потоку в подальших обмінах.

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

4. Після того, як клієнт вирішить закрити потік, команда TEARDOWN видається разом з ідентифікатором сесії, що вказує серверу припинити доставку RTP, пов'язану з цим ідентифікатором.

Подальше читання :

• Основи потокових протоколів
• Розуміння протоколів шару додатків - протокол потокового потоку в реальному часі (RTSP)
• Вступ до HTML5 Video (Opera)
• Аудіо та відео HTML5: Що потрібно знати
• RTSP аналіз Wireshark

Ось швидка та брудна відповідь.

Існує різниця між відтворенням відео в Інтернеті і фактичним його трансляцією в режимі реального часу.

Відтворення здійснюється за допомогою програвача, який знаходиться на веб-сторінці (можливо, використовує Flash, JS або відео-об’єкт html5). Клієнт (браузер) завантажує цей плеєр і запускає його. Програвач, у свою чергу, отримує відео з простої URL-адреси завантаження. Насправді навіть у Youtube є програми, які дозволяють вам безпосередньо отримувати доступ до розміщених відеофайлів та завантажувати їх, як і будь-який файл. Оскільки система використовує звичайне старе посилання для завантаження, немає необхідності в складних протоколах потокової передачі, таких як RTSP

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