Event-based video recording
We’re retiring the Azure Video Analyzer preview service, you're advised to transition your applications off of Video Analyzer by 01 December 2022.
Azure Video Analyzer for Media is not affected by this retirement. It is now rebranded to Azure Video Indexer. Click here to read more.
Action Required: To minimize disruption to your workloads, transition your application from Video Analyzer per suggestions described in this guide before December 01, 2022. After December 1, 2022 your Azure Video Analyzer account will no longer function. Starting May 2, 2022 you will not be able to create new Video Analyzer accounts.
Event-based video recording (EVR) refers to the process of recording video triggered by an event. The event in question could originate due to processing of the video signal itself (for example, when motion is detected) or could be from an independent source (for example, a door sensor signals that the door has been opened). A few use cases related to EVR are described in this article.
The timestamps for the recordings are stored in UTC. Recorded video can be played back using the streaming capabilities of Video Analyzer. See Recorded and live videos for more details.
You can use Video Analyzer to perform EVR in two ways:
- Record the input from a given RTSP-capable IP camera to a given video resource in the cloud, where each new event would append to the recording available in that video resource.
- Record to separate MP4 files to the local storage of the IoT Edge device - each event would result in a new MP4 file.
A few use cases related to event-based video recording are described in this article.
Video recording triggered by motion detection
In this use case, you can record video clips only when there is motion detected in the video and be alerted when such a video clip is generated. This could be relevant in commercial security scenarios involving protection of critical infrastructure. EVR would help you lower storage costs.
The diagram below shows a graphical representation of a pipeline that addresses this use case. The JSON representation of the pipeline topology of such a pipeline can be found here.
In the diagram, the RTSP source node captures the live video feed from the camera and delivers it to a motion detection processor node. Upon detecting motion in the live video, the motion detection processor node generates events, which goes to the signal gate processor node as well as to the IoT Hub message sink node. The latter node sends the events to the IoT Edge Hub, from where they can be routed to other destinations to trigger alerts.
Events from the motion detector node also trigger the signal gate processor node, opening it, and letting the live video feed from the RTSP source node flow through to the video sink node. In the absence of subsequent such motion detection events the gate will close after a configured amount of time. This determines the duration of the recorded video that is appended to the video resource.
Video recording based on events from other sources
In this use case, signals from another IoT sensor can be used to trigger recording of video. The diagram below shows a graphical representation of a pipeline that addresses this use case. The JSON representation of the pipeline topology of such a pipeline can be found here.
In the diagram, the external sensor sends events to the IoT Edge Hub. The events are then routed to the signal gate processor node via the IoT Hub message source node. The behavior of the signal gate processor node is the same as with the previous use case - when triggered by an event, it will open and let the live video feed flow through from the RTSP source node to the file sink node. A new MP4 file is written to the local storage of the IoT Edge device each time the gate opens.
Video recording based on an external inferencing module
In this use case, you can record video based on a signal from an external logic system. An example of such a use case could be recording video to the cloud only when a truck is detected in the video feed of traffic on a highway. The diagram below shows a graphical representation of a pipeline that addresses this use case. The JSON representation of the pipeline topology of such a pipeline can be found here.
In the diagram, the RTSP source node captures the live video feed from the camera and delivers it to two branches: one has a signal gate processor node, and the other uses an HTTP extension node to send data to an external logic module. The HTTP extension node allows the pipeline to send image frames (in JPEG, BMP, or PNG formats) to an external inference service over REST. This signal path can typically only support low frame rates (<5fps). You can use the HTTP extension processor node to lower the frame rate of the video going to the external inferencing module.
The results from the external inference service are retrieved by the HTTP extension node, and relayed to the IoT Edge hub via IoT Hub message sink node, where they can be further processed by the external logic module. If the inference service is capable of detecting vehicles, for example, the logic module could look for a specific vehicle such as a truck. When the logic module detects the object of interest, it can trigger the signal gate processor node by sending an event via the IoT Edge Hub to the IoT Hub message source node in the pipeline. The output from the signal gate is shown to go to a video sink node. Each time a truck is detected, video is recorded to the cloud (appended to the video resource).
An enhancement to this example is to use a motion detector processor ahead of the HTTP extension processor node. This will reduce the load on the inference service, such as during night time when there may be long periods of time when there are no vehicles on the highway.
See the note on resilient recording which also applies to EVR.
Submit and view feedback for