12

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

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

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

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

|источник

3 ответа3

7

Как проигрыватели потокового мультимедиа, работающие на страницах 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 причин, почему вы никогда не должны размещать свои собственные видео », я процитировал части, которые помогут вам ответить на ваш вопрос "в общих чертах", не будучи слишком конкретными.

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

  • (1) определить клиентские настройки веб-браузера при «соединении и запросе» от клиента и
  • (2) это установит кодек и любые другие параметры обнаружения на стороне клиента в соответствующие значения параметров, а затем
  • (3) он будет транслировать видео непосредственно с сервера потоковой передачи, на котором размещены видео- и аудиофайлы, на основе дополнительного кода в конфигурациях встроенного медиаплеера, указывающего 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.

Встроенный видеоплеер автоматически определяет устройство пользователя, браузер и скорость подключения к Интернету, а затем подает им соответствующую версию видеофайла. Нечего устанавливать на свой сайт. Нет плагинов, чтобы быть в курсе. Нет хитрого кода.

источник

|источник
5

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

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, связанную с этим идентификатором.

Дальнейшее чтение :

|источник
1

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

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

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

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .