Skip to content

LUNA PLATFORM v.5.56.0#

Changes#

  • The ability to perform video analytics using the new resource "videosdk" has been added.

    Important: Currently, the resource is in beta testing status. Input and output schemes may be changed in future releases without backward compatibility support.

    Video analytics is a set of functions that process frame by frame and assess valuable data.

    To perform video analytics, an external link to a video file not exceeding 1 GB in size must be specified.

    During video analytics, a certain number of events are generated according to some rules, where each event has a start and end. Events are recorded in the response body and contain specific information about the particular video analytics. The response body also contains basic metadata about the video (number of frames, frame rate, video duration). The obtained information is only available in the response body and is not saved anywhere.

    Important: An event in video analytics is in no way related to events generated by handlers.

    In the "LUNA_REMOTE_SDK_VIDEO_SETTINGS" section of the Remote SDK service, you can configure video processing settings, such as the number of decoder working processes, temporary directory for storing videos, etc.

    Note: In the current version, video decoding is only done on the CPU. GPU decoding will be added in future releases.

    Currently, only people counting video analytics is supported.

    People counting video analytics

    The event of people counting video analytics starts when the specified number of consecutive frames (parameter "probe_count") shows the specified number of people (parameter "people_count_threshold"). For example, if the minimum number of people is 10, and the number of consecutive frames is 3, the event will start if there are 10 people in 3 frames. If there are 10 people in 2 frames, and 9 people in the third frame, the event will not start.

    By default, every 10 frames are processed. If necessary, you can adjust the frame processing frequency using the "rate" parameter (for example, process every 3 seconds or every 3 frames).

    For this type of video analytics, you can also configure a rectangular region of interest (parameter "roi") on the frame (coordinates "x", "y", width, height, units of measurement - percentages or coordinates). The operating principle of ROI is similar to FaceStream.

    Each event in people counting video analytics contains the following information:

    • "event_id" - Event ID.
    • "max_people_count" - Maximum number of people detected in the processed video segment.
    • "video_segment" - Information about the video segment (start time of the event, end time of the event, first frame number, last frame number).
    • "frames_estimations" - Array with information about estimates on each frame, containing the following information:
      • Frame number.
      • Time corresponding to the frame.
      • Number of people.

    See detailed information about the new resource in the OpenAPI specification.

  • The SDK has been updated to version 5.17.0.

    In this version of the SDK, the LivenessOneShotRGB estimator has been updated.

  • A built-in plugin has been added to the API service, which enables you to make some requests to the LUNA Streams service through the API service.

    Before using the plugin, you must enable and configure it (optional).

    Plugin "luna-streams.py" located in the API service container along the path /srv/luna_api/plugins and enabled using the setting "LUNA_API_ACTIVE_PLUGINS".

    The plugin can be configured in the "LUNA_API_PLUGINS_SETTINGS" setting. In the setting, you can set the address and API version of the launched LUNA Streams service, as well as connection timeouts.

    Example of the content of the "LUNA_API_PLUGINS_SETTINGS" setting for the "luna-streams.py" plugin:

    { "luna-streams": { "luna-streams-address": { "origin": "http://127.0.0.1:5160/1", "api_version": 1 }, "luna-streams-timeouts": { "request": 60, "connect": 20, "sock_connect": 10, "sock_read": 60 } } }

    If necessary, you can differentiate access rights for requests to LUNA Streams using token permissions. To do this, you need to create a new or update an existing token by passing a custom "streams" key with permissions for the token.

    To proxy requests from the LUNA API service to the LUNA Streams service, you need to specify a permission named "streams". Other custom key names will not work.

    You can set the following permissions:

    • "creation" (POST requests)
    • "view" (GET requests)
    • "modification" (PUT requests and PATCH requests)
    • "deletion" (DELETE requests)

    See the "Plugins" section of the developer manual to get a list of possible requests.

    The information will also be added to the FaceStream administrator manual in the next release.

  • A new "get list of plugins" request has been added to all LUNA PLATFORM services, which enables you to get a list of imported plugins and their status.

  • A new type of Tasks has been added to the Lambda service-lambda, designed to implement additional custom long task types.

    Examples of possible functionality:

    • Unlink faces from lists if faces do not similar to the specified face.
    • Remove duplicates from list.
    • Recursively find events similar to the specified photo.

    Lambda-tasks are created in the same way as the other types using the "create lambda" request.

    After creating a lambda, you must perform the "lambda task" request to create a Lambda task. The results of the task/subtask can be obtained using standard requests from the Tasks service.

    The Lambda task is created according to the general task creation process, except that the Lambda service is used instead of the Tasks worker.

    See the "Tasks-lambda" section of the administrator manual for additional basic information.

    See the detailed information and code examples in the Tasks service developer manual.

    It is also possible to create a schedule for Lambda tasks.

  • The error description for some cases of validation of the "generate events" request body when using the "multipart/form-data" scheme has been improved.

Fixed errors#

  • Fixed generation of incorrect token expiration time when creating/updating it in cases when the server's local time is set ("STORAGE_TIME" = "LOCAL").

  • Fixed the error that caused excessive opening of database connections when creating a Linker task with a large number of people, which led to the task hanging.

  • Fixed the error due to which it was impossible to perform a "create new events" request to the Events service with non-null "location" fields.

    An attempt to execute a similar request ended with an error with the code "12047" and the description "Failed to validate input msgpack. Path: '[0].location.', message: '[0].location. must be string''".

  • Fixed the error 'a coroutine was expected, got None that occurred when using the event dispatch plugin with a large number of arguments.

    See the "Plugins" section of the Handlers service developer manual for details and an example of an event sending plugin.

  • Fixed the error of counting the current time ("now-time") for the "create_time__lt" and "create_time__gte" filters specified in the "match_policy" > "candidates" policy when creating a handler.

    Previously, the current time was counted from the time when the handler was created. Now the current time will be counted from the time when the event was generated.

  • Fixed the license check for the ISO feature.

    Previously, if the ISO licensed feature was disabled, requests to perform any estimations ended with an error with the code "11055" and the description "License problem: ISO feature is disabled".

  • Fixed processing of detections in the generate stream events (beta) request.

    Now, if samples are transferred with the type "sources" > "source_type" > "detections", then detection and extraction of these samples will be performed.

  • Fixed the error in the absence of the "unknown" field in the description of the liveness request in the OpenAPI specification of the Backport3 service.