Как смотреть RTSP в браузере: 4 способа в 2026 году
Chrome, Firefox, Safari и Edge не умеют открывать rtsp:// ссылки напрямую. Разбираем четыре живых способа показать поток IP-камеры в браузере — с таблицей задержек, требований и реальными примерами кода.
TL;DR — за 60 секунд
Почему не работает. Браузеры понимают только http/https/ws/ftp/mailto. Протокол RTSP не реализован нигде кроме старого IE с ActiveX (который умер в 2022).
Как починить. Нужен промежуточный ретранслятор — он забирает RTSP с камеры и отдаёт в браузер в понятном формате. Четыре варианта: HLS (задержка 5-7 сек, просто), WebRTC (0.3-1 сек, сложно), MJPEG (0.2 сек но жрёт трафик), WebSocket+canvas (низкий latency, кастомно).
Рекомендация 2026 года. Для 90% случаев — HLS через готовый ретранслятор (MediaMTX свой или RTSP.KZ). Для охранных систем где мгновенное реагирование — WebRTC с собственным TURN-сервером.
- Почему браузер не понимает RTSP — техническая причина
- Таблица сравнения 4 способов по 7 параметрам
- Способ 1: HLS — универсальный
- Способ 2: WebRTC — минимальная задержка
- Способ 3: MJPEG — просто, но дорого
- Способ 4: WebSocket + canvas — кастом
- Реальный кейс: корпоративный портал в Шымкенте
- Готовые примеры: <video> + hls.js за 5 минут
- FAQ — 6 вопросов
Почему браузер не понимает RTSP — технически
RTSP (Real Time Streaming Protocol) описан в RFC 2326 в 1998 году. Это управляющий протокол на уровне приложения: клиент отправляет команды DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN. А сам медиа-трафик (видео и аудио) передаётся отдельно — через RTP/RTCP по UDP или TCP.
Браузер — это HTML+CSS+JS+HTTP машина. Поддерживаемые схемы URL определяются в стандарте WHATWG URL Standard и фактически сводятся к семи: http, https, ws, wss, ftp, file, mailto. Браузер не умеет ни устанавливать TCP-соединение на произвольный порт (554), ни парсить RTP-пакеты, ни декодировать H.264 из сырого потока.
Что умел старый IE? До 2015 поддерживал RTSP через плагин-обёртку ActiveX (VLC Plugin, QuickTime). Chrome до версии 45 поддерживал NPAPI-плагины. Всё это убрано ради безопасности: плагины были главным источником уязвимостей. С 2022 даже Internet Explorer не запустить без хаков — Microsoft удалила его из Windows.
Вывод: в 2026 единственный путь показать RTSP в браузере — конвертировать поток в один из четырёх форматов, которые браузер понимает нативно. Ниже разбираем каждый способ с примерами и ограничениями.
Сравнение 4 способов — таблица
| Параметр | HLS | WebRTC | MJPEG | WS+canvas |
|---|---|---|---|---|
| Задержка | 5-10 сек (LL-HLS: 2-3) | 0.3-1 сек | 0.2 сек | 0.5-1 сек |
| Трафик (1 Мп камера) | 2-3 Мбит/с | 2-3 Мбит/с | 10-30 Мбит/с | 2-3 Мбит/с |
| Качество | Full HD / 4K | Full HD / 4K | Ограничено 1-2 Мп | Full HD |
| Аудио | Да (AAC) | Да (Opus) | Нет | Зависит от реализации |
| Mobile browsers | Все | Все | Все | Все |
| Сложность настройки | ★★☆ | ★★★ | ★☆☆ | ★★★ |
| Готовые решения | MediaMTX, Wowza, RTSP.KZ | MediaMTX, Janus, Kurento | Встроено в камеру | jsmpeg, Broadway.js |
Короткий ответ. В 9 случаях из 10 используйте HLS через готовый ретранслятор — это баланс простоты, совместимости и качества. WebRTC — когда критична минимальная задержка (охрана, видеоконсультации). MJPEG — только для очень простых кейсов (1-2 камеры, внутренняя сеть). WebSocket+canvas — для кастомных реализаций с низкой задержкой на слабых устройствах.
Способ 1: HLS — универсальный, просто, везде работает
HLS (HTTP Live Streaming)
Принцип: ретранслятор забирает RTSP-поток с камеры, нарезает на .ts-сегменты по 2-10 секунд и публикует .m3u8-манифест. Браузер скачивает манифест, потом сегменты по одному, склеивает и играет через <video>-тег.
Плюсы: работает в любом браузере (Safari нативно, Chrome/Firefox через hls.js), проходит через корпоративные firewall (обычный HTTPS), хорошо масштабируется через CDN, Apple выдавила ActiveX именно этим стандартом.
Минусы: задержка 5-10 секунд из-за буферизации сегментов. LL-HLS снижает до 2-3 сек, но требует iOS 14+ или hls.js с правильной конфигурацией.
Готовые инструменты:
Способ 2: WebRTC — минимальная задержка, сложная настройка
WebRTC (Web Real-Time Communication)
Принцип: клиент и сервер устанавливают P2P-соединение через STUN/TURN для обхода NAT. Сервер шлёт медиа-пакеты напрямую в WebRTC PeerConnection. Видео декодирует браузер через встроенный H.264/VP8/VP9/AV1.
Плюсы: задержка на уровне локального WebRTC — 300-500 мс, в идеальной сети меньше 200 мс. Шифрование DTLS-SRTP встроено. Работает через NAT благодаря ICE/STUN/TURN.
Минусы: сложная архитектура — нужен signaling сервер + STUN (бесплатно, stun.l.google.com:19302) + TURN (платно, если клиенты за симметричным NAT). Настройка требует экспертизы, 80% бюджета WebRTC-проектов уходит на отладку NAT-traversal.
Когда брать. Только если нужна задержка меньше 2 сек: видеозвонки с камеры, охрана с реагированием, интерактивные системы.
Готовые инструменты:
- MediaMTX (WebRTC встроен с версии 1.0)
- Janus Gateway
- Kurento Media Server
- Pion WebRTC (Go library)
Способ 3: MJPEG — просто, но трафик конский
MJPEG (Motion JPEG)
Принцип: камера отдаёт не H.264-поток, а последовательность JPEG-картинок с частотой 15-25 fps. Браузер показывает их через тег <img src="http://camera/mjpeg"> — автоматически обновляется.
Плюсы: не нужен никакой ретранслятор, если камера умеет MJPEG напрямую (большинство Hikvision, Dahua, Axis умеют — через /ISAPI/Streaming/channels/101/httpPreview, /mjpg/video.mjpg, /axis-cgi/mjpg/video.cgi). Работает в браузере вообще без JS.
Минусы: катастрофический трафик. JPEG не использует inter-frame compression, каждый кадр — отдельное фото. Full HD MJPEG = 15-30 Мбит/с против 2-4 у H.264. Нет аудио. Нет синхронизации кадров, дёргается при задержках сети.
Когда использовать. Для внутренней сети с парой камер. Для preview-картинки в админке. Для Raspberry Pi где нет ресурсов на H.264-транскодирование.
<!-- Простейшая встройка MJPEG в HTML --> <img src="http://192.168.1.64:80/ISAPI/Streaming/channels/101/httpPreview?auth=YWRtaW46cGFzc3dvcmQ=" alt="camera preview">
Способ 4: WebSocket + canvas — кастомный low-latency
WebSocket + JS-декодер (jsmpeg, Broadway, WebCodecs API)
Принцип: сервер шлёт H.264-пакеты через WebSocket, клиент декодирует JavaScript-библиотекой (jsmpeg для MPEG-TS, Broadway для H.264) и рисует на <canvas>. Новое API WebCodecs (Chrome 94+) позволяет использовать аппаратный декодер напрямую.
Плюсы: контроль над каждым байтом, задержка меньше 1 секунды без WebRTC-монстра. WebCodecs даёт близко к нативной производительности.
Минусы: нужно писать свой сервер и клиент. jsmpeg поддерживает только MPEG-TS (большой overhead). Broadway — программный декодер H.264, ест CPU. WebCodecs пока только в Chrome.
Для большинства проектов overkill. Рассматривайте если хотите свой видеоплеер с какой-то спецификой (overlay, ROI, multi-view).
Корпоративный портал в Шымкенте: 12 камер × 50 сотрудников
Задача. Производственное предприятие в Шымкенте (химическая отрасль, СЭЗ «Оңтүстік»). 12 камер Dahua IPC-HFW2431 в цехах. Нужен внутренний портал где 50 сотрудников (руководство, диспетчеры, ОТБ) могут смотреть камеры. Цель: нагруженность цехов, безопасность, соответствие GMP-требованиям.
Что тестировали:
- MJPEG напрямую с камеры. Работает, но 12 камер × 50 зрителей = 600 MJPEG-потоков × 20 Мбит/с = 12 Гбит/с. Камеры Dahua не тянут больше 10 MJPEG-клиентов одновременно.
- WebRTC через Janus. Задержка 0.5 сек, красота. Но настройка TURN за 2 недели, не нашли Java-разработчика в Шымкенте.
- HLS через MediaMTX. MediaMTX на внутреннем Linux-сервере, конфиг на 50 строк. Задержка 4-6 сек. На ретранслятор достаточно 8 Мбит/с (по одному потоку с камеры), клиенты смотрят кэшированные сегменты с внутреннего сервера — 0 нагрузка на камеры.
Выбор. HLS + MediaMTX. Портал на Nuxt.js с hls.js, 12 окошек на сетке. Задержка 4-6 сек для наблюдения за производством — приемлемо.
Итого. Сервер 80 000 ₸ единоразово, MediaMTX и инфра бесплатно (open source), настройка 3 дня. Годовая стоимость владения — 0 ₸ на софт, только электричество и админ.
Готовый код: встроить RTSP-камеру на ваш сайт за 5 минут
Сценарий: у вас есть HLS-ссылка от RTSP.KZ (https://rtsp.kz/hls/mycamera/index.m3u8) или собственного MediaMTX. Вставить на сайт:
Вариант А: только Safari iOS и desktop
<!-- Safari iOS, macOS Safari — поддерживают HLS нативно --> <video src="https://rtsp.kz/hls/mycamera/index.m3u8" controls autoplay muted playsinline style="width:100%;max-width:800px"></video>
Вариант Б: универсальный (Chrome, Firefox, Edge, Safari)
<video id="cam" controls autoplay muted playsinline></video> <script src="https://cdn.jsdelivr.net/npm/hls.js@1"></script> <script> const url = "https://rtsp.kz/hls/mycamera/index.m3u8"; const video = document.getElementById("cam"); // Safari — нативный HLS if (video.canPlayType("application/vnd.apple.mpegurl")) { video.src = url; } // остальные — через hls.js else if (Hls.isSupported()) { const hls = new Hls({ liveSyncDurationCount: 1 }); hls.loadSource(url); hls.attachMedia(video); } </script>
Этого кода достаточно для большинства случаев. Без hls.js работает только в Safari. С hls.js — везде.
Для WebRTC (продвинутый)
Если хотите задержку 0.5 сек, подключайтесь к WebRTC-endpoint MediaMTX или используйте whip/whep SDK:
// MediaMTX встроенный плеер (работает из коробки) <iframe src="https://your-mediamtx:8889/mycamera" width="800" height="450" allow="autoplay"></iframe>
Не хотите возиться со своим сервером?
RTSP.KZ берёт всё на себя: HLS + WebRTC из коробки, HTTPS-ссылки для embed, работает у всех провайдеров KZ. 1 час бесплатно без регистрации.
Попробовать →FAQ — 6 вопросов о RTSP в браузере
Браузеры Chrome, Firefox, Safari, Edge понимают только схемы http, https, ws, wss, ftp, mailto. RTSP — отдельный протокол (RFC 2326), он не реализован в современных браузерах. IE/Chrome до 2015 поддерживали RTSP через плагины ActiveX/NPAPI, но с уходом Flash и плагинов единственный способ — конвертация в HLS или WebRTC.
Для публичной трансляции где задержка 5-7 сек нормальна — HLS (проще, работает везде). Для охранных систем, видеозвонков и онлайн-наблюдения с реагированием — WebRTC (задержка 0.3-1 сек, но сложнее настройка, нужен TURN-сервер). MJPEG устарел, большой трафик.
Напрямую — нет. Safari имеет нативную поддержку HLS в теге <video>: можно вставить <video src="stream.m3u8" autoplay muted playsinline></video>. iOS 14+ поддерживает LL-HLS с задержкой 2-3 сек. В Chrome/Firefox для iOS нужна hls.js.
Да. Браузер не получает RTSP напрямую от камеры. Нужен ретранслятор: забирает RTSP и отдаёт в браузер в формате HLS/WebRTC/MJPEG. Готовые: MediaMTX (open-source, бесплатно), Wowza ($125/мес), Nimble, RTSP.KZ. Свой сервер — VPS 2 000-4 000 ₸/мес + настройка.
Без транскодирования (pass-through) на 1 vCPU — 5-10 FHD-потоков. Узкое место — сеть: 4 Мбит/с × 10 клиентов = 40 Мбит/с uplink для одной камеры. При 10 камерах с 10 зрителями нужен канал 400 Мбит/с. Масштабное решение — WebRTC SFU или CDN для HLS.
Получите HLS-ссылку от RTSP.KZ (https://rtsp.kz/hls/myroom/index.m3u8), добавьте на страницу <video src="..." controls playsinline autoplay muted> и подключите hls.js для Chrome/Firefox. Код — 10 строк. Задержка 5-7 сек. Для 0.5 сек — WebRTC через iframe MediaMTX.