Перейти к основному содержимому

Чтение логов FFMPEG и диагностика проблем

06-06-01

Работа с сетевыми видеопотоками через FFMPEG часто сопровождается неожиданными сбоями: камера не отвечает, изображение пропадает, звук отстаёт или вовсе отсутствует. В таких ситуациях первое, к чему следует обратиться — это логи FFMPEG. Они содержат ключевую информацию о состоянии соединения, причинах сбоев и внутренних процессах обработки медиапотока.

Этот материал поможет вам научиться читать и интерпретировать сообщения FFMPEG, понимать, где искать проблему, и какие действия предпринять для её устранения. Мы разберём типичные ошибки, научимся включать подробное логирование и рассмотрим реальные сценарии диагностики.

Ошибки подключения к сетевым источникам​

Одни из самых частых проблем при работе с FFMPEG — это неудачные попытки подключиться к источнику потока. Это может быть IP-камера по RTSP, RTMP-сервер или SRT-шина. Причины могут быть как на стороне клиента (FFMPEG), так и на стороне сервера.

Типичные сообщения и их значение​

401 Unauthorized / 403 Forbidden​

Эти HTTP-подобные коды возвращаются при попытке доступа к RTSP-потоку.

  • 401 Unauthorized — сервер требует аутентификацию, но она не предоставлена или неверна.

    • Пример в логе:

      [rtsp @ 0x55a1b2c3d0] method DESCRIBE failed: 401 Unauthorized

    • Что проверить:

      • Правильно ли указаны логин и пароль в URL: rtsp://user:pass@ip:port/stream.
      • Поддерживает ли камера передачу учётных данных в URL (некоторые прошивки блокируют это).
      • Не изменился ли пароль или не сработала ли блокировка после нескольких попыток.
  • 403 Forbidden — аутентификация прошла, но у пользователя нет прав на доступ к этому потоку.

    • Пример:

      [rtsp @ 0x55a1b2c3d0] method DESCRIBE failed: 403 Forbidden

    • Что проверить:

      • Уровень доступа пользователя в настройках камеры.
      • Доступен ли указанный профиль потока (например, stream2, high, low) для данного пользователя.

💡 Совет: Используйте утилиты вроде curl или ONVIF-менеджер для проверки доступа к камере отдельно от FFMPEG. Это поможет локализовать проблему: сеть/аутентификация или именно FFMPEG.

Connection timed out​

Соединение не установлено в течение ожидаемого времени.

  • Пример:

    [tcp @ 0x55a1b2c3d0] Connection to tcp://192.168.1.100:554?timeout=5000000 failed: Connection timed out

  • Возможные причины:

    • Камера или сервер не в сети.
    • Неверный IP-адрес или порт.
    • Фаервол или NAT блокируют соединение.
    • Камера перегружена и не отвечает.

  • Что делать:

    • Проверьте доступность устройства через ping и telnet <ip> <port>.
    • Убедитесь, что порт RTSP (обычно 554) или SRT (например, 7001) открыт.
    • Увеличьте таймаут в FFMPEG: -timeout 10000000 (в микросекундах).

method DESCRIBE failed​

Критическая ошибка при попытке получить описание потока по RTSP.

  • Пример:

    [rtsp @ 0x55a1b2c3d0] method DESCRIBE failed: 404 Not Found

  • Что это значит:

    • Сервер не нашёл запрошенный поток (неверный URL).
    • Камера не поддерживает RTSP или отключена.
    • Некорректный URL (например, /live.sdp вместо /stream1).

  • Решение:

    • Проверьте точный RTSP-URL через документацию камеры или ONVIF-инструмент.
    • Убедитесь, что поток включён в настройках камеры.

🧩 Пример из практики:
Камера Dahua. URL rtsp://admin:pass@192.168.1.50:554/cam/realmonitor?channel=1&subtype=0 — если subtype=1, поток может быть недоступен, если не настроен. Ошибка DESCRIBE failed в этом случае — не ошибка FFMPEG, а отсутствие потока на стороне камеры.

Проблемы приёма и воспроизведения потока​

Даже если подключение установлено, могут возникать проблемы с приёмом данных: поток «рвётся», появляются артефакты, теряется синхронизация.

Потери пакетов и переполнение буфера​

FFMPEG сообщает о сетевых проблемах через сообщения вроде:

[rtsp @ 0x55a1b2c3d0] RTP: missed 12 packets

или

[buffer @ 0x55a1b2c3d0] Buffer queue overflow, dropping.

Что означают эти сообщения:​

СообщениеПричинаЧто делать
RTP: missed N packetsПотеря пакетов в сети (UDP), джиттер, перегрузка каналаПерейти на TCP (-rtsp_transport tcp), проверить сеть, уменьшить битрейт
Buffer queue overflowВходной буфер FFMPEG переполнен — данные приходят быстрее, чем обрабатываютсяУвеличить размер буфера (-rtbufsize 100M) или уменьшить нагрузку на CPU
Buffer underflowБуфер опустошился — данных не хватает для декодированияУвеличить буфер, проверить стабильность соединения

💬 Важно: При использовании UDP (например, в RTSP или UDP/RTP) потери пакетов — норма. FFMPEG не может их восстановить, если не используется FEC или ретрансмиссия (как в SRT).

Рассинхронизация аудио и видео (A/V desync)​

Иногда звук опережает или отстаёт от видео. В логах это может проявляться косвенно:

[AVSync] audio timestamp 123456 < video timestamp 124000, difference too large

или просто:

Non-monotonic DTS in output stream

Причины:​

  • Разная задержка в аудио- и видеопотоках.
  • Потери пакетов в одном из потоков.
  • Нестабильные временные метки (PTS/DTS) от источника.

Как диагностировать:​

  • Включите подробное логирование (см. ниже) и следите за PTS/DTS.
  • Используйте -probesize и -analyzeduration для лучшего определения параметров потока.
  • В крайнем случае — принудительно синхронизируйте через фильтры: async=1, aresample, setpts.

🎯 Пример:
При работе с RTMP-сервером, перегруженным трансляциями, аудио может буферизоваться сильнее, чем видео. Решение — уменьшить буферы на стороне сервера или использовать SRT с настройкой latency.

Включение подробного логирования​

По умолчанию FFMPEG выводит только критические ошибки. Чтобы глубже диагностировать проблему, нужно включить расширенный режим логирования.

Уровни детализации​

FFMPEG поддерживает несколько уровней логирования. Для диагностики сетевых проблем наиболее полезны:

УровеньКомандаЧто показывает
quiet-loglevel quietНичего (только ошибки)
error-loglevel errorТолько ошибки
warning-loglevel warningОшибки и предупреждения
info-loglevel infoСтатус инициализации, параметры потока (по умолчанию)
verbose-loglevel verboseПодробная информация о пакетах, буферах, PTS/DTS
debug-loglevel debugМаксимальная детализация, включая внутренние вызовы

Рекомендуемая команда для диагностики:​

ffmpeg -loglevel verbose -i rtsp://... -c copy output.mp4

или

ffmpeg -loglevel debug -i srt://... -c copy output.ts

⚠️ Внимание: Уровень debug генерирует очень большой объём вывода. Используйте его только для кратких тестов и перенаправляйте в файл:

ffmpeg -loglevel debug -i rtsp://... -c copy out.mp4 2> debug.log

На что смотреть в подробных логах​

При включённом -loglevel verbose или debug FFMPEG начинает выводить информацию, полезную для диагностики:

1. PTS и DTS — временные метки кадров​

Пример вывода:

[rtsp @ 0x55a1b2c3d0] DTS 123456, PTS 123456, duration 33 ms
  • PTS (Presentation Time Stamp) — время отображения кадра.
  • DTS (Decoding Time Stamp) — время декодирования.

Что искать:

  • Немонотонные значения — если PTS прыгает вперёд/назад, это может вызвать рывки.
  • Большие разрывы — например, от 1000 до 2000 мс — признак потерь или перезапуска потока.
  • Отрицательные значения — возможны при старте, но не должны сохраняться долго.

2. Состояние буферов: underrun и overrun​

В логах могут встречаться сообщения:

[buffer @ 0x55a1b2c3d0] Buffer underrun, waiting for more data

или

[buffer @ 0x55a1b2c3d0] Buffer overrun, dropping frame
  • Underrun — буфер пуст, данных не хватает. Причина: медленная сеть, перегрузка CPU.
  • Overrun — буфер переполнен. Причина: данные приходят слишком быстро, FFMPEG не успевает обрабатывать.

Что делать:

  • Для underrun: увеличьте буфер (-rtbufsize 100M) или уменьшите нагрузку.
  • Для overrun: уменьшите битрейт источника или оптимизируйте кодирование.

3. Статистика приёма пакетов​

В режиме verbose FFMPEG может показывать:

[rtsp @ 0x55a1b2c3d0] Received packet of type video, size 1460, seq 1234
[rtsp @ 0x55a1b2c3d0] RTP: missed 5 packets after seq 1234

Это позволяет отследить:

  • Частоту потерь.
  • Моменты, когда сеть «проседает».
  • Соответствие между потерями и артефактами на видео.

Примеры реальных ситуаций и диагностика​

Ситуация 1: Камера не отвечает​

Симптом: FFMPEG зависает на старте, нет изображения.

Лог:

[tcp @ 0x55a1b2c3d0] Connection to tcp://192.168.1.100:554?timeout=5000000 failed: Connection timed out

Диагностика:

  • Проверить ping 192.168.1.100.
  • Проверить telnet 192.168.1.100 554.
  • Убедиться, что камера включена и настроена.

Решение: Исправить сеть или перезагрузить камеру.

Ситуация 2: RTMP-сервер перегружен​

Симптом: Запись идёт, но с обрывами. В логе — buffer overrun.

Лог:

[flv @ 0x55a1b2c3d0] Failed to send packet: Broken pipe
[buffer @ 0x55a1b2c3d0] Buffer overrun, dropping.

Диагностика:

  • Сервер не успевает принимать данные.
  • Возможно, высокая нагрузка на CPU или сеть.

Решение:

  • Увеличить буфер на стороне FFMPEG: -flvflags nobuffer.
  • Уменьшить битрейт: -b:v 2M.
  • Перейти на SRT с управляемой задержкой.

Ситуация 3: SRT-соединение с недостаточной задержкой​

Симптом: Потери пакетов, несмотря на надёжность SRT.

Лог:

[srt @ 0x55a1b2c3d0] SRT: lost packet, seq 12345

Причина: Параметр latency слишком мал для текущего джиттера.

Решение:

  • Увеличить задержку при подключении:

    srt://192.168.1.100:7001?mode=caller&latency=200

  • Проверить джиттер сети с помощью srt-live-transmit или wireshark.

Заключение: алгоритм диагностики​

При возникновении проблем с FFMPEG в сетевой среде рекомендуется следовать такому алгоритму:

  1. Проверьте доступность источника — ping, telnet, ONVIF-менеджер.
  2. Запустите FFMPEG с -loglevel info — посмотрите, доходит ли до стадии Input #0.
  3. Если подключение есть, но поток рвётся — включите -loglevel verbose.
  4. Ищите в логах:
    • Ошибки подключения (401, timeout).
    • Потери пакетов (RTP/SRT).
    • Переполнение/опустошение буферов.
    • Нарушения PTS/DTS.
  5. Примите меры:
    • Настройте аутентификацию.
    • Увеличьте буферы (-rtbufsize, latency).
    • Перейдите на TCP или SRT.
    • Упростите пайплайн (отключите фильтры, транскодирование).

📌 Ключевое правило: FFMPEG — отличный инструмент, но он не может компенсировать нестабильную сеть или неправильно настроенные устройства. Логи помогают понять, где находится узкое место: в сети, в источнике или в самой команде FFMPEG.