Continuity count error что это

События в календаре не найдены.

Кто сталкивался с настройкой sumavision?

禪

• Печать

Страницы: 1 … 26 27 [28] 29 30 … 65   Вниз

Тема: sumavision  (Прочитано 298349 раз)

« Последнее редактирование: 08.04.2014, 01:21 от baks »

Записан

• Печать

Страницы: 1 … 26 27 [28] 29 30 … 65   Вверх

2.2.1. Q: Как начать работать с системой мониторинга?¶

A: Необходимо знать несколько базовых вещей:

1. Система состоит из сервера мониторинга (находится в облаке) и клиентской части — зонда, который пользователь размещает в своей сети.
2. Пользователь самостоятельно выбирает аппаратное обеспечение для зонда.
3. Вам необходимо скачать архив зонда в личном кабинете. Обратите внимание, что пакет привязан к проекту в вашем кабинете. Это означает, что запущенный зонд будет отображать данные только в проекте, из которого он был загружен.
4. Следующим шагом необходимо запустить зонд и убедиться, что он появился в системе мониторинга (выпадающая левая панель в ЛК на сервисе boro.elecard.ru).
5. Следует знать, что можно запускать несколько зондов. Количество зондов фактически ограничивается количеством анализируемых потоков в приобретенной подписке.
6. Если требуется запуск нескольких зондов на одной машине, необходимо сделать копию всей папки зонда (например папки win64), так как приложения streamMonitor, запущенные из одной папки, будут иметь конкурирующий доступ к некоторым файлам!
7. Кроме этого, следует знать, что зонд не отправляет потоки на облачный сервер в каком-либо виде. Весь анализ проводится локально. На сервер отправляются статистические данные (величина битрейта, зарегистрированные ошибки), структура потока (PSI таблица), Closed Caption и SCTE35 данные и эскизы видеопрограмм.

2.2.2. Q: Как запустить зонд в консоли?¶

A: Для того, чтобы получить приложение, необходимо пройти несколько этапов. Более подробное описание можно найти в Руководстве по быстрому старту. Если вы скачали архив с приложением, для его запуска нужно осуществить следующие действия:

Linux

1. Скопируйте скачанный архив зондов в необходимый каталог на Linux машине.

2. При необходимости установите пакет unzip. Пример инсталляции на CentOs:

3. Перейдите в каталог с архивом зондов и разархивируйте его, пример распаковки с созданием директории Boro:

   unzip -d ./boro ESenSay.2016-v1.00-2016.11.07.proj244.zip
   

4. Зайдите в каталог, соответствующий разрядности и типу вашей ОС.

5. В файле monitor.cfg отредактируйте поле «AppDescription» (задайте имя анализатору, которое будет отображаться в системе) и при необходимости задействуйте поле «proxy», убрав // перед строкой прокси сервера.

6. Запустите анализатор в консоли:

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

7. В случае успешного запуска (зонд отображается в боковой панели личного кабинета зеленой точкой) все дальнейшие действия (запуск, редактирование и остановка задач) производятся при помощи браузера.

8. Если зонд не запускается, обратитесь к параграфу Q: Зонд не запускается.

Windows

1. Разархивируйте полученный файл в необходимую директорию.
2. Зайдите в папку, соответствующую разрядности и типу вашей ОС.
3. В файле monitor.cfg отредактируйте поле «AppDescription» (задайте имя анализатору, которое будет отображаться в системе) и при необходимости задействуйте поле «proxy», убрав // перед строкой прокси сервера.
4. Запустите анализатор «от администратора» (правый клик на файле streamMonitor.exe -> Запуск от имени администратора). Должна запуститься консоль.
5. В случае успешного запуска (зонд отображается в боковой панели личного кабинета зеленой точкой) все дальнейшие действия (запуск, редактирование и остановка задач) производятся при помощи браузера.
6. Если зонд не запускается, обратитесь к параграфу Q: Зонд не запускается.

2.2.3. Q: Как правильно остановить зонд, запущенный в консоли?¶

A: Правильным методом является одинарное нажатие Ctrl+C в консоли, после этого необходимо ожидать корректного завершения работы зонда (до 1 минуты). Данный метод используется в Linux и Windows системах.

Если просто закрыть консоль, выполнение программы завершится некорректно, программа не будет иметь возможности передать на сервер команду остановки. Сервер будет ожидать отклик от некорректно завершенного зонда до 1 минуты, и только потом переведет задачи в состояние «завершенные» с пометкой «некорректно».

2.2.4. Q: Зонд не запускается¶

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

• Неустойчивое Internet соединение (попробуйте повторный запуск);
• Выход в Internet осуществляется через прокси сервер, но он не указан (указан неправильно) в файле monitor.cfg, либо строка в конфиге «закомментирована»;
• Firewall (Brandmauer) ограничивает доступ приложения к сети. Решение данной проблемы описано в Почему Boro «не видит мультикаст», плеер на этой машине играет поток! -> A1: Firewall (Brandmauer).

A2: В файле monitor.cfg были внесены правки, нарушающие формат .json, или добавлены данные, которые не соответствуют структуре данных, определенных в файле monitor.cfg. Кроме этого, файл monitor.cfg обязан сохраняться в utf-8. Обычно, при проблемах с конфигурационным файлом в лог консоли попадают сообщения об ошибках парсинга при запуске. Это первый признак проблем в файле monitor.cfg.
Решение проблемы:

• Попытаться найти ошибки в файле (сложно для начинающих);
• Скачать заново архив из личного кабинета и положить свежий неизмененный monitor.cfg в каталог, где производилась попытка запуска зонда. Однако, в таком случае, вы потеряете все настройки и список задач, сохраненные в monitor.cfg на момент последней остановки зонда. Необходимо заново задать имя зонда, при необходимости установить прокси сервер и поставить задачи запущенному зонду из web.

Подробную информацию о конфигурационном файле вы можете найти в разделе Конфигурационный файл.

A3: Возможно, в каталоге с приложением были удалены или повреждены некоторые библиотеки. Скачайте архив заново, подмените в свежем пакете файлы monitor.cfg и authkey.pub вашими файлами. Желательно скопировать скрытый файл .stored.cache, тогда не будет создано повторной записи с одинаковым именем зонда.

A4: Возможно, вы пытаетесь запустить очень старую версию зонда. Попробуйте скачать свежую версию пакета зондов в личном кабинете, отредактируйте файл monitor.cfg и попробуйте запуск снова.

A5: Используется устаревшая версия ОС Linux. Необходима поддержка glibc-2.11 и выше.

2.2.5. Q: Запуск и остановка зонда как служба (демон процесс)¶

A1: служба в Widows

Не поддерживается

A2: Сервис в systemd (CentOs 7, Ubuntu 16.04)

Полезные ссылки: https://habrahabr.ru/company/centosadmin/blog/255845/ (RU)
https://www.dynacont.net/documentation/linux/Useful_SystemD_commands/ (EN)

1. Создайте файл /etc/systemd/system/boro-client.service следующего содержания:

   [Unit]
   Description=boro probe
   Documentation=https://boro.elecard.com https://boro.elecard.com/pdf/FAQ_en.pdf
   After=network-online.target
   Wants=network-online.target
   
   
   [Service]
   #Type=simple
   User=root
   #Group=root
   WorkingDirectory=/opt/boro/dev/lin64
   ExecStart=/opt/boro/dev/lin64/streamMonitor
   PrivateTmp=false
   Restart=always
   RestartSec=120s
   
   [Install]
   WantedBy=multi-user.target,
   

где необходимо правильно указать поля WorkingDirectory и ExecStart — директорию, в которой находится зонд, и путь до исполняемого файла, соответственно.

1. Для проверки состояния сервиса необходимо выполнить следующую команду:

   [user@localhost ~]$ systemctl -l status boro-client
   boro-client.service - boro client
   Loaded: loaded (/etc/systemd/system/boro-client.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
   

   Выделенные поля говорят о том, что автозапуск не включен, и приложение не запущено.

2. Для запуска демона необходимо выполнить команду:

   systemctl start boro-client
   

   Для остановки демона необходимо выполнить команду:

   systemctl stop boro-client
   

1. Для разрешения автозапуска выполните команду:

   systemctl enable boro-client
   

   Для отключения автозапуска:

   systemctl disable boro-client
   

2. Проверьте состояние запущенного демона:

   [user@localhost lin64]$ systemctl -l status boro-client
   boro-client.service - boro client
   Loaded: loaded (/etc/systemd/system/boro-client.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2017-03-28 16:01:35 +07; 2s ago
   

   Выделенные поля указывают, на то, что демону разрешен автозапуск (enabled), и он сейчас запущен (Active: active (running)).

A3: Сервис в SysV (устаревшие дистрибутивы Linux)

Полезные ссылки: https://www.opennet.ru/base/sys/run_services_tips.txt.html (RU).

Необходимо сказать, что данная система запуска сервисов сохраняется как наследие в современных дистрибутивах. Также необходимо знать, что функции в скрипте запуска (/etc/rc.d/init.d/functions) могут иметь разные аргументы в зависимости от дистрибутива, ознакомьтесь с документацией системы инициализации сервисов вашего дистрибутива для корректировки скрипта.

В данном разделе рассмотрена реализация скрипта автоматического запуска для дистрибутива Linux CentOs 6.8. Документация на подготовку скрипта:

/usr/share/doc/initscripts-*/sysvinitfiles.

1. Перейдите в директорию /etc/rc.d/init.d

2. Создайте файл boro-client (необходимы привилегии суперпользователя) со скриптом ниже. Будьте внимательны, создавая скрипт в Windows (CRLF), интерпретатор bash требует строгого соблюдения Linux стиля (только LF) переноса строк.

   #!/bin/sh
   # chkconfig: - 98 02
   # description: OTT and multicast probe.
   # processname: BoroProbe
   
   # Source function library.
   if [ -f /etc/init.d/functions ] ; then
           . /etc/init.d/functions
   elif [ -f /etc/rc.d/init.d/functions ] ; then
           . /etc/rc.d/init.d/functions
   else
           exit 0
   fi
   KIND="Boro-probe"
   PROCPATH="/opt/boro/lin64"
   
   start() {
     echo -n $"Starting $KIND services: "
     daemon --check=streamMonitor $PROCPATH/streamMonitor >/dev/null 2>&1 &
     #daemon --check=streamMonitor $PROCPATH/streamMonitor >$PROCPATH/proclog.log 2>&1 &
     echo
   }
   
   stop() {
           echo -n $"Shutting down $KIND services: "
           killproc streamMonitor
           echo
   }
   
   restart() {
           echo -n $"Restarting $KIND services: "
                   stop
                   start
   }
   
   case "$1" in
           start)
                   start
                   ;;
           stop)
                   stop
                   ;;
           restart)
                   restart
                   ;;
           status)
                   status streamMonitor
                   ;;
           *)
                   echo $"Usage: $0 {start|stop|restart|status}"
                   exit 1
   esac
   exit $?
   

3. В скрипте необходимо правильно задать переменную PROCPATH — путь до каталога с зондом.

4. В скрипте необходимо выбрать, хотите ли вы сохранять лог процесса.
   Лог не будет сохраняться:

   daemon --check=streamMonitor $PROCPATH/streamMonitor >/dev/null 2>&1 &
   #daemon --check=streamMonitor $PROCPATH/streamMonitor >$PROCPATH/proclog.log 2>&1
   

   Лог будет сохраняться в файл proclog.log в папке с зондом:

   #daemon --check=streamMonitor $PROCPATH/streamMonitor >/dev/null 2>&1 &
   daemon --check=streamMonitor $PROCPATH/streamMonitor >$PROCPATH/proclog.log 2>&1
   

5. Сохраните изменения в файле boro-client.

6. Необходимо назначить права на исполнение для скрипта (необходимы привилегии суперпользователя): chmod 755 /etc/rc.d/init.d/boro-client

7. Добавляем скрипт в систему запуска:

   chkconfig --add boro-client
   

8. Включаем автостарт сервиса:

9. После перезагрузки анализатор будет автоматически запущен как сервис. Для сервиса можно проверить статус, запустить и остановить его “вручную” следующими командами, находясь в директории /etc/rc.d/init.d:

   ./boro-client status
   ./boro-client start
   ./boro-client stop
   

Список установленных сервисов в системе и их статус можно проверить командой:

Автозапуск сервиса можно отключить командой:

chkconfig boro-client off

Примечание

При обновлении все настройки и задачи зонда сохраняются. Однако, компания Elecard рекомендует произвести сохранение конфигурации на сервере или создать копию конфигурационного файла monitor.cfg непосредственно перед обновлением зонда.

2.3.1. Q: Удаленное обновление зонда из web¶

A: Запустите ваш текущий зонд/зонды и перейдите на страницу настройки зонда, кликнув на соответствующее имя зонда в боковой выпадающей панели.

На рисунке ниже видно, что есть обновление для запущенного зонда (голубая ссылка Update to/Обновить с номером обновления). Необходимо нажать на данную ссылку.

Зонд должен обновиться в течение одной минуты, после этого страница обновится, и в поле Version/Версия вы увидите новую версию зонда. Если страница автоматически не обновилась, нажмите F5.

Если до обновления использовалась слишком старая версия зонда, при обновлении могут возникнуть проблемы. В таком случае может понадобиться перезапуск зонда непосредственно на удаленной машине. Кроме этого, до определенной версии, зонд не поддерживал команду обновления из web, воспользуйтесь обновлением из консоли, описанным ниже.

2.3.2. Q: Обновление зонда из командной строки¶

A: Для обновления из командной строки выполните следующую последовательность действий:

1. Если зонд запущен, остановите его нажатием Ctrl+C в командной строке. Если зонд запущен как демон/служба, обратитесь к вопросу Q: Запуск и остановка зонда как служба (демон процесс).

2. В консоли перейдите в директорию, в которой находится зонд, и запустите его с параметром -u:

   Linux: ./streamMonitor -u

   Windows: streamMonitor.exe -u

   Если на сервере есть обновление, зонд обновит нужные компоненты и покажет версию, до которой он обновился.
   Если доступного обновления нет, в консоли будет сообщение: No updates!

3. Проверить текущую версию зонда можно, используя ключ -v

   user@localhost lin64]$ ./streamMonitor -v
   date changed[pid:20373]: 29.03.2017
   Version: 1.01
   Build info: 2017.03.20 08:36:02 UTC
   Platform: lin64
   

Примечание

В связи с интенсивным развитием проекта, данный параграф может содержать расхождения и неточности. Стоит отметить, что разработчики компании Elecard стараются максимально сохранить обратную совместимость конфигурационного файла со свежими релизами ПО зонда. При управлении зондом из браузера все настройки и изменения отражаются в файле monitor.cfg. При этом происходит полное переформатирование текста файла к формату по умолчанию для используемой версии ПО зонда. Поэтому, если вы намерены назначать задачи зонду путем редактирования файла monitor.cfg, всегда сохраняйте резервную копию файла.

2.4.1. Q: Что такое конфигурационный файл?¶

A: Это файл monitor.cfg, получаемый в пакете зонда из личного кабинета (см. Руководстве по быстрому старту), лежащий в директории с исполняемым файлом streamMonitor. Файл предназначен для хранения настроек зонда, включая список задач. При управлении зондом, назначении задач для анализа и др. действиях на сервере данный файл модифицируется приложением зонда. При запуске, перезапуске и незапланированном перезапуске зонд использует monitor.cfg для восстановления состояния.
Один из вариантов постановки задач зонду — редактирование файла monitor.cfg.
Один из вариантов переноса настроек и бекапа — сохранение и копирование файла monitor.cfg.

2.4.2. Q: Редактирование конфигурационного файла¶

A1: Перед редактированием конфигурации необходимо знать несколько базовых вещей:

1. Минимальный набор параметров, необходимый для успешного запуска приложения зонда, уже включен в monitor.cfg в загруженном архиве зонда.
2. Очень внимательно отнеситесь к .json синтаксису (частая причина ошибок).
3. Файл monitor.cfg необходимо сохранять в формате utf-8.
4. Попробуйте поставить зонду пару задач из web и посмотрите, как изменится пустой конфиг на достаточно сложные массивы.
5. Перед управлением из браузера сохраняйте копию monitor.cfg при отладке.
6. Не стоит пугаться сложного конфига, сформированного автоматически! Задачи зонду можно поставить простым списком в monitor.cfg. А все необходимые настройки добавляются групповым редактированием задач в браузере.
7. Всегда можно изменить настройки в браузере, ваша цель — сформировать список URI и имен задач, пригодный для запуска зонда.
8. Обратитесь к примерам ниже , они проще примеров, сформированных автоматически.

Конфигурация сохраняется в формате, схожем с форматом json. Дополнительно:

• Поддерживаются C-подобные комментарии:

  • Текст, начинающийся с «/» и оканчивающийся на «/», образует блок комментариев.
  • Текст, начинающийся с «//» и до конца строки, является комментарием.

• Поддерживается дополнительная запятая после последнего значения в массиве или в объекте.

Поля и параметры

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

«AppDescription» – текстовое описание/название зонда (кириллица поддерживается). Данное поле описывает зонд, например, адрес его расположения. Данная информация появится в виде записи в левой колонке «Зонды» вашего браузера (работа с сервером).

«uri» & «addr» — пути к анализируемым потокам. Существует несколько вариантов указания URI (групп URI). Пожалуйста, обратитесь к примерам в конце данного параграфа.

Поддерживаются следующие префиксы: file://, udp://, rtp://, http://. Кроме этого, поддерживается формат HLS (URL должен оканчиваться на .m3u или. m3u8).

Каждому потоку можно присвоить название, заполнив поле «name» (кириллица поддерживается).

Дополнительно существует возможность связать URI (группы URI) с определенным сетевым интерфейсом путем указания параметра «iface».

Если в конфигурации задана группа URI, в случае истечения срока действия подписки, будет анализироваться только один поток из списка.

«proxy» – указывает proxy сервер для коммуникации Boro-зонда с сервером.

«defaultBindAddress» – определяет NIC IP адрес по умолчанию. Данный параметр позволяет принимать потоки из различных сетей без редактирования таблицы маршрутизации.

«iface» – связывает указанный URI (группу URI) с сетевым интерфейсом.

«name» – имя потока (например, название канала).

Примеры

Пример указания задач «в строку», поля URI и name. Поле defaultBindAddress будет распространяться на все задачи в списке. Таким способом удобно формировать конфигурационный файл в редакторах таблиц:

{
        "config":       {
                        "AppDescription":       "Elecard probe",
                        "server": "https://boro.elecard.ru"
                        "defaultBindAddress": "192.168.0.129",
                        "uri": [
        {"addr": "udp://239.0.0.22:1234","name": "Channel_1","iface":"10.10.30.197",},
        {"addr": "udp://239.0.0.41:1234","name": "Channel_2","iface":"10.10.30.197",},
                                        {"addr": "udp://239.0.0.71:1234","name": "Channel_3",},
                                        {"addr": "udp://239.0.0.73:1234","name": "Channel_4",},
                                        {"addr": "udp://239.0.0.181:1234","name": "Channel_5",},
                        ]
        }
}

Аналогичный пример, разбитый на строки:

{"config": {
"AppDescription": "Test Probe, Russia, Tomsk, 3 Razvitiya ave",
"defaultBindAddress":"192.168.0.129",
"uri": [
        {
          "addr":"udp://239.0.0.22:1234",
          "name":"Channel_1",
          "iface":"10.10.30.197",
        },
        {
          "addr":"udp://239.0.0.41:1234",
          "name":"Channel_2",
          "iface":"10.10.30.197",
        },
        {
          "addr":"udp://239.0.0.73:1234",
          "name":"Channel_4",
        },
],
//"proxy": "http://10.192.173.239:3128",
}}

Другие варианты назначения задач:

{"config": {
        "AppDescription": "Test Probe, Russia, Tomsk, 3 Razvitiya ave",
        "defaultBindAddress":"192.168.0.129",

//sample #1  Single URI
"uri":"file:///opt/serga/myWorkLog/2015/02/02.19/scte35/mpegwithscte35.ts",

//sample #2  groupe of URI
        "uri": [
"http://tv2.seversk.ru:8005/stream/1kanal",
"udp://235.0.0.2:1234",
"udp://235.0.0.1:1234"
        ],

//sample #3 mix type
        "uri": [
{
"addr":"udp://234.4.4.4:1234",
"name":"1st channel",
"iface":"192.168.4.8",
},
{
        "addr":"http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3356/mpegwithscte35.ts",
"name":"2nd channel",
"iface":"172.16.1.59",
},
"http://95.170.157.5:8880/eda.m3u8",
"http://95.170.157.5:80/channel84.m3u8",
        ],

//sample #4 mix type
        "uri": [
{
"addr":[
"udp://235.0.0.1:1234",
"udp://235.0.0.3:1234",
"udp://234.5.5.57:10200"
],
"iface":"10.10.30.231",
},
{
"addr":"udp://235.0.0.4:1234",
"name":"3rd channel",
"iface":"10.10.30.231",
},
"http://95.170.157.5:8880/eda.m3u8",
"http://95.170.157.5:80/channel84.m3u8",
        ],
}}

2.5.1. Q: Как определить, вижу ли я мультикаст на своей машине?¶

A0: Попытаться запустить зонд и поставить ему задачу анализировать нужный мультикаст поток.

A1: Достаточно простой способ: попытаться проиграть поток в сетевом плеере (например, в vlc плеере).

Если поток начинает проигрываться, это означает, что вещание доходит до вашего компьютера и может быть принято Boro зондом.

Если поток плеером не проигрывается, это еще не означает, что вы не получаете мультикаст. Возможно, у вас неправильно (иначе) настроена таблица маршрутизации. Для обхода правил маршрутизации, Boro использует прямое указание сетевого интерфейса: заполните правильно поле “IP адрес интерфейса” и проверьте, принимает ли Boro зонд данные. Если поле “IP адрес интерфейса” оставлено пустым, зонд будет принимать данные согласно таблице маршрутизации.

A2: Другим способом является попытка “сдампить” поток утилитой socat. Подробнее об утилите и пример команды читайте в разделе Q: Как “сдампить” мультикаст поток, для дальнейшего анализа?. Если дамп создается успешно, это означает, что вы принимаете поток. Если файл дампа создается, но в него ничего не записывается (размер файла равен 0), это означает, что вы по каким-либо причинам не получаете указанный поток в user space.

A3: Если вы испытываете проблемы с приемом мультикаста зондом Boro, ознакомьтесь с двумя вариантами ситуации ниже

2.5.2. Почему Boro «не видит мультикаст», плеер на этой машине играет поток!¶

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

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

Пример правильного указания URI: udp://235.0.0.5:123.

Примеры адреса с ошибкой: udp://235.0.0:5:1234 или udp://235.0.0.0.5:1234

A2: Второй типичной ошибкой является указание неправильного IP адреса интерфейса. Проверьте правильность указания IP адреса, убедитесь, что данный интерфейс все еще присутствует в системе и, что именно данный интерфейс используется для приема мультикаста. В качестве адреса могут выступать IP сетевых карт, виртуальных интерфейсов и адрес 127.0.0.1 (т.н. localhost). Если адрес не задан, потоки будут приниматься согласно системной таблице маршрутизации.

Данная ошибка часто возникает при копировании конфигов анализаторов с одной машины на другую. Мы рекомендуем для данных целей использовать удобный инструмент управления и сохранения конфигураций зонда, доступный на странице настройки зонда. Кнопки “Сохранить конфигурацию зонда” и “Применить конфигурацию зонда”.

2.5.3. Почему Boro «не видит мультикаст», плеер на этой машине не играет поток¶

A0: Необходимо разобраться, доходит ли мультикаст вещание до машины или нет. Для этого необходимо выполнить два шага:

1. Подписаться на мультикаст группу.
2. Исследовать трафик на необходимом сетевом интерфейсе.

Linux

Для установки утилит и пакетов используйте пакетный менеджер, соответствующий вашей операционной системе (в основном всегда требуются привилегии суперпользователя).
Подписаться на мультикаст группу можно следующей командой (в одну строку):

socat -u UDP4-RECV:7777,ip-add-membership=<MULTICAST_IP>:<NIC_IP>,reuseaddr CREATE:/dev/null

Проследить трафик можно несколькими способами, все они связаны с захватом трафика (т.н. packet capture) в обход всевозможных системных фильтров. Кроме этого, можно использовать т.н. Promiscuous mode — режим, в котором сетевая карта позволяет принимать все пакеты независимо от того, кому они адресованы.

1. Утилита iftop в promiscuous mode. Руководство(rus). Пример команды:

   iftop -p -i <INTERFACE_NAME> -F <MULTICAST_IP>/32
   

   В таблице должна отобразиться строка с указанной группой.

2. Утилита tcpdump. Руководство. Пример команды(в одну строку):

   tcpdump -i <INTERFACE_NAME> dst <MULTICAST_IP> and udp dst port <MULTICAST_PORT>
   

   Должен отобразиться список принимаемых пакетов (необходимо подождать 10-20с) по указанному MULTICAST IP.

Windows

Подписаться на мультикаст группу можно, запустив поток в vlc плеере или начав дампить поток с помощью утилиты socat (описание в Q: Как “сдампить” мультикаст поток, для дальнейшего анализа?).

Для отслеживания трафика рекомендуется использовать следующие утилиты:

1. Утилита WinDump. Скачать. Руководство. Требует установки драйвера WinPcap.
   Команда идентична команде, описанной для ОС Linux:

   WinDump.exe -i <INTERFACE_INDEX> dst <MULTICAST_IP> and udp dst port <MULTICAST_PORT>
   

   Единственным отличием является указание имени адаптера — для версии Windows используются индексы, которые можно получить командой:

2. Программа WireShark. Загрузить программу и прочитать руководство по использованию вы можете на официальном сайте www.wireshark.org

Если вы не видите трафика, то потенциальные проблемы могут крыться в источнике мультикаст вещания, сетевом оборудовании или проблемах с подпиской по протоколу IGMP.

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

A1: Если сниффер видит трафик, необходимо проверить влияние Firewall (Brandmauer).

Linux

Для проверки влияния firewall можно его временно отключить:

• ufw disable для Ubuntu,
• systemctl stop firewalld для CentOS 7.

В CentOS 7 вместо отключения firewall можно использовать один из способов:

1. Добавить разрешения для всех входящих igmp и мультикаст udp пакетов на всех интерфейсах:

   firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m udp -p udp -m pkttype --pkt-type multicast -j ACCEPT
   firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p igmp -j ACCEPT
   firewall-cmd --reload
   

2. Переместить интерфейс с мультикастами в доверительную зону (в терминах FirewallD on CentOS):

   firewall-cmd --zone=trusted --change-interface=<INTERFACE_NAME>
   

Windows

Случается, что брандмауэр Windows блокирует доступ к мультикаст вещанию. Разрешите использовать частные и публичные сети для работы streamMonitor.exe (установите две галочки в Брандмауэре Windows).

A2: Reverse Path Filtering (Linux only) — это механизм, проверяющий “маршрутизируемость” до отправителя пакета (ссылка). Помогает отключение данного фильтра.

Для проверки можно отключить так:

echo 0 >/proc/sys/net/ipv4/conf/<IFACE>/rp_filter
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter

Где <IFACE> имя интерфейса, для которого производится отключение фильтра.

Если дело в Reverse Path Filtering, то для отключения фильтра навсегда, нужно внести правки в sysctl.conf (<IFACE> нужно поменять на имя интерфейса) следующим образом

cat >>/etc/sysctl.conf <<EOF
# disable RP filter:
net.ipv4.conf.<IFACE>.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
EOF

A3: Использование порта меньше 1024 в Linux требует повышенных привилегий (root user). Порты из этого набора считаются системными во многих ОС, поэтому зонд не сможет получать данные (“сбиндиться”). Зонд будет выдавать подобный лог в консоль:

09:08:28 source_udp_start()[258]: Creating UDP/RTP receiver for 224.1.5.172:1001 (bind iface 172.16.67.10)
09:08:28 small_rtp_init_receiver()[254]: ERROR: bind failed, err 0xD
09:08:28 small_rtp_init2()[414]: ERROR: small_rtp_init_receiver: failed
09:08:28 source_udp_start()[279]: ERROR: small_rtp_init failed with code -1

Самое простое решение — запускать зонд от root.

2.5.4. Q: Как “сдампить” мультикаст поток, для дальнейшего анализа?¶

A: Самый простой способ “сдампить” (сохранить в .ts файл) мультикаст поток — утилитой socat.

Windows

Сборку socat для Windows можно скачать тут. Руководство. На момент написания статьи была протестирована версия socat 2.0.0 (beta 5) под управлением Windows 8.1.

Пример команды (в одну строку):

socat -u UDP4-RECV:<PORT>,ip-add-membership=<MULTICAST_IP>:<NIC_IP>,reuseaddr CREATE:dump_name.ts

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

Linux

Утилита socat. Руководство. Пример команды (в одну строку):

socat -u UDP4-RECV:<PORT>,ip-add-membership=<MULTICAST_IP>:<NIC_IP>,reuseaddr CREATE:dump_name-`date +'%F-%H.%M'`.ts

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

2.5.5. Версии протокола IGMP¶

A: Принудительно выбрать версию протокола IGMP в Linux можно командой:

echo 2 > /proc/sys/net/ipv4/conf/eno2/force_igmp_version

2.6.1. Графики¶

Download rate – график, отображающий скорость загрузки по протоколам HTTP/HTTPS. Для HLS-потоков скорость загрузки характеризуется отношением размера сегментов данных ко времени их скачивания.

Multicast Rate – график, отображающий общий битрейт входящего UDP/RTP.

Bitrate – график, отображающий битрейт потоков, как несущих полезную нагрузку (аудио и видео потоков), так и служебных потоков с EIT таблицами и PID 0x1fff, используемого для заполнения потока до фиксированного битрейта (т. н. «нули», null packet, padding).

EPSNR – график, отображающий статистическую оценку степени искажения цифровых видеоданных при их кодировании. Измеряется в децибелах и определяется отношением пикового квадратичного значения видеосигнала к среднеквадратическому отклонению декодированного изображения от исходного. Величина EPSNR (Estimated Peak Signal to Noise Ratio) оценивается на основании данных, содержащихся в закодированном видеопотоке, и не требует наличия исходных (незакодированных) видеоизображений. EPSNR применяется для оценки качества работы енкодеров. Для оценки можно принять следующие величины: 25-30dB — плохое качество, 45-50dB — хорошее качество.

Maximum Inter-packet Arrival Time (IAT) : Media Lose Rate (MLR) — сводный график параметров IAT и MLR. Данный график отображается только для мониторинга IPTV. Позволяет детально оценивать потери и джиттер сигнала на сетевом уровне. На графике расположены две горизонтальные линии, отображающие пороги предупреждения и ошибки параметра IAT. Применяется четырехуровневая цветовая схема. Зеленый цвет означает, что значения находятся ниже порога предупреждения, желтый — значения выше порога предупреждения, но ниже порога ошибки, оранжевый — значение IAT превышает порог ошибки. Отсутствие сигнала отображается красным цветом.

Пороги обоих параметров задаются в разделе настроек оповещения проекта, на вкладке Thresholds.

MDI [Delay factor (DF) : Media Loss Rate (MLR)] — сводный график параметров Delay factor (DF) и MLR, т.н. Media Delivery Index (MDI). График позволяет оценить качество доставки сигнала на основе двух параметров: потери пакетов и косвенного анализа джиттера сигнала (на базе вычисления DF).

Continuity Counter Errors — график распределения CC ошибок (TR 101 290 error 1.4 Continuity Counter) во времени.

Clock Continuity Errors — график распределения ошибок ClockContinuity во времени.

2.6.2. Эскизы¶

Thumbnails – захват эскизов видеопотока с настраиваемым интервалом времени между снимками. Дополнительно настраивается интервал между снимками в период рекламы, обозначенный метками SCTE35. Для активации захвата эскизов необходимо установить галочку «Захват эскизов» в форме постановки задачи.

2.6.3. Параметры, события и ошибки¶

Mapping — массив чисел, обозначающих количество TS пакетов внутри одного IP пакета, которые были обнаружены за последние 3 секунды, в порядке, пропорциональном частоте появления. Обычно 7 транспортных пакетов упаковываются в один IP пакет.

TOS/DSCP — Type-of-service, поле в IP заголовке. Может трактоваться совершенно по разному в различном оборудовании.

TTL — Time to live

Src address/Src MAC — IP и MAC адреса источника мультикаст вещания.

Dst MAC — Destination MAC. Для доставки мультикаста по IPv4 используется пул Ethernet MAC адресов 01:00:5e:00:00:00–01:00:5e:7f:ff:ff. Более подробную информацию можно найти, перейдя по ссылке.

Maximum Inter-packet Arrival Time (IAT) – график, отображающий максимальное время между приходящими пакетами. Джиттер может быть охарактеризован при помощи проверки времени между приходящими пакетами. Максимальное время между приходящими пакетами (IAT) является суммой среднего времени между пакетами и джиттером. Фиксируется максимальное значение IAT за секунду. Измеряется в миллисекундах. Подробнее о данном параметре можно прочитать в параграфе Q: Что такое Maximum Inter-packet Arrival Time (IAT)?.

MinIAT – минимальное значение времени между приходящими пакетами (IAT), зафиксированное за одну секунду измерений. Измеряется в миллисекундах.

AvgIAT – среднее значение времени между приходящими пакетами (IAT), вычисляемое на интервале в одну секунду. Измеряется в миллисекундах. Получаемое значение AvgIAT приближено к расчетному значению IAT для Constant bitrate потока с постоянном mapping равным 7.

MDI Media Delivery Index [Delay factor (DF) : Media Loss Rate (MLR)] — индекс, который может быть использован как индикатор качества при мониторинге сети доставки вещания видеосервисов, чувствительной к джиттеру и потере данных. Определяется джиттером потока, характеризуемым как отклонение битрейта от ожидаемого значения (флуктуация), и потерями данных потока (MLR). Флуктуация битрейта, вызванная джиттером и потерями данных, может быть определена как относительная глубина буфера (DF), необходимого для приема такого потока.

Several broadcasters — несколько источников мультикаст вещания в одной группе.

EIT — на сервер передается содержимое EIT таблиц.

ProgramSpecificInformation – на сервер передается описание о программах (PAT, PMT и SDT), входящих в анализируемый поток. На основе полученных данных может быть построена сервисная таблица. Также в данном событии передается информация о типе (поле type) и криптованности составляющих потоков, корректности потока и наличии PCR.

PCR – (Program Clock Reference) указывает на наличие меток синхронизации в составляющем потоке. Отображается во всплывающем окне «информация о сервисе» в виде часов. Информация о таких потоках приходит в PSI (ProgramSpecificInformation) событии.

PcrError – ошибка, в потоке полностью отсутствуют PCR метки.

Зашифрованный поток – отображается в виде символа замочка напротив соответствующего элементарного потока во всплывающем окне «информация о сервисе». Также символ замочка может отображаться на различных видах, указывая на то, что в потоке имеются признаки шифрования. Информация о шифрованности приходит в PSI (ProgramSpecificInformation) событии. Для таких потоков не производится анализ замирания картинки, захват эскизов, вычисление EPSNR.

Некорректный элементарный поток – (Invalid ES) отображается в виде символа молнии напротив соответствующего элементарного потока во всплывающем окне «информация о сервисе». Если для элементарного видео потока анализатор получает данные на заявленном PID, но в течении 10-20 секунд нет ни одного видео заголовка (SPS, PPS), такому потоку присваивается метка Invalid ES (возможно, поток шифрованный или используются произвольные данные). Информация о таких потоках приходит в PSI (ProgramSpecificInformation) событии. Для таких потоков не производятся: анализ замирания картинки, захват эскизов, вычисление EPSNR.

VideoInformation – на сервер передается описание заголовков видеопотоков. На основе полученных данных строится таблица во всплывающем окне «информация о видеопотоке». В таблице отображаются такие параметры, как формат кодирования, разрешение, количество кадров в секунду, соотношение сторон кадра и пр.

Download rate – скорость загрузки по протоколам HTTP/HTTPS.

Multicast Rate – сетевой битрейт входящего UDP/RTP потока.

Bitrate – величина текущего битрейта (усредненного за 1с) всех элементарных потоков, входящих в MPEG TS. Отображается во всплывающем окне «информация о сервисе» и в режиме TableView.

Min/Max bitrate – минимальная и максимальная величины битрейта всех элементарных потоков, входящих в MPEG TS. Отображается во всплывающем окне «информация о сервисе» и исчисляется с момента открытия окна.

Average bitrate – средний битрейт элементарного видеопотока за интервалы времени 5, 20 и 60 секунд. Отображается во всплывающем окне «информация о видеопотоке». Исчисляется с момента открытия окна.

Info/Stop – регистрируются события появления данных на входе зонда и момент передачи команды на остановку.

BadSource – регистрируется событие, когда зонд не может получать данные для анализа по какой-либо причине. Для разных типов доставки существуют разные критерии:

• для UDP/RTP — это отсутствие данных на входе в течение более, чем 1с;
• для HLS — это невозможность скачать сегмент по нескольким причинам:

– отсутствие изменений в плейлисте. Производится 3 попытки скачивания плейлиста с интервалом, равным длительности последнего сегмента. Если во всех трех попытках в плейлисте не произошло изменений — регистрируется BadSource;

– для HTTP/HTTPS — это нулевая скорость загрузки (download rate) в течение определенного времени, в среднем около 5с. За это время анализатор опустошает входной буфер.

VideoFreeze – анализируется замирание видео. Отображается синим цветом на виде LiveView и символом снежинки в области эскизов или поля “детали”. Анализ производится в два этапа. Производится проверка отношения размера I кадров к P кадрам. Когда это отношение превышает установленное пороговое значение, декодируются два соседних I кадра, которые сравниваются по точкам. Для активации анализа замирания необходимо установить галочку «Фиксация VideoFreeze» в форме постановки задачи.

SCTE35 – фиксируется метка в виде записи события в журнале, согласно стандарту ANSI/SCTE 35. Например: (SCTE35 00:01:01.157 {«event_id»=>662, «duration»=>242, «out_of_network_indicator»=>true, «pts_time»=>89742.159644})

ClosedCaption – под этими событиями отсылаются на сервер субтитры из видео. Поддерживаются стандарты CEA-608 и CEA-708.

CC ошибки – Continuity Counter (TR 101 290 error 1.4). Отображаются в таблице окна «информация о сервисе» в трех полях:

• количество ошибок с момента открытия окна;
• количество ошибок за последний час;
• количество ошибок с момента начала анализа данного потока.

TR_101_290_errors (priority 1) – группа ошибок первого приоритета согласно стандарту ETSI TR 101 290 (на английском языке). Ошибки отображаются на странице задачи в виде групп квадратов зеленого (или красного, в случае активного состояния ошибки) цвета. Также, если в потоке присутствуют ошибки, на эскизе или в поле “Детали” отображается символ “TR”.

• TS_Sync_Loss – фиксируется при детектировании двух и более идущих подряд ошибок Sync_Byte_Error (см. ниже). Данная ошибка пропадает при последовательном обнаружении пяти и более синхробайтов (считается, что синхронизация установлена).
• Sync_Byte_Error – отсутствие синхробайта 0x47 в следующем пакете (после 188 или 204 байт).

• PAT_Error – возникает при следующих условиях:

  • PID 0x0000 не появляется каждые 0,5с (настраиваемая величина);
  • PID 0x0000 не содержит секцию с table_id 0x00 (т.н. PAT таблица);
  • поле Scrambling_control_field, не равно 00 для PID 0x0000.

• Continuity_Count – возникает при следующих условиях:

  • неправильный порядок следования пакетов;
  • один и тот же пакет появляется последовательно более, чем два раза;
  • потеря пакетов.

• PMT_Error – возникает при следующих условиях:

  • секция с table_id 0x02 (т.н. PMT таблица) не появляется каждые 0,5с (настраиваемая величина) на PID, назначенном для этой цели в таблице PAT;
  • поле Scrambling_control_field, не равно 00 для всех PID, содержащих секции с table_id 0x02 (т.н. PMT таблицы).

Установка нуля в настройке порогов отключает детекцию PMT Error.

• PID_error – данные для указанного PID не появляются в течение установленного пользователем времени (по умолчанию 5с). Означает частичную потерю сервиса или ошибки в PAT/PMT. Отдельно ошибка настраивается и генерируется для элементарных потоков, которые являются видео или аудио. Установка нуля в настройке порогов отключает детекцию PID Error / AV PID Error.

TR_101_290_errors (priority 2) – группа ошибок второго приоритета согласно стандарту ETSI TR 101 290 (на английском языке). Реализована частично.

• Transport_error – фиксируется, если поле Transport_error_indicator установлено в 1 в TS заголовке.

ClockContinuity – регистрируется разрыв временных меток видеопотока. ClockContinuity отслеживает равномерность временных меток PTS/DTS в потоке, определяет наличие резких скачков и обратного прироста времени (обычно связано с потерями пакетов и/или в результате склейки потока). В отличие от ошибки “Период повторения PTS меток более, чем 700 мс (ETSI TR 101 290 Second priority 2.5 PTS_error)”, ClockContinuity — это анализ меток синхронизации, а не наличие данных через установленный период (maxPTSInterval) времени. Установка нуля в настройке порогов отключает детекцию ClockContinuity.

2.6.4. Параметры OTT¶

Resolution – разрешение (Ш x В) кадра профиля, заявленное в главном плейлисте.

Bandwidth – битрейт профиля, заявленный в главном плейлисте. Отображается в битах в секунду.

Actual bitrate – средний битрейт сегмента. Рассчитывается как: размер сегмента (Segment size) / длительность сегмента (Segment duration). Отображается в мегабитах в секунду (Mb/s).

Download speed – средняя скорость скачивания сегмента. Рассчитывается как: размер сегмента (Segment size) / время скачивания сегмента (Download time). Отображается в мегабитах в секунду (Mb/s).

Segment duration – длительность скачанного сегмента данных, заявленная в плейлисте второго уровня (Media Playlist). Отображается в секундах.

Download time – время, затраченное на скачивание сегмента данных. Отображается в секундах.

Segment size, B – точный размер скачанного сегмента. Отображается в байтах.

Segment size, MB – оценочный размер скачанного сегмента. Отображается в мегабайтах.

Start with an IDR frame – если сегмент не зашифрован и не сброшен перед началом анализа, то зонд производит проверку на наличие IDR кадра в начале сегмента (требование HLS спецификации). Если сегмент начинается с IDR кадра, то значение — OK, если нет, значение — Error.

INDEPENDENT tag – логический тип, Yes означает наличие #EXT-X-INDEPENDENT-SEGMENTS тега в Master или Media плейлистах.

2.6.5. События и ошибки OTT¶

HlsEvent – регистрация события скачивания очередного сегмента данных протокола HLS. Фиксируется время и дата скачивания, название, размер, длительность и порядковый номер сегмента. Размер сегмента и время его скачивания характеризуют скорость скачивания.

Profile changed (HlsBandwidthSwitched) – зафиксировано переключение на профиль с другим битрейтом. Только для анализатора в режиме «Плеер».

The number of profiles changed (HlsNumberOfProfilesChanged) – зафиксировано изменение количества профилей в плейлисте верхнего уровня (Master Playlist).

Minimum profiles (HlsMinimumProfiles) – количество профилей, заявленных в главном плейлисте, меньше, чем минимальное значение, заданное в настройках порогов.

Profiles sequence divergence (HlsSequenceDivergence) – зафиксировано расхождение значения полей #EXT-X-MEDIA-SEQUENCE в плейлистах второго уровня (Media Playlist).

Profile streamtype changed (HlsProfileStreamTypeChanged) – изменилась информация о профиле в плейлисте верхнего уровня (Master Playlist).

Profile duplicate bandwidth (HlsDuplicateBandwidth) – в плейлисте верхнего уровня (Master Playlist) заявлены одинаковые максимальные битрейты для разных профилей (поля BANDWIDTH).

Profile invalid resolution (HlsInvalidResolution ) – зафиксировано некорректное разрешение в поле RESOLUTION плейлиста верхнего уровня (Master Playlist).

(LowDownloadrate) – время закачки чанка больше, чем длительность самого чанка. В Elecard Boro событие используется для отображение недостататка скорости скачивания на виде LiveView.

Download bitrate low (HlsDownloadSpeed = «Warning») – Низкая скорость скачивания чанка. Генерируется предупреждение, когда скорость скачивания ниже, чем установленный порог Download speed warning (download_speed_warning), выраженный в процентном отношении. Время загрузки / длительность чанка >= порог предупреждения (%). Порог предупреждения не может быть выше порога ошибки.

Download bitrate too low (HlsDownloadSpeed = «Error») – слишком низкая скорость скачивания чанка. Генерируется ошибка, когда скорость скачивания ниже, чем установленный порог Download speed error (download_speed_error), выраженный в процентном отношении. Время загрузки / длительность чанка >= порог ошибки (%).

Actual bitrate (HlsActualBitrate = «Error») – средний битрейт скачанного сегмента больше или меньше заявленного в границах, установленных пользователем. Actual bitrate min (actual_bitrate_min) задает нижнюю границу, и Actual bitrate max (actual_bitrate_max) – верхнюю границу в процентах. Условие генерации ошибки по нижней границе: Размер скачанного чанка / заявленная длительность <= заявленного битрейта профайла (%). Условие генерации ошибки по верхней границе: Размер скачанного чанка / заявленная длительность >= заявленного битрейта профайла (%).

Bad segment size (HlsBadSegmentSize ) – ошибочный размер сегмента данных. Битрейт сегмента в 50 раз превышает максимальный битрейт, указанный в поле BANDWIDTH в главном плейлисте (Master Playlist).

Manifest sequence discontinuity (HlsSequenceNumberDiscontinuity) – зафиксирована потеря одного или нескольких плейлистов с потерей HLS сегментов. Ошибка фиксируется в случае, если номер полученного плейлиста отличается от предыдущего более, чем на 1, и, при этом, были потеряны сегменты данных. Данная ошибка может быть вызвана как проблемами в генерации и раздаче OTT контента, так и недостаточной производительностью зонда.

Static manifest (HlsStaticManifest) – плейлист второго уровня не обновился в течение нескольких скачиваний подряд. Число попыток задается пользователем в Number of identical playlist (sequance_age). Между попытками выдерживается пауза, равная длительности последнего скачанного сегмента.

Manifest error (HlsManifestError) – ошибка обработки/разбора плейлиста или несоответствие содержимого плейлиста стандарту. Содержимое плейлиста, которое не удалось разобрать, возвращается. Также ошибка генерируется, если версия плейлиста выше поддерживаемой.

Unknown manifest (HlsUnknownManifest ) – неизвестный манифест. Возвращаются возможные причины ошибки (TARGETDURATIONMissing, EXTM3UMissing, PlaylistEmpty).

Manifest size (HlsManifestSize) – размер плейлиста превышает пороговое значение Manifest size (manifest_size), установленное пользователем.

Manifest download failure (HlsFailedDownloadPlaylist) – ошибка, при которой приемник не может скачать плейлист первого или второго уровня, дополнительно возвращается HlsCurlError или HlsHTTPError.

Key download failure (HlsFailedDownloadKey) – ошибка получения ключа для зашифрованного сегмента, дополнительно возвращается HlsCurlError или HlsHTTPError.

Segment download failure (HlsFailedDownloadChunk) — ошибка, при которой приемник не может скачать сегмент данных, дополнительно возвращается HlsCurlError или HlsHTTPError.

Curl error (HlsCurlError) – код ошибки приема HLS и ее описание, возвращаемые модулем libcurl. Подробнее об ошибках можно узнать на официальной странице проекта libcurl.

HTTP error (HlsHTTPError) – ошибка приема HLS, возвращается код HTTP ошибки.

2.6.6. Системные ошибки¶

Error – группа системных ошибок и ошибок общего плана:

• “Buffer overflow, data skipped” – данные сбрасываются перед декодером. Такая ситуация возникает в результате недостаточной производительности системы. Необходимо отметить, что данные сбрасываются уже после прохождения анализа на целостность сигнала (TR 101 290) и вычисления битрейта, поэтому данная ошибка не влияет на результаты вычисления целостности. Это утверждение также применимо для OTT: данные сбрасываются перед декодированием, не влияя на вычисление скорости загрузки сегментов и детектирование OTT ошибок. Сброс данных может появиться при вычислении следующих параметров: ошибки замирания картинки, захват эскизов и вычисление EPSNR.
• “Resumption” – фиксируется событие перезагрузки дочернего процесса, анализирующего поток, родительским процессом, так как он не отвечал в течении 10с. Главный процесс следит за работоспособностью всех задач анализатора (дочерних процессов) и, в случае критической ошибки, производит перезапуск с восстановлением состояния.
• Skip segment (HlsSkipSegment) – пропущен сегмент данных, очередь скачанных сегментов превысила установленное значение. Недостаточная производительность зонда, скорость скачивания чанков превышает скорость их обработки.

2.7.1. Ethernet параметры и библиотека pcap¶

К Ethernet параметрам относятся: Inter-packet Arrival Time (IAT), Delay Factor (DF), Media Loss Rate (MLR), Type-of-service (TOS/DSCP), Time to live (TTL), destination MAC, source IP/MAC, mapping. Вычисление указанных параметров базируется на сторонней библиотеке libpcap для Linux приложения или winpcap для Windows приложения. Анализатор не будет вычислять указанные параметры, если в системе не установлена соответствующая библиотека. Кроме этого, для системы Linux, зонд должен запускаться с правами суперпользователя (sudo ./streamMonitor).

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

2.7.2. Q: Ограничения на вычисление Ethernet параметров в зависимости от ОС?¶

2.7.3. Q: Что такое Maximum Inter-packet Arrival Time (IAT)?¶

A: Maximum Inter-packet Arrival Time (IAT) – максимальное время между приходящими пакетами. Джиттер может быть охарактеризован при помощи проверки времени между приходящими пакетами. Максимальное время между приходящими пакетами (IAT) является суммой среднего времени между пакетами и джиттером. Фиксируется максимальное значение IAT за секунду.

2.8.1. Общая информация¶

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

В данном параграфе описываются несколько свойств контроллеров, и приводится сводная таблица с особенностями ряда контроллеров, которая поможет вам осуществить выбор. При выборе контроллера необходимо учитывать и понимать следующие пункты.

2.8.2. Как узнать какой контроллер/адаптер у меня установлен (Linux)?¶

Подробно информация изложена в информационной статье на сайте losst.ru

Коротко можно указать следующие команды.

Просмотр всех, подключенных к системе интерфейсов: название, описание и производитель адаптера, скорость, драйвер и прочее:

Продукт и имя производителя вашей сетевой карты:

Информация о адаптере eth0 (указать свой): настройки, статус соединения, скорость и пр.:

Информация о драйвере:

2.8.3. Как узнать, поддерживает ли мой сетевой адаптер hardware timestamping?¶

Полезные ссылки: http://www.tcpdump.org/manpages/pcap-tstamp.7.html

A1: Посмотреть поддерживаемые режимы выставления меток времени можно с помощью утилиты tcpdump:

tcpdump -J -i <INTERFACE_NAME>

Пример исполнения команды:

[root@localhost ~]# tcpdump -J -i enp2s0
Time stamp types for enp2s0 (use option -j to set):
  host (Host)
  ADAPTER (ADAPTER)
  ADAPTER_UNSYNCED (ADAPTER, NOT SYNCED WITH SYSTEM TIME)

Выделены режимы, в которых сетевой адаптер проставляет метки времени.

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

Sniff interface — имя интерфейса, который захватывает пакеты.

UseHWTimeStamps() — информация о поддержке hardware time stamping адаптером. Одно из двух сообщений ниже означает, что есть поддержка HW time stamps:

Sniffer use timestamp type: adapter (3)

Sniffer use timestamp type: adapter_unsynced (4)

2.8.4. Q: Как узнать запущена ли балансировка прерываний адаптера (Linux)?¶

Как указано в статье о Receive-Side Scaling (RSS), для проверки, распределены ли прерывания интерфейса на различные ядра, можно воспользоваться следующим способом:

egrep 'CPU|p1p1' /proc/interrupts,

где p1p1 имя исследуемого интерфейса.

Если в ответе на команду будет несколько строк, например так:

   CPU0    CPU1    CPU2    CPU3    CPU4    CPU5
89:   40187       0       0       0       0       0   MSI-edge   p1p1-0
90:       0     790       0       0       0       0   MSI-edge   p1p1-1
91:       0       0     959       0       0       0   MSI-edge   p1p1-2
92:       0       0       0    3310       0       0   MSI-edge   p1p1-3
93:       0       0       0       0     622       0   MSI-edge   p1p1-4
94:       0       0       0       0       0    2475   MSI-edge   p1p1-5

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

Если в ответе только одна строка, например так:

                  CPU0       CPU1
27:        108    1595151   PCI-MSI-edge      enp2s0

это означает, что задействована только одна очередь. Либо адаптер не поддерживает несколько очередей, либо не настроено распределение/балансировка прерываний.

Проверить, запущен ли irqbalance на CentOS 7 (входит в стандартную сборку), можно командой: systemctl -l status irqbalance.service.

Если в ответе Active: active (running), значит демон запущен и работает.

Подробнее о настройке irqbalance можно прочитать в официальной документации RedHat.

2.9.1. Может ли Boro мониторить различные карточки захвата, например, ASI/SDI/HDMI?¶

A: Boro может мониторить только IP потоки и файлы TS. Но, если поток с карточки может быть доставлен в IP, например в интерфейс localhost, тогда можно проводить измерения. Это касается только карты ASI.

2.9.2. Есть ли поддержка анализа DVB сигнала?¶

A: Boro не поддерживает карты захвата DVB сигнала. Однако реализована и испытана следующая схема построения анализатора:

Применяются карты захвата под управлением ПО Elecard CodecWorks Encoder. Транспортный поток направляется в localhost или в один из доступных сетевых интерфейсов, откуда, его захватывает анализатор Boro. Поток может быть как в исходном MPTS формате с различными таблицами, так и ремультиплексированным на SPTS потоки. Поддержки формата T2MI нет.

CodecWorks Encoder поддерживает следующие карты захвата DVB:

• igital Devices DuoFlex C2T2 (DVB-T/T2/С);
• Behold TV T8 (DVB-T/T2/С);
• AVerMedia Nova T2 (DVB-T/T2).

2.10.1. Анализатор постоянно падает, система “тормозит”, на LiveView периодически регистрируются хаотичные состояния BadSource¶

A: Стоит обратить внимание на утилизацию оперативной памяти, особенно при большом количестве запущенных задач и использовании декодера (включена одна или несколько опций: вычисление EPSNR, захват эскизов, анализ замирания картинки). Процессы приложения начинают вытесняться в swap, и скорости не хватает для нормальной работы анализаторов (которые начинают периодически перезагружаться из-за долгого молчания).

Оценочные значения утилизации памяти:

SD: TR 101290 (only) — 34MB/stream; TR 101290 + decoder — 53MB/stream;

HD: TR 101290 (only) — 34MB/stream; TR 101290 + decoder — 105MB/stream.

2.10.2. Cистема “тормозит”, на LiveView периодически регистрируются ложные CC и ClockContinuity ошибки¶

A: Стоит обратить внимание на загрузку CPU. Особенно при большом количестве запущенных задач и использовании декодера (включена одна или несколько опций: вычисление EPSNR, захват эскизов, анализ замирания картинки). Вычисление EPSNR создает очень большую нагрузку на CPU, т.к. алгоритм требует полного декодирования видеопотоков. Производительность зависит от разрешения видеоданных в потоке и битрейта потока.

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

Оценочные таблицы производительности вы можете получить по запросу у команды технической поддержки проекта: tsup@elecard.ru.

2.10.3. Q: Значительный расход дискового пространства в Windows¶

A: Наблюдается существенный расход пространства на диске С, при детальном изучении в каталоге C:WindowsTemp создается временный файл, который продолжает стремительно расти. После остановки анализатора дисковое пространство высвобождается. Проблема проявляется при анализе потоков, получаемых по протоколу http. Причина проблемы — антивирус, установленный в операционной системе. Нами была зафиксирована проблема с NOD32 на Windows 10. В среде Internet зарегистрировано множество сообщений с подобными проблемами с различными антивирусами. Для устранения проблемы необходимо блокировать работу антивируса или деинсталлировать его.

Posts: 122

Joined: Dec 2014

Reputation:
1

Hi,

when I’ve enabled Over-The-Air EPG (within the DVB input setup), I receive consecutively the folliowing error:

This error makes a picture and sound interrupt.
Here’s an example how often the error occurs:

When I disable the over-the-air EPG, the error did not disappear, but it’s really rare then. Additionally I’ve disabled «Force EPG on startup», which makes obviously no difference.
Does anyone of you might have an idea, how to use the over-the-air EPG without these problem?

I would really appreciate any kind of help/or ideas.
Thanks in advance.

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

Posts: 806

Joined: Nov 2015

Reputation:
33

Continuity errors are essentially processing errors. They mean that packets are being decoded/assembled out of order, or that they are being dropped. This is usually the case when your hardware does not have the bandwidth/power to keep up with the stream coming in.

If you are using a network tuner (such as HDHomeRun), ensuring you are using the HDHomeRun client in Tvheadend will help (as opposed to using HTTP/IPTV streams) makes a big difference.

If your tuner is USB, make sure you have the bandwidth to handle it, especially if you are using multiple USB devices. This is most important on limited devices such as the Raspberry Pi.

The Pi is a great little board for small uses, but a bandwidth powerhouse it most certainly is not. (I find they make great clients for Kodi, but TV servers not so much.)

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

Posts: 57

Joined: Sep 2015

Reputation:
3

I’m a LibreELEC user, and had the exact same problem with the LibreELEC 8.0.x production builds.

It turned out to be that a problem was introduced in the core linux kernel for USB DVB devices and there is a long thread on this here:
https://forum.libreelec.tv/thread/4235-d…nel-4-9-x/

I’m on a reasonably powerful Generic x86 HTPC … 4x 1.8GHz processor cores, 4GB RAM, ION2 GPU. Generally when watching a TV Show my CPU is around 20% used, and I only get the continuity errors and picture break-ups in distributions that ship with a v4.9 or above kernel. At the moment I am using a LibreELEC community build with 4.8.13 kernel as provided in the thread above (have been for the past few months) and the continuity errors have gone so everything is sweet.

I really hope this gets fixed upstream so I can eventually upgrade my kernel. Reading the thread above it looks like they’ve identified the set of kernel commits where the problem was introduced, but are struggling to track down the individual commit.

My advice to you would be to downgrade your kernel to something less than v4.9.

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

Posts: 57

Joined: Sep 2015

Reputation:
3

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

@jahutchi

I’d like to thank you on this occasion (I’m not registered on the LibreELEC Forum) for your time & effort in identifying the offending kernel commit that is causing the reported issue. Amazing work!
https://forum.libreelec.tv/thread/4235-d…#post75965

On that LibreELEC thread, after the involvement of the «media guru» kernel maintainer Mauro Carvalho Chehab (mchehab):
https://forum.libreelec.tv/thread/4235-d…#post77169
and the reference to Linus’ patch for softirq.c (some links have vanished — posts might have been edited), I’ve noticed that some users were still reporting issues even after applying Linus’ patch.

I was trying to follow the development on this issue on my own on the kernel forums and found the patch Linus proposed:
https://patchwork.linuxtv.org/patch/46368/
Found also some discussions on the subject:
Vger.kernel.org/msg1581628.html» target=»_blank» rel=»noopener» class=»mycode_url»>https://www.mail-archive.com/linux-kerne…81628.html
https://lkml.org/lkml/2018/1/6/252
https://patchwork.kernel.org/patch/10150031/

Linus has some points on the issue, calling the commit «a pretty damn big hammer»:
http://lkml.iu.edu/hypermail/linux/kerne…00842.html
And then in another thread, still related to fixing softirq.c:
http://lkml.iu.edu/hypermail/linux/kerne…03838.html

Looking at the the Raspberry Foundation kernel issues list to see if this was admitted as a bug, I found out that JamesH65 has apparently found a resolution that he doesn’t want to share with anyone, just keeping it for himself:
https://github.com/raspberrypi/linux/issues/2134#
JamesH65 commented Sep 13, 2017
«Closing this issue as questions answered/issue resolved.»

But then, this kind of denial that also got me a ban (from the same JamesH65) on their forum, exactly by trying to report this very issue is not something new.

I’m still stuck with the kernel 4.4.50 ATM and was wondering if you have found a working fix for this issue. Are you happy with Linus’ softirq.c patch? Should I wait for the kernel folks to come up with some «overhauling» of softirq.c ? It looks like the last discussions on the topic in the kernel forums was in the middle of January…

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

Posts: 11

Joined: Mar 2018

Reputation:
0

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

Posts: 57

Joined: Sep 2015

Reputation:
3

@abga I double-checked in github for The Rasberry Pi Foundation kernel:https://github.com/raspberrypi/linux

It looks like they reverted the offending commit in the 4.14 branch:
https://github.com/raspberrypi/linux/com…/softirq.c   ( Revert «softirq: Let ksoftirqd do its job» )

But the same revert hasn’t been made in their 4.9 or 4.9-stable branches:
https://github.com/raspberrypi/linux/com…/softirq.c
https://github.com/raspberrypi/linux/com…/softirq.c

Looking at the tarball link you provided: https://github.com/raspberrypi/linux/arc…130.tar.gz

This references commit 80a14a56dacb7cc2b40d5f37d00bedb0ceace130 which is a commit point in the 4.14 branch
https://github.com/raspberrypi/linux/com…b0ceace130

abga



Senior Member

Posts: 149

Joined: Sep 2016

Reputation:
3

@jahutchi Thanks again for your time looking into this (mess)!
I was always staying away from kernels that were not officially released by the Raspberry Foundation, mainly because I’m looking for stability and trust them with their extensive testing before the release. That’s why I haven’t tested the new 4.14.x branch and also not planning to.
The link I provided for the source code that was used for compiling their latest official kernel release 4.9.80+ is the result/output of the rpi-source script:
https://github.com/notro/rpi-source/wiki
See this thread — I was justme123 & was looking for the kernel headers after suddenly failing (different Module.symvers) to use the ones from https://www.niksula.hut.fi/~mhiienka/Rpi…aders-rpi/
https://www.raspberrypi.org/forums/viewt…6#p1156287
This rpi-source method is apparently the only documented way to obtain the exact source code that was used for compiling the running kernel.
Now, I cannot guarantee that the source code that resulted from running the rpi-source script was the one used in the kernel compilation and this is something only the Raspberry Foundation can check. It could be that the offending commit was actually not reverted and that means that all the investigative effort was/is in vain.

If the offending commit was indeed reverted in the Raspberry Foundation official kernel release 4.9.80+, then it will mean that only reverting it is not sufficient and maybe Linus’ patch should be applied instead.
Worth to mention that I was trying this Raspberry Foundation official 4.9.80+ kernel on a Raspberry Pi 2B board, on which I was running tvheadend 4.2.5 and streaming to a remote Kodi player. On these Raspberry Pi boards the Ethernet goes also through USB (meaning that the USB subsystem was used by both the DVB adapter & Ethernet card) and the system performance (CPU) is way lower compared to the system you said you were using in a previous post «reasonably powerful Generic x86 HTPC … 4x 1.8GHz processor cores, 4GB RAM, ION2 GPU»

I’m only able to meet you and @popcornmix here on the Kodi Forum and hope that @popcornmix will see this thread/post and check what was reported.

@popcornmix  — if you’re around, please have look on what was written here. Thank you in advance!

Posts: 57

Joined: Sep 2015

Reputation:
3

It would be good to get some official confirmation. However, I’m pretty sure the offending commit was not reverted on the 4.9 2018-03-13 kernel.

You can browse the tree for the official rpi 2018-03-13 kernel here (via its tag in the 4.9-stable branch)
https://github.com/raspberrypi/linux/tre…20180313-1

From there you can get to kernel/softirq.c and view its history
https://github.com/raspberrypi/linux/com…/softirq.c

I can see theyve created a 20180328 tag which has the commit reverted but not sure if thats on the 4.14 branch.
https://github.com/raspberrypi/linux/com…/softirq.c

Back to my original advice
‘you probably still need to stick with an older kernel for now, or figure out how to patch and recompile the kernel for your O/S.’

Ive been running with vanilla kernel 4.9.x with just the troublesome commit reverted for>3months now. and everything is perfect for me.