Проблемы трансляции с IP-камеры
Классификация по симптому: frame drops, высокая задержка, артефакты (зелёные квадраты), чёрный экран при правильном соединении. Инструменты диагностики и готовые решения.
TL;DR — за 60 секунд
4 главных симптома. (1) Frame drops (тормозит) — битрейт выше пропускной; (2) Высокая задержка (5+ сек) — TCP буферизация или UDP с потерями и retransmit; (3) Артефакты (зелёные квадраты) — keyframe пропал, или UDP теряет пакеты; (4) Чёрный экран — кодек mismatch, client не декодирует H.265.
Сначала диагностика, потом лечение. VLC → Tools → Codec Information покажет битрейт, FPS, кодек. ffprobe детальнее. Wireshark вскрывает транспорт (TCP retransmissions, UDP loss). Без диагностики лечение — гадание.
Частые путаницы. «Тормозит» может быть и из-за загрузки CPU клиента (не декодирует быстро), и из-за сети. Смотрите загрузку CPU параллельно.
Классификация по симптомам
| Симптом | Где искать | Типичная причина |
|---|---|---|
| Видео тормозит, frame drops | Битрейт vs пропускная способность | Канал не тянет, настройки камеры слишком высокие |
| Задержка 5+ секунд | Буферизация, протокол транспорта | TCP buffering, UDP retransmit, плохой GOP |
| Зелёные квадраты, разваленное | UDP packet loss, keyframe interval | Потеря keyframe, слабая сеть UDP |
| Чёрный экран, звук есть | Codec mismatch | H.265 на клиенте без декодера |
| Нет звука, видео есть | SDP, audio codec | AAC vs G.711, клиент не поддерживает |
| Рассинхрон звука и видео | Timestamps, PTS drift | Проблема с PTS на камере или в ретрансляторе |
| Подключение рвётся каждые 60 сек | Keep-alive, NAT timeout | NAT закрывает idle UDP соединение |
| Пикселизация только на движении | Битрейт на motion | CBR слишком низкий, VBR нужен |
Frame drops — тормозит
Диагностика
В VLC: Tools → Codec Information → вкладка Statistics. Смотрите:
- Displayed frames — сколько реально показали
- Lost frames — сколько пропустили
- Content bitrate — реальный битрейт потока
- Declared bitrate — заявленный в SDP
Если Lost frames > 5% — проблема реальная.
В ffprobe:
ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate,avg_frame_rate,codec_name \ "rtsp://user:pass@IP:554/path"
Причина 1: канал не тянет
Битрейт main stream обычно 4–8 Mbps. Проверьте скорость канала в месте приёма потока:
- Локальная сеть — должно быть 100 Mbps+ легко. Если меньше — ищите кабель, switch, дуплекс.
- Через интернет — проверьте upload камеры (не download!): speedtest.net на камере (если смогли поставить) или на роутере где камера.
- Если upload от камеры меньше битрейта потока — снижайте битрейт или используйте sub stream.
Причина 2: CPU клиента упёрся
H.265 4K декодирование на слабом процессоре (старше 4 ядер, без hardware decode) потребляет 80–100% CPU. Проверьте в Task Manager (Windows) / htop (Linux) — если клиент грузит CPU в 100% и теряет кадры, решения:
- Включить hardware acceleration: VLC → Preferences → Input / Codecs → Hardware-accelerated decoding → Automatic.
- Снизить разрешение: открывать sub stream вместо main.
- Переключить кодек камеры с H.265 на H.264 (H.264 легче декодируется).
Причина 3: WiFi вместо Ethernet
Через WiFi 2.4 ГГц пропускная плавает: 30–50 Mbps в идеале, часто 5–15 Mbps при помехах. 4K камера не влезет. Решения:
- Переведите клиент на Ethernet.
- Или используйте 5 ГГц WiFi (WiFi 5 или WiFi 6).
- Или sub stream (обычно 512 Kbps — 1 Mbps, влезает в любой WiFi).
Задержка 5+ секунд
Нормальная задержка RTSP напрямую — 200–500 мс. Через публичный интернет с буферизацией — 1–2 сек. Если видите 5+ секунд — есть проблема.
Причина 1: TCP с большим буфером
RTSP поверх TCP гарантирует доставку, но из-за этого буферизует пакеты. VLC и многие плееры добавляют свою буферизацию поверх TCP-буфера ОС.
Решения:
- В VLC: Preferences → Input / Codecs → Network caching: 300 ms (по умолчанию 1000 ms). Но ниже 300 ms получите drops.
- FFmpeg:
-fflags nobuffer -flags low_delay -rtsp_transport tcp. - В камере настроить меньший GOP: Setup → Video → I-frame Interval → 25 (при 25 FPS = 1 сек) или даже 12.
Причина 2: UDP с potentry потерями и retransmit
UDP транспорт RTSP по умолчанию, но без гарантии доставки. При потере пакета клиент запрашивает retransmit — добавляется RTT × 2-3.
Если сеть плохая (потери >2%), UDP хуже TCP — постоянные retransmit накапливаются в задержку. Переключите на TCP: rtsp_transport tcp в клиенте или в настройках камеры «Transmission Protocol: TCP».
Причина 3: транскодирование на ретрансляторе
Если между камерой и клиентом стоит ретранслятор, который транскодирует поток (например, RTSP → HLS через FFmpeg), задержка добавляется:
- HLS — по природе 6+ секунд (3 × длина сегмента по 2 сек).
- DASH — 3–6 секунд.
- WebRTC — 100–300 мс, самый быстрый.
- RTMP — 1–2 секунды.
Если нужна real-time (охрана, мониторинг) — используйте WebRTC или прямой RTSP. HLS только для массовой раздачи.
Артефакты и разваленное изображение
Типичное: зелёные квадраты, «плывёт» изображение при движении, половина экрана как будто зависла.
Причина 1: потерялся keyframe
H.264/H.265 работают так: раз в GOP-интервал (обычно 1–2 сек) камера посылает I-frame (полный кадр), между ними — P/B-frames (только разница). Если I-frame потерялся в сети — клиент «залипает» и пытается собрать картинку из P-frames.
Решение:
- Уменьшить GOP: I-frame interval: 25 (при 25 FPS = 1 сек). Чаще keyframes, меньше зависимость от одного.
- Переключиться на TCP транспорт — keyframe не потеряется.
- Увеличить bitrate keyframe в настройках: Setup → Video → Bit Rate → I-frame Rate: 100%.
Причина 2: UDP packet loss
Через плохую сеть UDP теряет 1–5% пакетов. Каждая потеря на уровне RTP bibliotek — дырка в картинке, часто зелёная.
Диагностика: Wireshark → фильтр rtp → Statistics → RTP streams. Покажет lost packets и jitter.
Решение: TCP транспорт или улучшить сеть.
Причина 3: битый кабель или интерференция
Если артефакты только на одной камере из 10 в одной локалке — ищите кабель. Перегибы, окислившиеся разъёмы, кабель рядом с силовыми кабелями 220V → наводки → CRC errors → потери пакетов. Замените кабель на заведомо хороший cat5e или cat6.
Чёрный экран при корректном соединении
VLC показывает «Connected», но картинки нет. Звук иногда есть (если камера его отдаёт).
Причина 1: кодек не поддерживается
Камера H.265, VLC 2.x не умеет декодировать. Обновите VLC до 3.0.18+ или переключите камеру на H.264.
Проверка: Tools → Codec Information → Video codec. Если HEVC / H.265, а вы на старом VLC — проблема ясна.
Причина 2: поток проигрывается, но hardware decode падает
При включённом hardware acceleration через плохо поддержку драйвера может быть чёрный экран. Попробуйте: Preferences → Input / Codecs → Hardware-accelerated decoding → Disable.
Причина 3: ROI / privacy mask
В камере настроена privacy mask, покрывающая весь кадр. Редкий случай, но бывает — кто-то по ошибке замаскировал всю картинку.
Нет звука или рассинхрон
Нет звука
- Камера не поддерживает аудио (да, многие уличные bullet без микрофона).
- Аудио отключено в настройках: Setup → Audio → Enable.
- Клиент не поддерживает кодек камеры. Hikvision по умолчанию G.711 Alaw — универсальный. AAC — не все клиенты играют.
Рассинхрон звук-видео
Корень — разные задержки декодирования video и audio. Частое:
- Через транскодер — каждый путь вносит свою задержку, рассинхрон накапливается.
- На камере PTS (presentation timestamps) некорректные — баг прошивки, обновляйтесь.
- В VLC: Tools → Track Synchronization → Audio track synchronization → сдвиньте вручную.
Инструменты диагностики
VLC Statistics
Tools → Codec Information → вкладка Statistics. Живые метрики: bitrate, lost frames, sent packets.
ffprobe
ffprobe -v error -show_streams -show_format "rtsp://..."
# Детальная инфо потока: кодеки, разрешение, битрейт
ffmpeg -v debug
ffmpeg -v debug -rtsp_transport tcp -i "rtsp://..." -t 10 -f null -
# 10 секунд записи, лог всех RTSP-сообщений
Wireshark
Фильтры:
rtsp— весь RTSP control (DESCRIBE, SETUP, PLAY, TEARDOWN)rtp— RTP data streamtcp.analysis.retransmission— TCP retransmits (плохая сеть)- Statistics → RTP → Stream Analysis — jitter, lost packets, max delta
iperf3 для проверки канала
iperf3 -c server.example.com -p 5201 -t 30 -J
# 30 секунд TCP test, JSON output. Реальная пропускная между вами и сервером.
Магазин в Атырау — задержка 8 секунд на всех камерах
4 Hikvision DS-2CD, NVR, RTSP-трансляция на rtsp.kz. Владелец жалуется: я двигаюсь перед камерой — вижу себя с задержкой 8 секунд в мониторе кассира.
Диагностика: Wireshark показал TCP retransmissions 0%, но RTP jitter 300 ms — что-то буферизует. Открыли VLC Preferences → Network caching: стояло 3000 ms (3 секунды). Плюс HLS на RTSP.KZ добавлял 3 сегмента по 2 сек = 6 сек.
Решение: сменили network caching в VLC на 500 ms, запросили у RTSP.KZ использовать WebRTC вместо HLS для этого объекта. Задержка стала 400 ms.