Мониторинг захвата¶

Дешборд с мониторингом захвата является одним из важнейших во всем сервисе Retroview, ведь именно он обуславливает всё, что будет дальше происходить с сигналом.

По нашей 15-летней практике большинство проблем с обработкой видео уходят сами по себе, если устранить проблемы на входе. Огромная часть нашего сложного кода написана вокруг обработки тех проблем на входе, которые не получается исправить.

Индикация проблемных потоков¶

Это самый главный график для мониторинга состояния входа. Из всех потоков вашего сервиса (от единиц до сотен тысяч) сюда выводятся самые проблемные. Дальше можно выбирать с самого верха и анализировать детали.

Важно пользоваться разными временными диапазонами: и небольшим, чтобы увидеть свежие проблемы и на много дней, чтобы увидеть суточную периодичность.

После того, как первичная картина получена, надо выбрать конкретный стрим и уже изучать ситуацию на нём:

Как выглядит вечерний пик интернета¶

На таком графике мы можем видеть, что каждый вечер примерно с 19 до 1 часа ночи идут проблемы с приемом. Причина очень простая: трафик от источника идет по той же сети, что и обслуживание пользователей этого интернет провайдера, поэтому их вечернее потребление интернета приводит к потерям пакетов от камер наблюдения.

Выход простой: разносить сеть или физически или путем настроек VLAN, QoS и других подходов.

Эпизодические провалы сети¶

Так выглядят периодические провалы пропускной способности вашей сети. Характеризуются одновременным ростом ошибок на многих каналах одновременно. Чаще всего надо разбираться в индикации загрузки на свитчах и расширять пропускную способность сети.

Как выглядит авария у поставщика¶

Так выглядит авария у поставщика каналов, которую надо исправлять звонком. Всё было нормально и в один момент испортилось. Например такое могло быть, если поломалось оборудование или что-то случилось с настройками дескремблирования.

Если при такой картине не звонят абоненты, возможно вам эти каналы не нужны.

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

Состояние одного потока¶

Ниже в группе Stream details есть несколько графиков: ошибки, трафик, предупреждения, dvr. Они все нужны для планомерной работы с потоками. Ошибки и предупреждения о проблемах мы разнесли, чтобы вам было удобнее отделять критические проблемы от потенциальных.

Ошибки потока¶

Самый важный график - это ошибки. Они должны быть на нуле и это достижимо. Всё что выше нуля - это проблема, которую надо решать. В большинстве случаев можно быть уверенным в том, что ошибка на графике - это рассыпание картинки или потеря звука/субтитров и т.п.

Так выглядит плохой поток с камеры, который надо улучшать исправлениями в сети между камерой и медиасервером.

Так выглядят потери по SRT, которые друг друга продуцируют: потеря пакетов приводит к CC ошибкам. Возможно, если устранить потери (т.е. нехватку пропускной способности канала), то и остальные ошибки уйдут.

Так выглядит прием телевизионного сигнала с большим количеством потерь. Такое видео показывать клиентам нет смысла, но на практике такое часто пытаются транскодировать и просят помочь с плохой картинкой. Нужно чинить прием.

Настройте алерты: Алерт на рост числа проблемных потоков предупредит о деградации качества до того, как абоненты начнут жаловаться на рассыпание картинки. Алерт на нестабильные потоки поможет выявить периодические проблемы сети, такие как вечерний пик или эпизодические провалы.

Список известных ошибок¶

Далее идет список известных ошибок, которые можно увидеть на графиках.

lost_packets - на протоколах SRT, RTSP, WebRTC, ST2110 можно достоверно посчитать количество потерянных пакетов. Чинить сеть или увеличивать пропускную способность канала
src_404 - количество раз, когда источник отдал HTTP 404 (или другой код). Менять или чинить URL источника
src_403 - код 403 на источнике, т.е. нет авторизации. Обновить авторизационный ключ или учётные данные
src_500 - ошибка 500 на источнике. Срочно чинить источник
broken_payload - подобная ошибка встречается на разных протоколах. Например, в SDI это означает поломанный кадр; при распаковке RTP этот счётчик может увеличиваться от поломанной структуры H264/5 NAL-юнитов. Если потерь пакетов нет, а счётчик растёт, надо чтобы поставщик чинил источник
dropped_frames - такое может встретиться при захвате MPEG-TS потока, когда одна дорожка объявлена и надолго исчезла. При этом механизм пересортировки дорожек не может дождаться её и выбрасывает всю накопившуюся очередь. Обратиться к поставщику, чтобы починил источник
dropped_packets - пакеты, отброшенные по разным причинам, которые не всегда учитываются как lost_packets. Проверить качество сети и стабильность источника
no_signal - кадры отброшены, потому что на входе нет сигнала (например, чёрный кадр с платы захвата или камеры). Проверить камеру, кабель и источник
duplicate - данные кадра продублированы с предыдущего кадра, потому что вход не успевал. Снизить нагрузку на сервер или устранить медленный источник или сеть
ts_duplicate - временная метка кадра совпадает с предыдущим кадром. Обычно означает зависшие или сломанные часы источника. Починить источник или обновить прошивку камеры
cpu_stall - кадр отброшен из-за слишком высокой загрузки CPU на сервере. Снизить нагрузку или распределить потоки по серверам
ts_stuck_restarts - некоторые камеры доходят до максимального значения таймкода пакета и дальше вместо обнуления начинают слать максимальное значение. Лечится переподключением к камере. Обратиться к производителю камеры
ts_jump_restarts - перезапуски соединения из-за очень большого скачка временной метки потока. Обычно означает сломанные таймстемпы на источнике. Починить источник или обновить прошивку камеры
desync - индикация того, что байтовый поток на входе потерял структуру начала и конца пакетов и необходимо выбрасывать байты, пока заново не появится синхронизация, т.е. чёткая структура кадров. Чинить источник или сеть
ts_pat - во входящем MPEG-TS потоке не было PAT длительное время. Чинить источник или антенну
ts_pmt - во входящем MPEG-TS потоке не было PMT длительное время. Указан раздельно по PID потока. Чинить источник
errors_pid_lost - MPEG-TS PID исчез из потока. Показывается отдельно по PID на MPEG-TS графиках. Чинить источник или разбираться с мультиплексированием
ts_service_lost - как много раз был получен MPEG-TS PAT с программами, которых нет. Чинить мультиплексирование на источнике
adaptation_broken - сколько раз MPEG-TS adaptation field был невалидным. Как правило эта ошибка означает полный мусор на входе
ts_scrambled - MPEG-TS поток идет шифрованным. Необходимо срочно разобраться с CAM модулями.
ts_cc - некорректный MPEG-TS Continuity Counter, скорее всего потеря пакетов. Чинить сеть.
ts_tei - пришел MPEG-TS пакет с индикацией ошибки, которую явно проставил предыдущий источник. Разбираться с тем источником
ts_psi_checksum - несовпадение чексуммы в служебных структурах MPEG-TS пакетов. Чинить источник или антенну.
broken_pes_count - PES пакет внутри MPEG-TS начался не со старткода. Чинить плохой источник.
discarded_buffer_count - сколько раз данные в MPEG-TS выбрасывались, потому что нельзя было собрать из них кадр. Чинить источник.
ts_crashed - произошла внутренняя ошибка в медиасервере при обработке MPEG-TS. Обратиться к технической поддержке.
too_large_dts_jump - в MPEG-TS потоке произошел скачок времени более чем на 30 секунд. Такое может возникать, например из-за того, что источник сформирован из файлов, которые ротируются без перештамповки времени. Другая причина - смешивание звука и видео из разных потоков. Если такие ошибки редкие, то возможно нарушение проигрывания будет носить только локальный характер, но в любом случае такой поток стоит исправить.
rtp_pt_reject - в RTSP (RTP) потоке приходят пакеты с неизвестным, чужим Payload Type и их приходится выбрасывать. Требовать обновления прошивки камеры
dts_stuck - RTSP камера начала отдавать один и тот же таймстемп. Менять камеру или обновлять прошивку.
resync_count_jump - Источник может изменять временные метки без какого-либо уведомления. Этот счётчик показывает, насколько плох источник.
discarded_not_allowed_nal_count - пришёл неподдерживаемый тип пакетизации H264, например STAP-B или MTAP. Скорее всего нужно обновлять прошивку или менять камеру, но если есть уверенность в том, что это то, что вам нужно — писать в поддержку
motion_detector_not_authorized - запросы к детектору движения отклонены из-за ошибки авторизации. Проверить учётные данные ONVIF и настройки доступа на камере
motion_detector_url_unreachable - запросы к детектору движения не прошли из-за неверного URL или сетевых проблем. Проверить настроенный URL, сетевой путь и доступность камеры
motion_detector_no_agent_connected - запрос к детектору движения не прошёл, потому что Flussonic Agent не подключён. Убедиться, что агент запущен и подключён к стримеру
motion_detector_no_service - попытка обратиться к отключённому или неподдерживаемому ONVIF-сервису детекции движения. Включить детекцию движения на камере или проверить совместимость по ONVIF
motion_detector_incorrect_time_values - ответы детектора движения не соответствуют ожидаемым временным меткам или значениям. Проверить прошивку камеры и настройки детектора движения
motion_detector_broken_payload - ответы детектора движения содержали битый или невалидный контент. Проверить прошивку камеры; при необходимости обновить
agent_conn_failed - агент не смог открыть запрошенное соединение. Может означать проблемы с открытием TCP-сокета на агенте или недоступность удалённого хоста. Проверить агент, сеть и целевой хост
agent_out_of_memory - у агента не хватило памяти для установки соединения с удалённым хостом. Снизить нагрузку на агент или увеличить доступную память
agent_buffer_overrun - буфера агента не хватило для исходящего трафика. Увеличить размер буфера или снизить трафик через агент
agent_invalid_request - агент получил невалидные запросы. Проверить конфигурацию потока и версию агента
agent_unknown - неизвестные ошибки агента. Собрать логи и обратиться в техническую поддержку
crashed - необработанный сбой при обработке входа. Обратиться в техническую поддержку
errors_sr_clock_deviation - время на камере значительно отличается от времени стримера. Возникает, когда стример получает RTCP-синхронизацию и обнаруживает, что отклонение времени камеры превышает допустимый порог. Счётчик увеличивается только если включена опция wait_rtcp, при которой стример использует время камеры без коррекции. Последствия: серьёзные проблемы с архивом, повреждённая временная шкала DVR и сбои при просмотре. Что делать: срочно проверить и исправить время на камере (системные часы, часовой пояс, NTP). Если репликация архива IRIS-DVR не используется, можно отключить опцию wait_rtcp на стримере. Если проблема сохраняется при использовании IRIS-DVR, обратиться в поддержку

Детали предупреждений входного потока¶

Предупреждения, которые корректируются сервером:

not_aligned_packets_udp_mpegts - UDP-пакеты, у которых длина MPEG-TS payload не кратна 188 байтам. Обычно означает повреждение в сети, неверную инкапсуляцию или неправильную настройку оборудования. Проверить UDP-путь и источник
ts_stuck - перезапуски из-за зависания TS
sr_ts_stuck - SR пакеты с повторяющимся RTP timestamp
sender_clock_deviation - часы отправителя опережают/отстают от серверного времени
ts_goes_backwards - время на канале прыгнуло назад
ts_jump_forward - время прыгнуло вперед
no_marker_mode_flag - декодер работает в режиме без маркера
fu_pattern_is_broken_count - нарушенный паттерн FU
fu_has_both_start_end_bits_count - FU с установленными одновременно битами Start и End
fu_end_then_middle_workaround_count - применен workaround для FU
dts_stuck - повторяющийся DTS
dts_goes_backwards - DTS прыгнул назад
dts_jump_forward - DTS прыгнул вперед

Настройте алерт: Алерт на рост числа оффлайн потоков позволит среагировать на нарастающую проблему до того, как она затронет критичную массу каналов.

Состояние записи¶

На графике «DVR recording issues» можно увидеть проблемы записи.

Это не совсем относится к захвату, но сами данные прийдут в негодность, если на этом графике будут ошибки.

Обращать внимание надо на следующие ошибки:

discontinuity означает, что в потоке есть разрывы. При проигрывании не будет бесшовного воспроизведения. Чинить источник.
failed - попытка записи в хранилище завершилась ошибкой. Срочно менять жесткий диск.
skipped - не успевали записать и начали выбрасывать сегменты. Отказаться от сетевого стораджа, снизить нагрузку на жесткие диски, отказаться от аппаратного RAID и перейти на Flussonic RAID
slow и delayed означает что запись была успешная, но опасно долго, больше половины длительности самого сегмента.
collapsed - пришлось записывать несколько сегментов вместе. Не фатально, но больше роста нагрузки эта система не выдержит.