v.5.110.0

Changes

• Support for schedules in video stream analytics has been added — now you can set on which days and hours each analytic should run. This has allowed more precise control of system load, use of resources only when truly needed, and exclusion of event generation during irrelevant times.

  Note: The new feature has been available only for video stream processing (not available for video files).

  Examples of possible analytic schedules:

  • Every day from 9:00 to 18:00
  • Every weekday from 8:30 to 12:30
  • Every 15 minutes around the clock
  • Every Saturday at 23:00 for 2 hours
  • The first day of each month from 00:00 to 06:00
  • Monday, Wednesday, and Friday from 3:00 to 5:00
  • Once a day for 24 hours from any start time

  Two methods have been provided to specify analytic schedules in stream creation or update requests:

  1․ Direct specification of analytic execution intervals (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" }
  ]
  

  Such intervals can have been calculated in advance using the new request calculate intervals, specifying a cron expression, duration, time range, and time zone.

  2․ Specification of an identifier of a previously created schedule template (analytics.schedules.schedule_id).

  The template has allowed automatic generation of intervals based on given parameters (cron, duration, range) and their reuse between analytics. Template management has been performed using the new resource group /streams/templates.

  Both methods can have been combined — passing both schedule_id and additional intervals simultaneously. In this case, all specified intervals have been merged into one final group of working intervals.

  To get both unmerged and merged analytic intervals, the request get stream analytics working intervals with the parameter merged=true can be used.

  Important:

  • If intervals have not been set for analytics, it has run all the time while the stream has been processed.
  • If analytics have been temporarily paused (outside the interval), but the stream has been in in_progress state, the agent has continued to be considered busy.
  • If the stream has ended or become unavailable during a pause of all analytics, the system has not issued errors or warnings until at least one analytic has reached the next working interval.

• The ability to select a stream distribution algorithm between agents has been added.

  Two options have been available:

  • "simple" (default): a random available agent has been selected to process the stream (or its part).
  • "percent": the least loaded agent (by percentage) among available ones has been selected.

  Important: The distribution algorithm has not affected already running streams. That is, if "percent" has been set with streams already running, they have not been reallocated to less loaded agents. To redistribute load, all streams must have been stopped and restarted.

  To select the algorithm, the new parameter LUNA_VIDEO_MANAGER_STREAMS_DISTRIBUTION_ALGORITHM must be used.

  See detailed information in the "Stream distribution" section.

• The following POST responses have been updated:

  • create stream
  • create group
  • register agent

  • create analytic

  • New parameters have been added to the response body: url — relative path (e.g., /6/streams/:id) and external_url — absolute URL (e.g., http://<host>:<port>/6/streams/:id)

  • New header Location — the location of the created resource (similar to url).

• A new parameter ffmpeg_kwargs has been added to requests in the /streams resource group for passing additional arguments to ffmpeg used during video decoding.

  This parameter has allowed control of low-level ffmpeg settings when standard parameters have been insufficient for connection or correct stream processing. For example, rtsp_transport may have needed specification for non-standard RTSP servers.

  If ffmpeg_kwargs has been passed, it must have contained a dictionary of additional named arguments for ffmpeg (e.g., "rtsp_transport": "udp"). For RTSP streams, if rtsp_transport has not been specified, TCP has been used by default.

  Important: All parameters have been passed directly to ffmpeg without validation or safety checks. Use at your own risk. Errors related to invalid parameters have been shown in stream logs.

  See the list of possible parameters and their values in the official ffmpeg documentation.

• Preliminary GPU access check in the Video Agent service has been added.

  For estimators requiring GPU, a check for GPU device availability and access has been performed during container startup.

  Previously, in case of missing proper GPU access, the service has just terminated with uninformative errors, complicating diagnosis.

  Now the service logs have included the message Check access to GPU:, recording the check result. If access error has occurred, a message from CUDA has been output.

• An example of a Standalone-lambda running an ML model has been added to the Lambda service developer manual, in the "Standalone lambda development" section.

  See detailed information in the Standalone-lambda section.

Fixed errors

• The HTTP header Location has been added to responses for several OpenAPI specification resources.

• An error causing date fields not to be validated during the event creation request execution has been fixed.

  Previously, an "Internal server error" with status code 500 could have occurred due to an incorrect date format.

• The description of human_tracking node monitoring in the developer documentation has been fixed. Series for the human_tracking analytic have been explicitly marked.

  See detailed information in the "Monitoring" section of the developer manual.

• An error in the Video Agent service preventing connection to the Events service has been fixed.