v.5.110.0#

Изменения

Добавлена поддержка расписаний для аналитик видеопотоков — теперь можно задать, в какие дни и часы должна выполняться каждая аналитика. Это позволяет точнее управлять нагрузкой на систему, использовать ресурсы только тогда, когда это действительно нужно, а также исключить генерацию событий в неактуальное время.

Примечание. Новая возможность доступна только для обработки видеопотока (недоступно для видеофайлов).

Примеры возможных расписаний выполнения аналитик:
- Каждый день с 9:00 до 18:00
- Каждый будний день с 8:30 до 12:30
- Каждые 15 минут круглосуточно
- Каждую субботу в 23:00 на 2 часа
- Первый день каждого месяца с 00:00 до 06:00
- Понедельник, среда и пятница с 3:00 до 5:00
- Раз в день на сутки (24 часа) с любого времени старта
Есть два способа указать расписание аналитики в запросе на создание или обновление потока:

1․ Указание интервалов выполнения аналитики напрямую (analytics.schedules.start_time/end_time):
```
[
  { "start_time": "2025-07-01T09:00:00Z", "end_time": "2025-07-01T11:00:00Z" },
  { "start_time": "2025-07-02T09:00:00Z", "end_time": "2025-07-02T11:00:00Z" }
]
```
Такие интервалы можно рассчитать заранее с помощью нового запроса calculate intervals, указав cron-выражение, длительность, временной диапазон и часовой пояс.

2․ Указание идентификатора ранее созданного шаблона расписания (analytics.schedules.schedule_id).

Шаблон позволяет автоматически генерировать интервалы на основе заданных параметров (cron, длительность, диапазон) и повторно использовать их между аналитиками. Работа с шаблонами выполняется с помощью новой группы ресурсов /streams/templates.

Также можно комбинировать оба способа — передать одновременно schedule_id и дополнительные интервалы. В этом случае все указанные интервалы будут объединены в одну итоговую группу рабочих интервалов.

Чтобы получить как необъединённые, так и объединённые интервалы аналитики, можно воспользоваться запросом get stream analytics working intervals, передав параметр merged=true.

Важно: - Если для аналитики не заданы интервалы, она б удет работать всё время, пока обрабатывается поток. - Если аналитика временно на паузе (вне интервала), но поток находится в состоянии in_progress, агент при этом будет продолжать считаться занятым. - Если поток завершится или станет недоступен во время паузы всех аналитик, система не выдаст ошибок или предупреждений до тех пор, пока хотя бы одна аналитика не достигнет следующего рабочего интервала.

См. подробную информацию в разделе "Распределение аналитик" в руководстве администратора.
Добавлена возможность выбора алгоритма распределения потоков между агентами.

Доступны два варианта:
- "simple" (установлен по умолчанию): из числа доступных агентов для обработки потока (или его части) выбирается случайный агент.
- "percent": среди доступных агентов выбирается наименее загруженный (в процентном соотношении).
Важно! Алгоритм распределения потоков не распределяется на уже запущенные потоки. То есть если выставить значение "percent" при уже запущенных потоках, то они не будут переброшены на менее загруженного агента. Для перераспредения нагрузке нужно будет остановить все потоки и запустить их заново.

Для выбора алгоритма необходимо использовать новый параметр LUNA_VIDEO_MANAGER_STREAMS_DISTRIBUTION_ALGORITHM.

См. подробную информацию в разделе "Распределение потоков".
Обновлены ответы POST-запросов:
В них добавлены:
1. новые параметры в тело ответа: url — относительный путь (например, /6/streams/:id) и external_url — абсолютный URL (например, http://<host>:<port>/6/streams/:id)
2. новый заголовок: Location — расположение созданного ресурса (аналогично url).
В запросы группы ресурсов /streams добавлен новый параметр ffmpeg_kwargs, предназначенный для передачи дополнительных аргументов в ffmpeg, используемый при декодировании видео.

Этот параметр позволяет управлять низкоуровневыми настройками ffmpeg, если стандартных параметров недостаточно для подключения или корректной обработки потока. Например, для нестандартных RTSP-серверов может потребоваться указание rtsp_transport.

Если ffmpeg_kwargs передан, он должен содержать словарь дополнительных именованных аргументов для ffmpeg (например, "rtsp_transport": "udp"). Для RTSP-потоков, если rtsp_transport не указан, по умолчанию будет использоваться TCP.

Важно! Все параметры передаются напрямую в ffmpeg без проверки на валидность или безопасность. Используйте на свой страх и риск. Ошибки, связанные с неверными параметрами, отображаются в логах потоков.

Список возможных параметров и их значений см. в официальной документации ffmpeg.
Добавлена предварительная проверка доступа к GPU в сервисе Video Agent.

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

Ранее при отсутствии корректного доступа к GPU сервис просто завершался с неинформативными ошибками, что затрудняло диагностику.

Теперь в логах сервиса появляется сообщение Check access to GPU:, где фиксируется результат проверки. В случае ошибки доступа будет выведено сообщение от CUDA.
В руководство разработчика сервиса Lambda, в раздел "Standalone lambda development", добавлен пример Standalone-lambda, запускающей ML-модель.

См. подробную информацию в разделе Standalone-lambda

Исправленные ошибки

HTTP-заголовок Location добавлен в ответы для нескольких ресурсов спецификации OpenAPI.
Исправлена ошибка, из-за которой поля даты не проверялись во время выполнения запроса на создание события.

Ранее могла возникнуть ошибка типа "Internal server error" с кодом состояния 500 из-за некорректного формата даты.
Исправлено описание мониторинга нод human_tracking в документации разработчика. Серии для аналитики human_tracking теперь явно отмечены.

См. подробную информацию в разделе "Monitoring" руководства разработчика.
Исправлена ошибка в сервисе Video Agent, из-за которой не удавалось подключиться к сервису Events.