Настройка MTU на IP-камере: устранение потери пакетов и артефактов видео
Архитектура передачи видео (RTSP) и проблема фрагментации
Проблема, когда картинка с IP-камеры рассыпается на квадраты (артефакты), нижняя часть кадра смазывается (Smearing) или периодически возникает серый экран (I-Frame drop), часто связана с потерей пакетов на канальном уровне. Видеопоток (RTSP) обычно передается по протоколу UDP, который не умеет восстанавливать потерянные пакеты. Если размер сформированного IP-камерой пакета превышает MTU (Maximum Transmission Unit) маршрутизатора на пути следования (особенно актуально для VPN, PPPoE или 4G-модемов), пакет подвергается фрагментации. Потеря даже одного фрагмента приводит к отбрасыванию всего исходного видеокадра на стороне регистратора (NVR). Бизнес-риски: запись «битого» видео, на котором невозможно распознать лица или номера автомобилей.
Анализ сети и влияние MTU
| Топология (Транспорт) | Стандартный MTU | Рекомендуемый MTU камеры |
|---|---|---|
| Локальная сеть (LAN - Ethernet) | 1500 Байт | 1500 Байт (Не менять) |
| PPPoE (Интернет провайдер) | 1492 Байта (минус 8 байт PPPoE) | 1400 Байт |
| VPN-туннели (IPsec / OpenVPN) | ~1400 - 1440 Байт (Overhead на шифрование) | 1360 Байт |
Диагностика и изменение MTU IP-камеры
Сценарий 1: Поиск оптимального MTU с помощью Ping
Прежде чем менять настройки, найдите максимальный размер пакета, который проходит без фрагментации.
- Откройте командную строку (CMD) на ПК или регистраторе.
- Запустите пинг до камеры с запретом фрагментации (ключ
-f) и заданным размером полезной нагрузки (ключ-l). В Linux используйтеping -M do -s 1472.ping IP_Камеры -f -l 1472 - Если получаете ответ "Требуется фрагментация, но установлен флаг DF" (Packet needs to be fragmented but DF set), уменьшайте размер на 10 байт (1462, 1452, 1400...) пока пинг не пройдет успешно.
- Важно: К найденному числу прибавьте 28 байт (20 байт IP-заголовок + 8 байт ICMP-заголовок). Это и будет ваш целевой MTU.
Сценарий 2: Настройка MTU в камере (Hikvision/Dahua)
Снижаем размер пакета, который генерирует камера, чтобы он пролезал в VPN-туннель целиком.
1. Зайдите в Web-интерфейс камеры.
2. Перейдите: Настройки -> Сеть -> Базовые настройки -> TCP/IP.
3. Найдите поле "Размер MTU" (MTU Size).
4. Измените значение по умолчанию (обычно 1500) на рассчитанное (например, 1360).
5. Сохраните и перезагрузите камеру.Типовые ошибки администраторов
- Попытка лечить артефакты снижением битрейта: Снижение битрейта (Bitrate) или разрешения не устраняет причину, если туннель режет пакеты. Кадры все равно будут фрагментироваться. Нужно менять именно MTU (размер пакета).
- Изменение MTU на NVR: Изменение MTU на регистраторе влияет только на исходящий от него трафик (например, в облако). Камера все равно будет слать пакеты по 1500 байт. Настраивать MTU нужно на источнике трафика — самой камере.
Трансляция RTSP-потоков через нестабильные VPN и LTE-каналы — сложная инженерная задача. Сетевые архитекторы ITSTM оптимизируют протоколы инкапсуляции маршрутизаторов, настроят TCP Interleaving для RTSP и обеспечат идеальную картинку без потерь кадров.
Частые вопросы (FAQ)
Почему при просмотре через браузер камера показывает нормально, а NVR пишет артефакты?
Браузер часто запрашивает вторичный поток (Sub-stream), который использует низкое разрешение и иногда переключается на TCP, что гарантирует доставку. NVR пишет главный поток (Main Stream) по UDP, который чувствителен к потерям.
Что лучше для видеонаблюдения: UDP или TCP?
UDP обеспечивает минимальную задержку (Real-Time), что важно для PTZ-управления. TCP гарантирует доставку кадров (без артефактов), но при нестабильном интернете задержка видео может достигать нескольких секунд. Для плохих каналов принудительно переключайте RTSP транспорт на TCP.
Если я поставлю MTU 1280, это решит все проблемы?
Слишком маленький MTU увеличит накладные расходы (Overhead), так как на каждый кусочек видео будет добавляться свой IP-заголовок. Это повысит нагрузку на процессор камеры и роутера. Используйте рассчитанный оптимальный MTU.
Влияет ли MTU на I-Frame Interval?
Напрямую нет, но опорный кадр (I-Frame) весит много и разбивается на десятки UDP пакетов. Потеря хотя бы одного из-за MTU ломает весь I-Frame, что приводит к серому экрану до следующего I-Frame (через 1-2 секунды).