Потоковое мультимедиа из HTML-страниц, на примере

Так что я - инженер-программист, пытающийся понять некоторые мелкие детали о том, как работает потоковая передача мультимедиа. Я потратил львиную долю дня, пытаясь понять различные кодеки, форматы контейнеров и потоковые протоколы, которые имеют отношение к моему приложению. Итак, вот мое понимание того, как это работает, что вполне может ввести в заблуждение:

• Потоковое мультимедиа действительно сводится к формату контейнера и протоколу потоковой передачи :
  • Все аудиоданные кодируются (через аудиокодек) в аудиопоток
  • Все видеоданные закодированы (опять же через кодек) в видеопоток
  • Два потока объединяются ( мультиплексируются? ) Вместе в контейнер, который в конечном итоге становится файлом (таким как MP4 и т. Д.)
  • Затем специальный медиасервер передает этот контейнер (файл MP4 или другой формат) клиенту (возможно, проигрывателю HTML5 Video, работающему внутри чьего-либо браузера) через некоторый стандартный потоковый протокол, такой как RTSP
    • В случае клиента браузера, я предполагаю, что в самом браузере есть клиент RTSP, который затем каким-то образом представляет пользователям HTML5 Video Player
• Я мог бы разместить файл MP4 с веб- сервера, такого как nginx или httpd, но, поскольку эти серверы не являются серверами RTSP, я мог бы обрабатывать только запросы MP4 как запросы на загрузку и, следовательно, не мог бы выполнять потоковую передачу. медиа файлы
  • Аналогично, если бы я использовал curlдля извлечения файлов с сервера nginx, поскольку ни curlnginx, ни RTSP не говорят на RTSP, это будет рассматриваться как загрузка файла
• Но когда я размещаю файл MP4 с сервера потокового мультимедиа (VideoLAN, Red5, Wowza и т. Д.), И я использую RTSP-клиент (или любой поддерживаемый клиент потокового мультимедиа) для запроса потока с этого сервера, то тогда и только затем делает любое фактическое потоковое происходит
  • Следовательно, даже несмотря на то, что «видео» YouTube или Vimeo размещаются на страницах HTML, обслуживаемых через HTTP (S) HTTP-серверами, я предполагаю, что встроенные проигрыватели видео на этих страницах (с которых видео действительно воспроизводятся) фактически начинают второй последующее подключение к потоковому серверу, и потоковая передача происходит по протоколу RTSP или некоторому другому не HTTP-протоколу

Так что это мое понимание, и я полагаю, что сначала спрошу, что если что-то, что я изложил выше, неверно, пожалуйста, начните исправлять меня! Предполагая, что я более или менее прав:

Как проигрыватели потокового мультимедиа, работающие внутри страниц HTML и обслуживаемые серверами HTML, устанавливают потоковые (RTSP и т. Д.) Соединения с серверами потокового мультимедиа (обслуживающими запросы RTSP)?

Как проигрыватели потокового мультимедиа, работающие внутри страниц HTML и обслуживаемые серверами HTML, устанавливают потоковые (RTSP и т. Д.) Соединения с серверами потокового мультимедиа (обслуживающими запросы RTSP)?

Общие приложения

RTSP в настоящее время, кажется, больше используется с интерфейсами приложений / устройств, которые непосредственно транслируют (например, IP-камера) или повторно (как движок), чем для потоковой передачи сохраненных медиафайлов из физического местоположения через интерфейс веб-воспроизведения HTTP с встроенный плеер

Кажется, что RTSP является протоколом с отслеживанием состояния , и он использует UDP больше, чем TCP при потоковой передаче, и он больше используется в качестве серверного устройства (например, IP-камеры), который подключен к сети TCP / IP и передает потоки через UDP и т. Д. Затем вы подключаетесь к этим каналам (серверу) как клиент в той же сети, и вы можете выдавать RTSP-запросы для соответствующего использования.

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

^{Хотя RTSP в некотором смысле похож на HTTP, он определяет управляющие последовательности, полезные для управления воспроизведением мультимедиа. Пока HTTP не имеет состояния , RTSP имеет состояние; идентификатор используется при необходимости для отслеживания одновременных сеансов. Как и HTTP, RTSP использует TCP для поддержания сквозного соединения, и, хотя большинство управляющих сообщений RTSP отправляются клиентом на сервер, некоторые команды передаются в другом направлении (то есть от сервера к клиенту).}

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

^{_{источник}}

^Stateless

^{Протокол без сохранения состояния не требует, чтобы сервер сохранял информацию о сеансе или статус о каждом коммуникационном партнере в течение нескольких запросов. В отличие от этого, протокол, который требует сохранения внутреннего состояния на сервере, называется состоянием .}

^{Недостаток безгражданства заключается в том, что может потребоваться включение дополнительной информации в каждый запрос, и эта дополнительная информация должна будет интерпретироваться сервером.}

^{_{источник}}

Логический поток

Как я понимаю поток потокового мультимедиа в этой форме:

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

Пожалуйста, ознакомьтесь с разделом « Технологии потоковой передачи» ниже для общего сравнения HTTP и RTSP.

более того

В приведенных ниже 10 причинах, почему вы никогда не должны размещать свои собственные видео », я процитировал части, которые помогут вам ответить на ваш вопрос «в общих чертах», не будучи слишком конкретными.

По сути, это говорит о том, что веб-сайт, который имеет встроенные элементы управления медиаплеером, будет:

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

^{Потоковые технологии}

^{Клиентский браузер должен получить данные с сервера и передать их потоковому приложению для обработки. Потоковое приложение преобразует данные в изображения и звуки. Важным фактором успеха этого процесса является способность клиента быстрее получать данные, чтобы приложение могло отображать информацию. Избыточные данные хранятся в буфере - области памяти, зарезервированной для хранения данных в приложении. Если данные задерживаются при передаче между двумя системами, буфер очищается, и представление материала не будет гладким.}

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

^{HTTP является основным способом связи документов в Интернете. Клиент устанавливает соединение с сервером, содержащим файл для потоковой передачи, файл извлекается и соединение закрывается. HTTP-сервер сообщает браузеру тип файла для передачи.}

^{Преимущества использования HTTP}

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

^{Некоторые недостатки}

^{Для потоковой передачи HTTP используется протокол TCP / IP (протокол управления передачей и Интернет-протокол). Этот процесс проверяет отсутствующие пакеты и запрашивает их повторную передачу. Это становится проблематичным в сценарии потоковой передачи, когда вы хотите, чтобы данные игнорировались, если они теряются при доставке, поэтому динамические файлы продолжают воспроизводиться. HTTP не может определить скорость модема, поэтому администраторы сервера должны целенаправленно создавать файлы с разными степенями сжатия для пользователей серверов с разными типами соединений. Потоковая передача файлов с HTTP-серверов не рекомендуется в ситуациях с высокими требованиями.}

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

^{RTSP - это стандартный протокол, используемый большинством поставщиков потоковых серверов. Серверы RTSP используют UDP (протокол пользовательских дейтаграмм) для передачи мультимедийных файлов. 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 кбит / с).}

^{Но вы также захотите закодировать меньшую версию с меньшим разрешением для доставки на мобильные устройства, такие как телефоны и планшеты, а также для доставки зрителям с более медленными интернет-соединениями.}

^{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 (динамическая адаптивная потоковая передача по 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 видео (Opera)
• HTML5 аудио и видео: что вы должны знать
• RTSP Анализ Wireshark

Вот быстрый и грязный ответ:

Существует разница между воспроизведением видео в Интернете и его передачей в реальном времени.

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

Потоковое вещание в реальном времени (скажем, с веб-камеры) ... ну, сложнее. Flash имеет эту встроенную функциональность, но ее больше не следует использовать. Видео HTML5 не поддерживает потоковую передачу в реальном времени, но люди смогли «обмануть» его, заставив сервер размещения файлов постоянно изменять предлагаемый им видеофайл.