Потоковое воспроизведение в реальном времени в HTML5 (без использования webrtc) с помощью видеотега

Я хотел бы скопировать данные в режиме реального времени в webm или ogv и отправить их в браузер html5.

Может ли webm или ogv сделать это, Mp4 не может этого сделать из-за его атомов MDAT. (невозможно обернуть h264 и mp3 в реальном времени и обернуть его и отправить его клиенту) Скажем, я загружаю вход с веб-камеры и аудио из встроенного микрофона. Фрагментированный mp4 может справиться с этим, но его хлопот, чтобы найти libs для этого).

Мне нужно сделать это, потому что я не хочу отправлять аудио и видео отдельно.

Если я действительно отправляю его отдельно, отправляя аудио по тегу аудио и видео по видео > (аудио и видео демультиплексируются и отправляются) Могу ли я синхронизировать их с клиентским браузером с помощью javascript. Я видел несколько примеров, но пока не уверен.

Ответ 1

Эврен,

Поскольку вы задали этот вопрос на начальном этапе, расширения источников мультимедиа https://www.w3.org/TR/media-source/ созревают, чтобы иметь возможность играть очень короткие (30 мс) сегменты ISO/BMP видео /mp 4 с небольшой буферизацией.

См. потоковая передача HTML5

Итак, ваше утверждение

(нельзя обматывать h264 и mp3 в реальном времени и обернуть его и отправить его клиенту)

устарело. Да, вы можете сделать это с помощью h264 + AAC.

Существует несколько реализаций; взгляните на Unreal Media Server. Часто задаваемые вопросы от Unreal Media Server: http://umediaserver.net/umediaserver/faq.html

Как нереальная потоковая передача HTML5 отличается от MPEG-DASH?В отличие от MPEG-DASH, Unreal Media Server использует протокол WebSocket для прямой трансляции в элемент HTML5 MSE в веб-браузерах. Это намного эффективнее, чем выборка сегментов через HTTP-запросы на MPEG-DASH. Кроме того, Unreal Media Server отправляет сегменты минимальной продолжительности, как минимум 30 мс. Это обеспечивает низкую, субсекундную поточную передачу, в то время как MPEG-DASH, как и другие потоковые потоковые протоколы на основе HTTP, не может обеспечить прямую трансляцию с низкой задержкой.

В их демонстрационной веб-странице есть живой канал HTML5 с камеры RTSP: http://umediaserver.net/umediaserver/demos.html Обратите внимание, что задержка в проигрывателе HTML5 сопоставима с задержкой в Flash-проигрывателе.

Ответ 2

Я сделал это с ffmpeg/ffserver, работающим на Ubuntu, как показано ниже для webm (mp4 и ogg немного проще и должны работать аналогичным образом с одного и того же сервера, но вы должны использовать все 3 формата для совместимости в браузерах).

Во-первых, создайте ffmpeg из источника, чтобы включить драйверы libvpx (даже если вы используете версию, имеющую его, вам нужны новейшие (начиная с этого месяца) потоковое webm, потому что они просто добавили функциональность, чтобы включить глобальные заголовки). Я сделал это на сервере Ubuntu и на рабочем столе, а это руководство показал мне, как - инструкции для других ОС можно найти здесь.

Как только вы получите подходящую версию ffmpeg/ffserver, вы можете настроить их для потоковой передачи, в моем случае это было сделано следующим образом.

На устройстве захвата видео:

ffmpeg -f video4linux2 -standard ntsc -i /dev/video0 http://<server_ip>:8090/0.ffm

Часть "-f video4linux2 -standard ntsc -i/dev/video0" может изменяться в зависимости от вашего источника входного сигнала (моя предназначена для карты видеозахвата).

Соответствующий отрывок ffserver.conf:

Port 8090
#BindAddress <server_ip>
MaxHTTPConnections 2000
MAXClients 100
MaxBandwidth 1000000
CustomLog /var/log/ffserver
NoDaemon

<Feed 0.ffm>
File /tmp/0.ffm
FileMaxSize 5M
ACL allow <feeder_ip>
</Feed>
<Feed 0_webm.ffm>
File /tmp/0_webm.ffm
FileMaxSize 5M
ACL allow localhost
</Feed>

<Stream 0.mpg>
Feed 0.ffm
Format mpeg1video
NoAudio
VideoFrameRate 25
VideoBitRate 256
VideoSize cif
VideoBufferSize 40
VideoGopSize 12
</Stream>
<Stream 0.webm>
Feed 0_webm.ffm
Format webm
NoAudio
VideoCodec libvpx
VideoSize 320x240
VideoFrameRate 24
AVOptionVideo flags +global_header
AVOptionVideo cpu-used 0
AVOptionVideo qmin 1
AVOptionVideo qmax 31
AVOptionVideo quality good
PreRoll 0
StartSendOnKey
VideoBitRate 500K
</Stream>

<Stream index.html>
Format status
ACL allow <client_low_ip> <client_high_ip>
</Stream>

Примечание. Это настроено для сервера в файле feeder_ip для выполнения вышеупомянутой команды ffmpeg и для сервера на сервере server, поэтому сервер для client_low_ip через client_high_ip при обработке mpeg для сеанса webm на server_ip (продолжение ниже).

Эта команда ffmpeg выполняется на машине, ранее упоминавшейся как server_ip (она обрабатывает фактическое преобразование веб-конверсии mpeg → и возвращает ее обратно в ffserver на другом канале):

ffmpeg -i http://<server_ip>:8090/0.mpg -vcodec libvpx http://localhost:8090/0_webm.ffm

После того, как все они были запущены (сначала ffserver, затем процесс feeder_ip ffmpeg, затем процесс server_ip ffmpeg), вы должны иметь доступ к текущему потоку по адресу http://: 8090/0.webm и проверить статус в http://: 8090/

Надеюсь, что это поможет.

Ответ 3

Я использую сервер Stream-m для ретрансляции web-потоков на клиентские HTML-теги HTML5. https://github.com/yomguy/stream-m

Хорошо работает в производстве. Приветствия

EDIT: обратите внимание, что IceCast теперь также может передавать WebM из коробки;)

Ответ 4

Не уверен, что 100% вы можете это сделать. HTML5 не ратифицировал какой-либо механизм трансляции в реальном времени. Вы можете использовать веб-порты и отправлять данные в режиме реального времени в браузер, чтобы сделать это. Но вы должны сами писать логику разбора, и я не знаю, как вы будете передавать данные по мере поступления на плеер.

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