Базовая концепция видео в прямом эфире

Question

Я - любительский разработчик C++, который интересуется концепцией потокового видео в реальном времени на другом компьютере.

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

Путь я понимаю, жить-потоковое это:

1. Сервер устанавливает сервер UDP (будет легче всего ощутить его сообщение на основе вместо постоянной связи) (я знаю, что есть много других причин почему потоковая передача будет использовать UDP, но синтаксический анализ действительно является моей слабостью)

   2. Сервер считывает кодированные видеоданные (им не известно, как быстро он отправляется, например, 1 кадр данных , и т. д.)
   3. Сервер отправляет Клиенту
   4. Клиент получает видео и декодирует
   5. Клиент отображает видео пользователю.

Это основная идея? Или есть еще. Я хотел прикрепить камеру к малине pi и просто показать живой канал в веб-браузере (который, я полагаю, должен был бы узнать rstp)

Answer 1

Во-первых, вам нужно захватить видео с помощью API, такого как Directshow, AVFoundation , или v4l, в зависимости от вашей платформы.

Далее вам нужно использовать кодек для преобразования необработанных кадров в то, что вы действительно можете отправить через практическую сеть. Необработанные видеоданные огромны, поэтому для сжатия этих данных необходим кодек. На базовом уровне кодеки будут дедуплироваться между кадрами, так что все, что не меняется, не будет отправлено для каждого кадра. Кодеки гораздо более продвинуты, чем это, хотя, используя методы, основанные на том, что мы действительно воспринимаем (например, приоритет изменения яркости по сравнению с изменениями цвета), чтобы уменьшить объем данных, которые необходимо отправить. Вам не нужно писать кодек ... такая задача не является небольшой задачей и очень сложна. Есть много существующих кодеков на выбор. Выбор платформы и ее совместимость обычно дают вам вариант или два.

Теперь вам нужен транспортный протокол. Большая часть потокового видео на самом деле выполняется через TCP, обеспечивая прочный не сбойный поток. (UDP-пакеты все время переупорядочиваются и могут быть легко потеряны.) Приложения реального времени, такие как видеоконференции, часто используют UDP, поскольку задержка там имеет значение гораздо больше, чем поток качества. Приемлемо отбрасывать кадры и иметь случайный сбой в реальном времени. Недопустимо иметь такие глюки в кино, например, или даже в однонаправленных потоках, где латентность не имеет большого значения.

Используемый протокол приложения обычно определяет, используете ли вы TCP или UDP. RTSP является вариантом, и есть много других. Однако, если вы хотите просмотреть поток в браузере, вам понадобится RTMP с Flash, WebRTC или HTTP-протоколом, например, с прогрессивным прогрессивным HTTP, DASH или HLS.

DASH и HLS представляют собой формы сегментированной потоковой передачи, которые обычно реализуются путем записи нескольких секунд и записи статических файлов на диск, где они обслуживаются обычным HTTP-сервером. Файл манифеста или списка воспроизведения используется для указания клиенту, где находятся все эти файлы. (Вы можете использовать те же ресурсы непосредственно из своего приложения, если хотите.)

WebRTC предназначен для потоковой передачи данных и медиапотоков между двумя клиентами, подключенными одноранговым способом. Можно создать сервер, который действует как один из этих клиентов. Я не знаю какого-либо открытого исходного кода для этого, чтобы вы могли отправлять медиапотоки. Но это было сделано коммерчески.

HTTP progressive - это то, где вы просто передаете результат клиенту. Не все форматы могут транслироваться таким образом. MJPEG может работать таким образом. (MJPEG обычно используется камерами безопасности, но это низкое качество, но легко реализуется и будет работать как есть в большинстве браузеров.)

Если бы я делал этот проект сегодня, я бы использовал DASH с VP8 или VP9 для видеокодек (в зависимости от совместимости) и Opus для аудио. Вам понадобится DASH.js на странице клиента, чтобы облегчить загрузку сегментов DASH с помощью Media Source Extensions. Это самый совместимый способ получить приличный качественный поток.