LINUX.ORG.RU

Потоковое видео в реальном времени с помощью вебсокетов

 , , ,


0

3

Итак, задача: с N видеокамер покадрово снимается при помощи ffmpeg видеопоток и обрабатывается. В циклическом буфере в разделяемой памяти эти картинки постоянно висят (а также туда складывается дополнительная информация + индекс последнего сохраненного изображения). Нужно клиенту (firefox) вывести в веб-странице это видео со скоростью, которую позволяет канал.

Как это делалось раньше: CGI посылал jpeg'и с разделителем, которые отображались в <img>, обновляемом по таймеру. Это было не очень хорошо + требовало постоянно перезагружать веб-страничку (т.к. браузеры до сих пор текут!).

Хочется: отображать видео, которое не будет приводить к утечке памяти в браузере. Но не представляю, как это реализовать.

Клиент постоянно соединен с сервером через вебсокет (по нему идут асинхронные команды и ответы сервера), т.е. можно писать в вебсокет команду «дай мне следующий кадр» и забирать его как-нибудь.

Но как по-человечески отображать, чтобы не текла память браузера? Если опять передавать jpeg'и (пусть через вебсокет) и в канве их рисовать, то память будет течь (т.к. до сих пор в браузерах не реализовали сборщик мусора).

На ум приходит псевдо-html5-streaming. Но не приходит, как сделать.

Подкиньте идей, пожалуйста.

☆☆☆☆☆

Последнее исправление: CYB3R (всего исправлений: 1)
Ответ на: комментарий от gbg

А где бы пример посмотреть — будет ли оно вообще у меня работать?

// что такое WebRTC, я не знаю

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от dhampire

этот вариант у меня давным-давно навелосипежен

Eddy_Em ☆☆☆☆☆
() автор топика

Еще один все никак не может понять, что программирование — это периодическое окунание себя в лужу с говном.

buddhist ★★★★★
()
Ответ на: комментарий от Eddy_Em

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

Оно вроде как опенсорсное-то есть надо расчехлить поднять и посмотреть.

gbg
()
Ответ на: комментарий от gbg

Мне такое не нужно. Мне нужно нормальное видео в реальном времени на N клиентов (N мало, <256). И у всех рассинхронизация должна быть не больше 100мс.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Надо тесты делать. Потому что RTP, который лежит под WebRTC в принципе позволяет обеспечивать синхронизацию по алгоритмам, аналогичным NTP.

gbg
()

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

Пришлось делать так: сервер кодирует картинку в Base64 и передает клиенту через вебсокет (по запросу следующего кадра). Клиент декодирует и отображает (в src <img> пишется "data:image/jpeg;base64," + полученная картинка в base64). Пока в качестве теста гонял 2 картинки (в цикле) 640x480 пикселей. Получилось около 7 кадров в секунду. Маловато для нормального потокового видео, но для моей задачи (надо 1-2 кадра в секунду максимум) вполне сгодится.

Как-нибудь на досуге попробую с веб-камеры брать картинку. Интересно, какая там скорость получится.

Ну, а в конечном итоге добавлю все сюда. И попытаюсь разбить это на модули, чтобы более-менее универсально получилось (т.е. один демон тупо обрабатывает видео из выбранного источника и помещает вычисленные центры тяжести куда-нибудь в shm; другой демон считывает эти данные и управляет автогидом + по вебсокетам принимает команды + по вебсокетам передает изображения).

Eddy_Em ☆☆☆☆☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.