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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

lost_packets - на протоколах SRT, RTSP, WebRTC, ST2110 можно достоверно посчитать количество потерянных пакетов.
src_404 - количество раз, когда источник отдал HTTP 404 (или другой). Менять/чинить источник
src_403 - код 403 на источнике, т.е. нет авторизации. Менять авторизационный ключ
src_500 - ошибка 500 на источнике. Срочно чинить источник.
broken_payload - подобная ошибка встречается на разных протоколах. Например в SDI это означает поломанный кадр, при распаковке RTP этот счетчик может увеличиваться от поломанной структуры H264/5 NAL-юнитов. Если потерь пакетов нет, а счетчик растет, надо чтобы поставщик чинил источник.
dropped_frames - такое может встретиться при захвате MPEG-TS потока, когда одна дорожка объявлена и надолго исчезла. При этом механизм пересортировки дорожек не может дождаться её и выбрасывает всю накопившуюся очередь. Надо обращаться к поставщику чинить источник.
ts_stuck_restarts - некоторые камеры доходят до максимального значения таймкода пакета и дальше вместо обнуления, начинают слать максимальное значение. Эта ошибка индицируется тут, лечится переподключением к камере. Обратиться к производителю камеры за
desync - индикация того, что байтовый поток на вход потерял структуру начала и конца пакетов и необходимо выбрасывать байты, пока заново не появится синхронизация, т.е. четкая структура кадров.
ts_pat - во входящем MPEG-TS потоке не было PAT длительное время
ts_pmt - во входящем MPEG-TS потоке не было PMT длительное время. Указан раздельно по пидам потока.
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 камера начала отдавать один и тот же таймстемп. Менять камеру или обновлять прошивку.
discarded_not_allowed_nal_count - пришел неподдерживаемый тип пакетизации H264, например STAP-B или MTAP. Скорее всего обновлять прошивку или менять камеру, но если есть уверенность в том, что это то, что вам нужно - писать в поддержку.

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

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

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 - пришлось записывать несколько сегментов вместе. Не фатально, но больше роста нагрузки эта система не выдержит.