Потоковая передача в реальном времени на HTML5 (без webrtc) просто с помощью тега video
Я хотел бы обернуть закодированные данные в реальном времени в webm или ogv и отправить их в браузер html5.
Могут ли это сделать webm или ogv,
Mp4 не может этого сделать из-за своих атомов MDAT. (нельзя обернуть h264 и mp3 в реальном времени и обернуть его и отправить клиенту)
Скажем, я подаю вход с моей веб-камеры и аудио с моего встроенного микрофона.
Фрагментированный mp4 может справиться с этим, но его хлопот найти библиотеки, чтобы сделать это).
Мне нужно это сделать, потому что я не хочу отправлять аудио и видео раздельно.
Если я отправил его отдельно, отправив аудио по тегу audio и видео по видео>(аудио и видео демуксируются и отправляются)
Могу ли я синхронизировать их в клиентском браузере с javascript. Я видел несколько примеров, но пока не уверен.
3 ответов:
Эврен,
Поскольку вы задали этот вопрос изначально, расширения источника мультимедиа https://www.w3.org/TR/media-source/ достаточно повзрослели, чтобы иметь возможность воспроизводить очень короткие (30 мс) сегменты ISO-BMFF video/mp4 с небольшой буферизацией.
Итак, ваше утверждение
(нельзя обернуть h264 и mp3 в реальном времени и обернуть его и отправить клиенту)
Теперь устарело. Да вы можете это сделать он с h264 + AAC.
Существует несколько реализаций; взгляните на Unreal Media Server. Из Unreal Media Server FAQ: http://umediaserver.net/umediaserver/faq.html
Чем Unreal HTML5 live streaming отличается от 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.
Я сделал это с 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.выдержка из конф:
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_ip so server для client_low_ip через client_high_ip при обработке диалога mpeg-webm на server_ip (продолжение ниже).
Эта команда ffmpeg выполняется на машине, ранее называвшейся server_ip (она обрабатывает фактическое преобразование mpeg -- > webm и каналы он возвращается в 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/
Надеюсь, это поможет.
Не на 100% уверен, что вы можете это сделать. HTML5 не ратифицировал ни одного механизма потоковой передачи в реальном времени. Для этого можно использовать websockets и отправлять данные в браузер в режиме реального времени. Но вы должны написать логику разбора сами, и я не знаю, как вы будете подавать данные, когда они прибудут к игроку.
Что касается тега video и audio: тег Video может воспроизводить файлы-контейнеры, содержащие как аудио, так и видео. Поэтому заверните содержимое в контейнер, который совместим. Если вы измените свой браузер, чтобы написать свой прямая трансляция в этот видеофайл, поскольку живой контент продолжает поступать и выводить эти данные для каждого байта, запрошенного браузером, это может быть сделано. Но это определенно нетривиально.
Comments