Прямая трансляция видео с RTSP в MJPEG без дополнительных плагинов и проигрывателей на стороне клиента
Invite pending
Как можно было заметить, на рынке IP-камер произошли довольно крупные изменения, а именно массовый уход производителей с MJPEG в сторону RTSP. Камеры, вещающие свои данные по протоколу RTP, стоят дешевле. Это был основной критерий руководства для перехода на использование таких видеокамер.
Задача, поставленная перед отделом разработки была следующая:
Вы спросите: а как же звук и дуплексная связь? Эти амбиции были заложены для следующего этапа разработки. То есть задача ставилась так, что бы можно было спокойно закупать и продавать новое оборудование и попутно пилить новый upgrade для мобильных клиентов (как многим известно, upgrad'ы в том же App Store могут занимать длительно время).
Погуглив, выяснили, что задача не нова и кишит решениями, но на наш взгляд не очень изящными (в контексте нашего сервиса, в котором на сервере крутиться Apache и клиенты общаются с сервером посредством POST запросов). Большинство решений заключаются в использование ffmpeg и какого нибудь web-сервера, например того же ffserver и так далее. Изучив вывод ffmpeg'а (просто выведя его stdout в обычный файл), появился вопрос — зачем такие сложности? И было решено просто вывести stdout ffmpeg'а запросившему его клиенту примерно таким образом:
В итоге немного допилив код на сервере, мы решили поставленную задачу и можно спокойно заняться разработкой нормальной дуплексной связью между клиентами и сервером по RTSP.
Следует отметить, что конвертировать можно не только в mjpeg но и тот же flv и другие допустимые форматы с использованием соответствующих кодеков, управляя fps, битрейтом и другими плюшками подробно описанные на официальном сайте ffmpeg.
Надеюсь, эта статья будет полезной для тех, кто столкнется с подобного рода задачей.
Задача, поставленная перед отделом разработки была следующая:
- В кратчайшие сроки имплементировать новые RTSP-видеокамеры в систему, работающую с MJPEG (браузерные клиенты, а также мобильные клиенты на Android и IOS).
- Обеспечить обратную совместимость, то есть видеокамеры с MJPEG (которые уже установлены на объектах) должны тоже поддерживаться.
- Переезд должен осуществляться с наименьшими трудозатратами.
Вы спросите: а как же звук и дуплексная связь? Эти амбиции были заложены для следующего этапа разработки. То есть задача ставилась так, что бы можно было спокойно закупать и продавать новое оборудование и попутно пилить новый upgrade для мобильных клиентов (как многим известно, upgrad'ы в том же App Store могут занимать длительно время).
Погуглив, выяснили, что задача не нова и кишит решениями, но на наш взгляд не очень изящными (в контексте нашего сервиса, в котором на сервере крутиться Apache и клиенты общаются с сервером посредством POST запросов). Большинство решений заключаются в использование ffmpeg и какого нибудь web-сервера, например того же ffserver и так далее. Изучив вывод ffmpeg'а (просто выведя его stdout в обычный файл), появился вопрос — зачем такие сложности? И было решено просто вывести stdout ffmpeg'а запросившему его клиенту примерно таким образом:
<?php
if (isset($_REQUEST["get"])){
Header('Accept-Ranges:bytes');
Header('Connection:keep-alive');
Header('Content-type: multipart/x-mixed-replace;boundary=ffserver');
passthru('ffmpeg -i "rtsp://admin:password@192.168.0.118:554/videoMain" -qscale 2 -r 23 -b:v 2048k -crf 50 -s 640x480 -f mpjpeg pipe:');
}
?>
<html>
<head>
<title>RTSP to MJPEG</title>
</head>
<body>
<img src="rtsp2mjpeg.php?get=1" width="640" height="480" />
</body>
</html>
В итоге немного допилив код на сервере, мы решили поставленную задачу и можно спокойно заняться разработкой нормальной дуплексной связью между клиентами и сервером по RTSP.
Следует отметить, что конвертировать можно не только в mjpeg но и тот же flv и другие допустимые форматы с использованием соответствующих кодеков, управляя fps, битрейтом и другими плюшками подробно описанные на официальном сайте ffmpeg.
Надеюсь, эта статья будет полезной для тех, кто столкнется с подобного рода задачей.