Зонд ==== Различия и ограничения Linux и Windows версий --------------------------------------------- .. csv-table:: :header: "Свойство", "Linux", "Windows" "Вычисление Ethernet параметров(IAT/MLR/DF).", "Зонд должен быть запущен с правами суперпользователя(sudo ./streamMonitor).", "На компьютере, где запускается зонд, должна быть установлена библиотека захвата пакетов WinPcap (https://www.winpcap.org/install/)." "Вычисление Ethernet параметров для localhost (127.0.0.1).", "Ограничения нет.", "Вычисление IAT для localhost невозможно." "Вычисление Ethernet параметров на основе меток времени, проставляемых сетевым адаптером. (Высокая точность вычисления IAT).", "Поддерживается. Данный режим используется автоматически (если есть поддержка в адаптере). Подробнее в параграфе `Вычисление Ethernet параметров`_.", "Не поддерживается." Запуск и настройка зонда ------------------------ Q: Как начать работать с системой мониторинга? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Необходимо знать несколько базовых вещей: 1. Система состоит из сервера мониторинга (находится в облаке) и клиентской части - зонда, который пользователь размещает в своей сети. 2. Пользователь самостоятельно выбирает аппаратное обеспечение для зонда. 3. Вам необходимо скачать архив зонда в личном кабинете. Обратите внимание, что пакет привязан к проекту в вашем кабинете. Это означает, что запущенный зонд будет отображать данные только в проекте, из которого он был загружен. 4. Следующим шагом необходимо запустить зонд и убедиться, что он появился в системе мониторинга (выпадающая левая панель в ЛК на сервисе boro.elecard.ru). 5. Следует знать, что можно запускать несколько зондов. Количество зондов фактически ограничивается количеством анализируемых потоков в приобретенной подписке. 6. Если требуется запуск нескольких зондов на одной машине, необходимо сделать копию всей папки зонда (например папки win64), так как приложения streamMonitor, запущенные из одной папки, будут иметь конкурирующий доступ к некоторым файлам! 7. Кроме этого, следует знать, что зонд не отправляет потоки на облачный сервер в каком-либо виде. Весь анализ проводится локально. На сервер отправляются статистические данные (величина битрейта, зарегистрированные ошибки), структура потока (PSI таблица), Closed Caption и SCTE35 данные и эскизы видеопрограмм. Q: Как запустить зонд в консоли? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Для того, чтобы получить приложение, необходимо пройти несколько этапов. Более подробное описание можно найти в **Руководстве по быстрому старту**. Если вы скачали архив с приложением, для его запуска нужно осуществить следующие действия: **Linux** 1. Скопируйте скачанный архив зондов в необходимый каталог на Linux машине. 2. При необходимости установите пакет **unzip**. Пример инсталляции на CentOs:: sudo yum install unzip 3. Перейдите в каталог с архивом зондов и разархивируйте его, пример распаковки с созданием директории Boro:: unzip -d ./boro ESenSay.2016-v1.00-2016.11.07.proj244.zip 4. Зайдите в каталог, соответствующий разрядности и типу вашей ОС. 5. В файле monitor.cfg отредактируйте поле "AppDescription" (задайте имя анализатору, которое будет отображаться в системе) и при необходимости задействуйте поле "proxy", убрав // перед строкой прокси сервера. 6. Запустите анализатор в консоли:: sudo ./streamMonitor Необходимо использовать **привилегии суперпользователя** для снятия некоторых ограничений операционной системы и получения доступа к библиотеке захвата сетевых пакетов. 7. В случае успешного запуска (зонд отображается в боковой панели личного кабинета зеленой точкой) все дальнейшие действия (запуск, редактирование и остановка задач) производятся при помощи браузера. 8. Если зонд не запускается, обратитесь к параграфу `Q: Зонд не запускается`_. **Windows** 1. Разархивируйте полученный файл в необходимую директорию. 2. Зайдите в папку, соответствующую разрядности и типу вашей ОС. 3. В файле monitor.cfg отредактируйте поле "AppDescription" (задайте имя анализатору, которое будет отображаться в системе) и при необходимости задействуйте поле "proxy", убрав // перед строкой прокси сервера. 4. Запустите анализатор **"от администратора"** (правый клик на файле streamMonitor.exe -> Запуск от имени администратора). Должна запуститься консоль. 5. В случае успешного запуска (зонд отображается в боковой панели личного кабинета зеленой точкой) все дальнейшие действия (запуск, редактирование и остановка задач) производятся при помощи браузера. 6. Если зонд не запускается, обратитесь к параграфу `Q: Зонд не запускается`_. Q: Как правильно остановить зонд, запущенный в консоли? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Правильным методом является **одинарное** нажатие **Ctrl+C** в консоли, после этого необходимо ожидать корректного завершения работы зонда (до 1 минуты). Данный метод используется в Linux и Windows системах. Если просто закрыть консоль, выполнение программы завершится некорректно, программа не будет иметь возможности передать на сервер команду остановки. Сервер будет ожидать отклик от некорректно завершенного зонда до 1 минуты, и только потом переведет задачи в состояние "завершенные" с пометкой "некорректно". 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. .. note:: Рекомендуем пользоваться сохранением/загрузкой конфига на сервере, таким образом, вы избежите проблем с редактированием monitor.cfg, и у вас всегда будет backup конфигурации. Подробную информацию о конфигурационном файле вы можете найти в разделе `Конфигурационный файл`_. **A3:** Возможно, в каталоге с приложением были удалены или повреждены некоторые библиотеки. Скачайте архив заново, подмените в свежем пакете файлы *monitor.cfg* и *authkey.pub* вашими файлами. Желательно скопировать скрытый файл *.stored.cache*, тогда не будет создано повторной записи с одинаковым именем зонда. **A4:** Возможно, вы пытаетесь запустить очень старую версию зонда. Попробуйте скачать свежую версию пакета зондов в личном кабинете, отредактируйте файл *monitor.cfg* и попробуйте запуск снова. **A5:** Используется устаревшая версия ОС Linux. Необходима поддержка glibc-2.11 и выше. 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 - директорию, в которой находится зонд, и путь до исполняемого файла, соответственно. 2. Для проверки состояния сервиса необходимо выполнить следующую команду:: [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) Выделенные поля говорят о том, что автозапуск не включен, и приложение не запущено. 3. Для запуска демона необходимо выполнить команду:: systemctl start boro-client Для остановки демона необходимо выполнить команду:: systemctl stop boro-client .. note:: Cледует понимать, что после перезапуска Linux, демон будет запущен вновь, если включен его автозапуск. 4. Для разрешения автозапуска выполните команду:: systemctl enable boro-client Для отключения автозапуска:: systemctl disable boro-client 5. Проверьте состояние запущенного демона:: [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. Включаем автостарт сервиса:: chkconfig boro-client on 9. После перезагрузки анализатор будет автоматически запущен как сервис. Для сервиса можно проверить статус, запустить и остановить его “вручную” следующими командами, находясь в директории /etc/rc.d/init.d:: ./boro-client status ./boro-client start ./boro-client stop Список установленных сервисов в системе и их статус можно проверить командой:: chkconfig --list. Автозапуск сервиса можно отключить командой:: chkconfig boro-client off Обновление зонда ---------------- Существует два способа обновления зонда: * web обновление командой из личного кабинета; * из командной строки. .. note:: При обновлении все настройки и задачи зонда сохраняются. Однако, компания Elecard рекомендует произвести сохранение конфигурации на сервере или создать копию конфигурационного файла monitor.cfg непосредственно перед обновлением зонда. Q: Удаленное обновление зонда из web ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Запустите ваш текущий зонд/зонды и перейдите на страницу настройки зонда, кликнув на соответствующее имя зонда в боковой выпадающей панели. На рисунке ниже видно, что есть обновление для запущенного зонда (голубая ссылка **Update to/Обновить** с номером обновления). Необходимо нажать на данную ссылку. .. figure:: _static/probe_update_ru.png :scale: 80 % :align: center Зонд должен обновиться в течение одной минуты, после этого страница обновится, и в поле Version/Версия вы увидите новую версию зонда. Если страница автоматически не обновилась, нажмите F5. Если до обновления использовалась слишком старая версия зонда, при обновлении могут возникнуть проблемы. В таком случае может понадобиться перезапуск зонда непосредственно на удаленной машине. Кроме этого, до определенной версии, зонд не поддерживал команду обновления из web, воспользуйтесь обновлением из консоли, описанным ниже. 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 Конфигурационный файл --------------------- .. note:: В связи с интенсивным развитием проекта, данный параграф может содержать расхождения и неточности. Стоит отметить, что разработчики компании Elecard стараются максимально сохранить обратную совместимость конфигурационного файла со свежими релизами ПО зонда. При управлении зондом из браузера все настройки и изменения отражаются в файле monitor.cfg. При этом происходит полное переформатирование текста файла к формату по умолчанию для используемой версии ПО зонда. Поэтому, если вы намерены назначать задачи зонду путем редактирования файла monitor.cfg, всегда сохраняйте резервную копию файла. Q: Что такое конфигурационный файл? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Это файл monitor.cfg, получаемый в пакете зонда из личного кабинета (см. Руководстве по быстрому старту), лежащий в директории с исполняемым файлом streamMonitor. Файл предназначен для хранения настроек зонда, включая список задач. При управлении зондом, назначении задач для анализа и др. действиях на сервере данный файл модифицируется приложением зонда. При запуске, перезапуске и незапланированном перезапуске зонд использует monitor.cfg для восстановления состояния. Один из вариантов постановки задач зонду - редактирование файла monitor.cfg. Один из вариантов переноса настроек и бекапа - сохранение и копирование файла monitor.cfg. 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"** – текстовое описание/название зонда (кириллица поддерживается). Данное поле описывает зонд, например, адрес его расположения. Данная информация появится в виде записи в левой колонке "Зонды" вашего браузера (работа с сервером). .. note:: После первого запуска зонда на сервере будет создана запись, которую вы не сможете изменить редактированием поля AppDescription в конфигурационном файле. Если необходимо, отредактируйте имя в браузере или используйте следующий ключ для создания новой записи в колонке "Зонды": ``streamMonitor.exe --create-new-record`` **"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", ], }} Мониторинг мультикаст вещания ----------------------------- Q: Как определить, вижу ли я мультикаст на своей машине? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A0:** Попытаться запустить зонд и поставить ему задачу анализировать нужный мультикаст поток. **A1:** Достаточно простой способ: попытаться проиграть поток в сетевом плеере (например, в `vlc плеере `_). Если поток начинает проигрываться, это означает, что вещание доходит до вашего компьютера и может быть принято Boro зондом. Если поток плеером не проигрывается, это еще не означает, что вы не получаете мультикаст. Возможно, у вас неправильно (иначе) настроена таблица маршрутизации. Для обхода правил маршрутизации, Boro использует прямое указание сетевого интерфейса: заполните правильно поле “IP адрес интерфейса” и проверьте, принимает ли Boro зонд данные. Если поле “IP адрес интерфейса” оставлено пустым, зонд будет принимать данные согласно таблице маршрутизации. **A2:** Другим способом является попытка “сдампить” поток утилитой socat. Подробнее об утилите и пример команды читайте в разделе `Q: Как “сдампить” мультикаст поток, для дальнейшего анализа?`_. Если дамп создается успешно, это означает, что вы принимаете поток. Если файл дампа создается, но в него ничего не записывается (размер файла равен 0), это означает, что вы по каким-либо причинам не получаете указанный поток в user space. .. note:: Стоит упомянуть, что в указанном примере работы с socat используется прямое указание сетевого интерфейса, поэтому таблица маршрутизации не влияет на возможность получения потока. **A3:** Если вы испытываете проблемы с приемом мультикаста зондом Boro, ознакомьтесь с двумя вариантами ситуации ниже Почему Boro «не видит мультикаст», плеер на этой машине играет поток! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A0:** Ваш компьютер получает указанный мультикаст поток, проблема в настройке зонда. **A1:** Наиболее популярной проблемой является невнимательная постановка задачи анализатору. Т.е. проблема банально кроется в ошибках написания мультикаст группы. Пример правильного указания URI: udp://235.0.0.5:123. Примеры адреса с ошибкой: udp://235.0.0:5:1234 или udp://235.0.0.0.5:1234 .. tip:: На первый взгляд досадную ошибку сложно обнаружить, пожалуйста, проверяйте внимательно задаваемые URI. **A2:** Второй типичной ошибкой является указание неправильного IP адреса интерфейса. Проверьте правильность указания IP адреса, убедитесь, что данный интерфейс все еще присутствует в системе и, что именно данный интерфейс используется для приема мультикаста. В качестве адреса могут выступать IP сетевых карт, виртуальных интерфейсов и адрес 127.0.0.1 (т.н. localhost). Если адрес не задан, потоки будут приниматься согласно системной таблице маршрутизации. Данная ошибка часто возникает при копировании конфигов анализаторов с одной машины на другую. Мы рекомендуем для данных целей использовать удобный инструмент управления и сохранения конфигураций зонда, доступный на странице настройки зонда. Кнопки “Сохранить конфигурацию зонда” и “Применить конфигурацию зонда”. Почему Boro «не видит мультикаст», плеер на этой машине не играет поток ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A0:** Необходимо разобраться, доходит ли мультикаст вещание до машины или нет. Для этого необходимо выполнить два шага: 1. Подписаться на мультикаст группу. 2. Исследовать трафик на необходимом сетевом интерфейсе. **Linux** Для установки утилит и пакетов используйте пакетный менеджер, соответствующий вашей операционной системе (в основном всегда требуются привилегии суперпользователя). Подписаться на мультикаст группу можно следующей командой (в одну строку):: socat -u UDP4-RECV:7777,ip-add-membership=:,reuseaddr CREATE:/dev/null Проследить трафик можно несколькими способами, все они связаны с захватом трафика (т.н. packet capture) в обход всевозможных системных фильтров. Кроме этого, можно использовать т.н. `Promiscuous mode `_ - режим, в котором сетевая карта позволяет принимать все пакеты независимо от того, кому они адресованы. 1. Утилита iftop в promiscuous mode. `Руководство(rus) `_. Пример команды:: iftop -p -i -F /32 В таблице должна отобразиться строка с указанной группой. 2. Утилита tcpdump. `Руководство `_. Пример команды(в одну строку):: tcpdump -i dst and udp dst port Должен отобразиться список принимаемых пакетов (необходимо подождать 10-20с) по указанному MULTICAST IP. **Windows** Подписаться на мультикаст группу можно, запустив поток в `vlc плеере `_ или начав дампить поток с помощью утилиты socat (описание в `Q: Как “сдампить” мультикаст поток, для дальнейшего анализа?`_). Для отслеживания трафика рекомендуется использовать следующие утилиты: 1. Утилита **WinDump**. `Скачать `_. `Руководство `_. Требует `установки `_ драйвера **WinPcap**. Команда идентична команде, описанной для ОС Linux:: WinDump.exe -i dst and udp dst port Единственным отличием является указание имени адаптера - для версии Windows используются индексы, которые можно получить командой:: WinDump.exe -D 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= **Windows** Случается, что брандмауэр Windows блокирует доступ к мультикаст вещанию. Разрешите использовать частные и публичные сети для работы streamMonitor.exe (установите две галочки в Брандмауэре Windows). .. note:: способы настройки брандмауэра могут отличаться в различных версиях ОС Windows, воспользуйтесь поиском в вашем браузере. **A2:** Reverse Path Filtering (Linux only) - это механизм, проверяющий “маршрутизируемость” до отправителя пакета (`ссылка `_). Помогает отключение данного фильтра. Для проверки можно отключить так:: echo 0 >/proc/sys/net/ipv4/conf//rp_filter echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter Где имя интерфейса, для которого производится отключение фильтра. Если дело в Reverse Path Filtering, то для отключения фильтра навсегда, нужно внести правки в sysctl.conf ( нужно поменять на имя интерфейса) следующим образом :: cat >>/etc/sysctl.conf <.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. :: sudo ./streamMonitor Q: Как “сдампить” мультикаст поток, для дальнейшего анализа? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Самый простой способ “сдампить” (сохранить в .ts файл) мультикаст поток - утилитой socat. **Windows** Сборку socat для Windows можно скачать `тут `_. `Руководство `_. На момент написания статьи была протестирована версия socat 2.0.0 (beta 5) под управлением Windows 8.1. Пример команды (в одну строку):: socat -u UDP4-RECV:,ip-add-membership=:,reuseaddr CREATE:dump_name.ts Создастся файл с указанным именем, в который будет записываться поток, пока утилита не будет остановлена. **Linux** Утилита socat. `Руководство `_. Пример команды (в одну строку):: socat -u UDP4-RECV:,ip-add-membership=:,reuseaddr CREATE:dump_name-`date +'%F-%H.%M'`.ts Создастся файл с указанными именем и датой, в который будет записываться поток, пока утилита не будет остановлена. .. warning:: Особенность сборки под Linux: данная команда будет дампить все мультикасты, имеющие указанный порт. IP-адрес мультикаста тут фигурирует только для подписки на мультикаст (отправки IGMP запроса). Версии протокола IGMP ~~~~~~~~~~~~~~~~~~~~~ **A:** Принудительно выбрать версию протокола IGMP в Linux можно командой:: echo 2 > /proc/sys/net/ipv4/conf/eno2/force_igmp_version Регистрируемые параметры ------------------------ Графики ~~~~~~~ **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 во времени. Эскизы ~~~~~~ **Thumbnails** – захват эскизов видеопотока с настраиваемым интервалом времени между снимками. Дополнительно настраивается интервал между снимками в период рекламы, обозначенный метками SCTE35. Для активации захвата эскизов необходимо установить галочку «Захват эскизов» в форме постановки задачи. Параметры, события и ошибки ~~~~~~~~~~~~~~~~~~~~~~~~~~~ **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. Параметры 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 плейлистах. События и ошибки 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 ошибки. Системные ошибки ~~~~~~~~~~~~~~~~ **Error** – группа системных ошибок и ошибок общего плана: * **“Buffer overflow, data skipped”** – данные сбрасываются перед декодером. Такая ситуация возникает в результате недостаточной производительности системы. Необходимо отметить, что данные сбрасываются уже после прохождения анализа на целостность сигнала (TR 101 290) и вычисления битрейта, поэтому данная ошибка не влияет на результаты вычисления целостности. Это утверждение также применимо для OTT: данные сбрасываются перед декодированием, не влияя на вычисление скорости загрузки сегментов и детектирование OTT ошибок. Сброс данных может появиться при вычислении следующих параметров: ошибки замирания картинки, захват эскизов и вычисление EPSNR. * **“Resumption”** – фиксируется событие перезагрузки дочернего процесса, анализирующего поток, родительским процессом, так как он не отвечал в течении 10с. Главный процесс следит за работоспособностью всех задач анализатора (дочерних процессов) и, в случае критической ошибки, производит перезапуск с восстановлением состояния. * **Skip segment** (HlsSkipSegment) – пропущен сегмент данных, очередь скачанных сегментов превысила установленное значение. Недостаточная производительность зонда, скорость скачивания чанков превышает скорость их обработки. Вычисление Ethernet параметров ------------------------------ 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. Q: Ограничения на вычисление Ethernet параметров в зависимости от ОС? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. csv-table:: :header: "Свойство", "Linux", "Windows" "Вычисление Ethernet параметров(IAT/MLR/DF).", "Зонд должен быть запущен с правами суперпользователя(sudo ./streamMonitor).", "На компьютере, где запускается зонд, должна быть установлена библиотека захвата пакетов WinPcap (https://www.winpcap.org/install/)." "Вычисление Ethernet параметров для localhost (127.0.0.1).", "Ограничения нет.", "Вычисление IAT для localhost невозможно." "Вычисление Ethernet параметров на основе меток времени, проставляемых сетевым адаптером. (Высокая точность вычисления IAT).", "Поддерживается. Данный режим используется автоматически (если есть поддержка в адаптере). Подробнее в параграфе `Вычисление Ethernet параметров`_.", "Не поддерживается." Q: Что такое Maximum Inter-packet Arrival Time (IAT)? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A: Maximum Inter-packet Arrival Time (IAT)** – максимальное время между приходящими пакетами. Джиттер может быть охарактеризован при помощи проверки времени между приходящими пакетами. Максимальное время между приходящими пакетами (IAT) является суммой среднего времени между пакетами и джиттером. Фиксируется максимальное значение IAT за секунду. .. figure:: _static/IATideology_ru_en.png :scale: 80 % :align: center Выбор Ethernet контроллера -------------------------- Общая информация ~~~~~~~~~~~~~~~~ Сетевой контроллер является важной частью системы анализа, его внутренняя архитектура определяет производительность системы и точность измерений. .. note:: следует понимать, что Ethernet параметры (`Вычисление Ethernet параметров`_) (IAT, DF и MLR) измеряются на основании механизма захвата и маркировки Ethernet пакетов. Данный процесс происходит на аппаратном и программном уровнях. В данном параграфе описываются несколько свойств контроллеров, и приводится сводная таблица с особенностями ряда контроллеров, которая поможет вам осуществить выбор. При выборе контроллера необходимо учитывать и понимать следующие пункты. Метки времени приема Ethernet пакетов (timestamping) """""""""""""""""""""""""""""""""""""""""""""""""""" В данном пункте описываются факторы, влияющие на точность вычисления параметров IAT и DF. При захвате пакетов, каждый из них получает метку времени. Метки времени могут расставляться как программным путем, так и непосредственно сетевым контроллером. Особенности вычисления меток времени операционной системой более подробно описаны на сайте утилиты tcpdump в разделе `PCAP-TSTAMP `_ (английский язык). Механизм расстановки меток аппаратным путем (hardware time stamping) снижает общую нагрузку на host машину и, самое главное, увеличивает точность вычисления и устраняет зависимость точности расстановки меток от нагрузки host машины. Программный метод менее точен и имеет зависимость от нагрузки CPU, при высокой нагрузке на центральный процессор погрешность вычисления параметров может многократно увеличиваться. В свою очередь, аппаратный метод имеет различные реализации, наиболее эффективной является расстановка меток для каждого пакета (в терминологии Intel - Per-packet timestamp). Зонд автоматически пытается использовать аппаратный метод, если он доступен. Исследования компании Elecard показали, что при умеренной нагрузке на CPU разница в вычислении параметров Maximum и Average IAT программным путем и при использовании аппаратного режима Per-packet timestamp составила около 10-15%. Однако, при вычислении параметра Minimum IAT разница может составить -100%..+10000% от ожидаемого значения при использовании программного или аппаратного (отличного от Per-packet timestamp) режимов. Сказываются особенности проставления меток времени. **Вывод:** Джиттер характеризуют по параметру Maximum IAT, который достаточно точно вычисляется даже в программном режиме, при условии умеренной загрузки CPU. Недорогие адаптеры поддерживают только программный режим и могут быть рекомендованы для тестов системы. Для полноценной постоянной работы рекомендуется адаптер с аппаратной поддержкой расстановки меток времени (hardware time stamping). Для максимально точных измерений всех параметров (включая Minimum IAT) необходимо использовать карты с поддержкой маркировки временными метками каждого пакета (Per-packet timestamp). .. note:: Hardware time stamping поддерживается только в ОС Linux Очереди приема в контроллерах (Receive-Side Scaling) """""""""""""""""""""""""""""""""""""""""""""""""""" Данный пункт имеет влияние на вычисление MLR и общую производительность системы. Следующей важной особенностью сетевого контроллера является поддержка технологии Receive-Side Scaling (RSS) (`ссылка 1 `_, `ссылка 2 `_). «Суть технологии RSS достаточно проста – входящий поток данных сетевого уровня разбивается на несколько очередей, обработка каждой из которых (вызов прерываний, копирование информации) производится выделенным виртуальным процессором (т.е. или отдельным физическим, или ядром). Таким образом, в случае наличия нескольких процессоров Вы можете распределить интенсивный сетевой трафик по ним, снизив количество вызовов прерываний, переключений контекста, очистки кэша и прочих неприятностей, которые, если происходят много тысяч раз в секунду, могут ощутимо навредить производительности системы в целом...» (Цитата из технической статьи «`Тонкая настройка сетевого стека на Windows-хостах `_»). Вышесказанное справедливо, и при распределении прерываний между ядрами только одного процессора, нагрузка по обслуживанию прерываний перераспределяется между ядрами, что исключает чрезмерную загрузку одного ядра. С практической точки зрения недорогой сетевой адаптер, не имеющей технологии RSS, начнет терять данные (регистрировать ложные MLR и CC ошибки) при определенном битрейте. Вся нагрузка по обслуживанию прерываний контроллера ляжет на одно ядро, которое будет загружено на 100%, хотя остальные ядра будут свободны. Величина этого битрейта будет зависеть от производительности CPU и системы в целом. Наличие поддержки RSS сетевым контроллером еще не означает, что ваша ОС использует разные ядра для обслуживания прерываний. Для автоматического распределения прерываний по ядрам в ОС Linux может быть установлен и запущен пакет irqbalance, который осуществляет балансировку прерываний на различные ядра. Подробнее о балансировке в параграфе «`Q: Как узнать запущена ли балансировка прерываний адаптера (Linux)?`_». Кроме этого, в Linux, `для части контроллеров компании Intel `_ используется драйвер `e1000e `_, который не имеет поддержки RSS (даже если в документации на контроллер заявлена поддержка нескольких очередей). Нельзя дать однозначный совет, при каком битрейте необходимо переходить на карты с несколькими очередями, различные системы показывают различные результаты. Если вы явно испытываете большую нагрузку на одном из ядер процессора при отключенном вычислении Ethernet parameters (`Вычисление Ethernet параметров`_ может давать схожую неравномерную нагрузку одного или нескольких ядер), необходимо переходить на контроллеры с поддержкой RSS. **Вывод:** рекомендуется использовать сетевые адаптеры с поддержкой нескольких очередей (Receive-Side Scaling). Сводная информация по некоторым контроллерам """""""""""""""""""""""""""""""""""""""""""" .. csv-table:: :header: "**Name**", "`Intel I350 `_", "`Intel I340(82580) `_", "`Intel I211 `_", "`Intel I210 `_", "`82574L `_ Intel® Gigabit CT Desktop Adapter", "`Intel 82576 `_", "Intel 82575", "`Broadcom BCM5719 `_" "**HW timestamping**", "Yes", "Yes", "Yes", "Yes", "Yes", "Yes", "Yes", "Yes" "**Per-packet timestamp**", "Yes", "Yes", "Yes", "Yes", "No", "No", "No", "?" "**Rx queue # (RSS) per port**", "Up to 8", "2", "Up to 2", "Up to 4", "e1000e driver", "Up to 16", "4", "Up to 17" Как узнать какой контроллер/адаптер у меня установлен (Linux)? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Подробно информация изложена в `информационной статье `_ на сайте losst.ru Коротко можно указать следующие команды. Просмотр всех, подключенных к системе интерфейсов: название, описание и производитель адаптера, скорость, драйвер и прочее:: sudo lshw -class network Продукт и имя производителя вашей сетевой карты:: lspci | grep -i 'net' Информация о адаптере eth0 (указать свой): настройки, статус соединения, скорость и пр.:: sudo ethtool eth0 Информация о драйвере:: sudo ethtool -i eth0 .. note:: Необходимо отметить, что все способы требуют установки соответствующих утилит. Как узнать, поддерживает ли мой сетевой адаптер hardware timestamping? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Полезные ссылки: http://www.tcpdump.org/manpages/pcap-tstamp.7.html **A1:** Посмотреть поддерживаемые режимы выставления меток времени можно с помощью утилиты tcpdump:: tcpdump -J -i Пример исполнения команды:: [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:** При запуске зонда в логе есть информация об устройстве захвата пакетов: .. figure:: _static/SnifferTimestampMode_ru_en.png :scale: 80 % :align: center Sniff interface - имя интерфейса, который захватывает пакеты. UseHWTimeStamps() - информация о поддержке hardware time stamping адаптером. Одно из двух сообщений ниже означает, что есть поддержка HW time stamps: Sniffer use timestamp type: adapter (3) Sniffer use timestamp type: adapter_unsynced (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 `_. Поддержка карт захвата ---------------------- Может ли Boro мониторить различные карточки захвата, например, ASI/SDI/HDMI? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Boro может мониторить только IP потоки и файлы TS. Но, если поток с карточки может быть доставлен в IP, например в интерфейс localhost, тогда можно проводить измерения. Это касается только карты ASI. .. note:: В картах захвата SDI/HDMI используются несжатые данные, неупакованные в транспортный поток, поэтому использовать Boro нельзя, т.к. основным свойством системы является измерение целостности транспортных потоков. Есть ли поддержка анализа DVB сигнала? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Boro не поддерживает карты захвата DVB сигнала. Однако реализована и испытана следующая схема построения анализатора: .. figure:: _static/DVB_common_ru_en.png :scale: 68 % :align: center Применяются карты захвата под управлением `ПО 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). Некорректное поведение анализатора ---------------------------------- Анализатор постоянно падает, система “тормозит”, на 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. Cистема “тормозит”, на LiveView периодически регистрируются ложные CC и ClockContinuity ошибки ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Стоит обратить внимание на загрузку CPU. Особенно при большом количестве запущенных задач и использовании декодера (включена одна или несколько опций: вычисление EPSNR, захват эскизов, анализ замирания картинки). Вычисление EPSNR создает очень большую нагрузку на CPU, т.к. алгоритм требует полного декодирования видеопотоков. Производительность зависит от разрешения видеоданных в потоке и битрейта потока. При большой нагрузке система “не успевает” обрабатывать входящие данные, появляются ложные ошибки. Оценочные таблицы производительности вы можете получить по запросу у команды технической поддержки проекта: tsup@elecard.ru. Q: Значительный расход дискового пространства в Windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **A:** Наблюдается существенный расход пространства на диске С, при детальном изучении в каталоге C:\Windows\Temp создается временный файл, который продолжает стремительно расти. После остановки анализатора дисковое пространство высвобождается. Проблема проявляется при анализе потоков, получаемых по протоколу http. **Причина проблемы - антивирус**, установленный в операционной системе. Нами была зафиксирована проблема с NOD32 на Windows 10. В среде Internet зарегистрировано множество сообщений с подобными проблемами с различными антивирусами. Для устранения проблемы необходимо блокировать работу антивируса или деинсталлировать его. .. note:: Описанная проблема вызвана особенностью работы ПО антивируса, а не недостатками ПО Boro. Поддерживаемые форматы ---------------------- Видеокодеки: MPEG-2, AVC/H.264, HEVC/H.265 Транспорт: MPEG-2 TS (SPTS /MPTS) Источники: **Доставка по сети** .. csv-table:: :header: "Тип [2]_", "Пример URI" "UDP", "udp://235.0.0.8:1234" "RTP", "rtp://235.0.0.10:4444" "http/https", "http://localhost:8888/stream https://storage.streamsample.ru/stream5458993" "HLS v3", "http://95.170.157.5:80/channel1.m3u8 https://127.0.0.1:8080/channel25.m3u8" **Анализ файла** .. csv-table:: :header: "Тип [3]_", "Пример URI" "Файл", "file://d:\Streams\SPTS\dump45689.ts" "HLS v3 из папки", "file://c:\HLS\HLS_SD.m3u8" .. [2] Для всех типов сетевой доставки поддерживается только транспорт MPEG-2 TS (SPTS /MPTS) .. [3] Для всех типов анализа из файла поддерживается только транспорт MPEG-2 TS (SPTS /MPTS)