Пара вопросов.

[Valery Sch]

1. Можно ли очистить таблицы EVENTS  и TREE_EVENTS и чем это чревато?
2. На что влияет параметр "Декодировать"? Что будет если его поставить в "Выкл"
По дефолту, как я понимаю декодирование включено.

[Valery Sch]

C декодированием кажись разобрался. Появился вопрос по onvif(автонастройка)
Камера показывает три профиля (во вложении).
Выбор первого профиля не вызывает затруднений. При выборе второго профиля программа не видит камеру.
Используя полученную строку подключения, ввел ее в VLC и подключение прошло.
Но! VLC показал, что разрешение отличается от того, что показал onvif(автонастройка)

Вручную поменял автовыствленное разрешение 704х576 на 800х448 , которое показал VLC и камера увиделась аврегом.

По третьему профилю совсем непонятно. Его не удалось задействовать ни в авреге, ни подключиться в VLC
Как я понимаю по 3-му профиля камера отдает JPEG, но как его получить-непонятно.
Может что-то делаю не так и можете подсказать можно ли получить этот поток.

суббота, 13 апреля 2024 г. в 19:51:17 UTC+2, Valery Sch:

[Andrey Nikitin]

Valery Sch писал(а):

Здравствуйте.

> 1. Можно ли очистить таблицы EVENTS и TREE_EVENTS и чем это чревато?

TREE_EVENTS это кеш интерфейса Архив::Галерея. Её можно чистить.

В EVENTS записываются ссылки на сохранённые ролики.
Если её очистить все интерфейсы Архив:* окажутся пустыми,
а файлы на диске придётся удалять вручную.
Эту таблицу синхронно с ФС очищает avreg-unlink в автоматическом режиме или при ручном запуске (CLI).
http://avreg.net/manual_tuning_avreg-unlink.html

> 2. На что влияет параметр "Декодировать"? Что будет если его поставить в
> "Выкл"

Вы не сможете использовать детектор движения, локальный просмотр (avreg-mon)
и, если с камеры забирается НЕ mjpeg, то не будет работать дефолтный просмотр
в реальном времени в браузере (только HLS).

[Andrey Nikitin]

Valery Sch писал(а):

> Может что-то делаю не так и можете подсказать можно ли получить этот поток.

Суть этого запроса к ONVIF - автоматическое заполнение параметров на основании RTSP URL отданного камерой:
1 rtsp_port
2 geometry
3 rtsp_play

Чтобы определить причину по которой захват не осуществляется нам нужно увидеть логи и конфигурацию AVReg,
получить которые в нужном объёме проще всего зайти на страницу "Сообщить о проблеме".

[Valery Sch]

Вряд ли "Сообщить о проблеме" тут поможет. Дело в том, что и ONVIF Device Manager показывает такое же разрешение 704х576

и только VLC дает 800х488 используя строку подключения, которую формирует аврег. Это для второго профиля камеры.
По строке подключения 3-го профиля подклюяиться не получается, ни аврегом, ни VLC.

Скрины ODM для профилей 2 и3

понедельник, 15 апреля 2024 г. в 08:07:24 UTC+2, Andrey Nikitin:

[Andrey Nikitin]

Valery Sch писал(а):

> Вряд ли "Сообщить о проблеме" тут поможет. Дело в том, что и ONVIF Device

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

[Valery Sch]

В логах появляется
avregd: cam[1]: capture (AV) failed: Invalid data found when processing input
да еще
cam[1]: capture (AV) failed: interrupted
cam[1]: mjpg --> ins...@192.168.30.240:47438: have not a source video stream now #1 (resp.status 503)

понедельник, 15 апреля 2024 г. в 20:33:28 UTC+2, Andrey Nikitin:

[Valery Sch]

Выше я указал при выборе 3-го профиля. При выборе 2-го
cam[1]: capture (UN) failed: hevc video stream resolutions mismatch: avreg's "geometry" (704x576) vs camera setting (800x448)
Правка вручную 704x576 на 800x448 делает камеру видимой и убирает ошибку.

понедельник, 15 апреля 2024 г. в 23:40:41 UTC+2, Valery Sch:

[Andrey Nikitin]

Valery Sch писал(а):

> avregd: cam[1]: capture (AV) failed: Invalid data found when processing input

Чаще всего такая ошибка может встречаться на расфокусированных или тормозных камерах и обычно помогает увеличение
Захват -> по сети:
nc_wait_conn_timeout

> Выше я указал при выборе 3-го профиля. При выборе 2-го
> cam[1]: capture (UN) failed: hevc video stream resolutions mismatch:

Зачем забирать в h265(hevc) разрешение менее FullHD?

> avreg's "geometry" (704x576) vs camera setting (800x448)
> Правка вручную 704x576 на 800x448 делает камеру видимой и убирает ошибку.

Какой-то баг клиента и/или сервера ONVIF.

[Valery Sch]

nc_wait_conn_timeout тут не в тему. VLC тоже по этой строке не цепляется.

> "Зачем забирать в h265(hevc) разрешение менее FullHD? "

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

> "Какой-то баг клиента и/или сервера ONVIF."

Пожалуй да. ODM тоже показывает "ошибочное" разрешение.
Но в конечном итоге ведь аврег понял какое разрешение отдает камера (704x576) vs camera setting (800x448)
Может нужна какая-то дополнительная проверка потока для определения истинного значения geometry .

вторник, 16 апреля 2024 г. в 16:04:45 UTC+2, Andrey Nikitin:

[Andrey Nikitin]

Valery Sch писал(а):

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

Да но и тип кодека имеет значение. Декод h264 существенно быстрее h265.

> > "Какой-то баг клиента и/или сервера ONVIF."
> Пожалуй да. ODM тоже показывает "ошибочное" разрешение.
> Но в конечном итоге ведь аврег понял какое разрешение отдает камера
> (704x576) vs camera setting (800x448)
> Может нужна какая-то дополнительная проверка потока для определения
> истинного значения geometry .

Истинное значение потока - то, которое в медиа-стриме (RTSP).
Если где-то в ONVIF ошибка, это нюансы, настроить захват можно и без ONVIF.
Если камера не нонейм китайский - проверьте актуальность прошивки камеры, может это уже пофиксили.

[Valery Sch]

Камера скорей нонейм, чем нет. Говорит что она XM530V200_X4C-WQ_8M

В точности под найти прошивку-проблематично.
В обеих работающих профилях указан кодек h264, но один отдает 2560х1440, а второй (как оказалось) 800х448

Вот я и хочу под декодирование пустить второй

В третьем профиле указан кодек jpeg но получить его не получается.

Может я неправильно интерпретирую данные из ODM. Вот они:

вторник, 16 апреля 2024 г. в 20:30:35 UTC+2, Andrey Nikitin: