cgroup_enable=cpuset
and cgroup_enable=memory cgroup_memory=1
to this file: /boot/firmware/nobtcmd.txt
Note: If not able to install the debian package of v4l2loopback due to using a different Linux kernel, you can clone the repo, build the module, and setup the module dependencies like so:git clone https://github.com/umlaeute/v4l2loopback.gitcd v4l2loopbackmake & sudo make installsudo make install-utilssudo depmod -a
video_nr
argument.Note: If this generates an error, be sure that there are no existing video streams targeting the video device nodes by running the following and then re-running the previous command:if pgrep gst-launch-1.0 > /dev/null; thensudo pkill -9 gst-launch-1.0fi
yaml
file that you apply to your cluster. Within it, you specify three things:KERNEL=="video[0-9]*"
. It matches name of the mock USB cameras.Note, when real USB cameras are used, the filtering udev rule can be more precise to avoid mistaken device match. For example, a better rule isKERNEL=="video[0-9]*"\, ENV{ID_V4L_CAPABILITIES}==":capture:"
that adds a criteria on device capability. We may go further by adding criteria such as vendor name. An example isKERNEL=="video[0-9]*"\, ENV{ID_V4L_CAPABILITIES}==":capture:"\, ENV{ID_VENDOR}=="Great Vendor"
. In order to write correct rule, check output of "udevadm" command for USB cameras. A example is "udevadm info --query=all --name=video1".
akri-udev-video
.agent.full=true
is set. By default, a slim Agent without any embedded Discovery Handlers is deployed and the required Discovery Handlers can be deployed as DaemonSets. This demo will use that strategy, deploying the udev Discovery Handlers by specifying udev.discovery.enabled=true
when installing Akri.Note: See the cluster setup steps for information on how to set the crictl configuration variableAKRI_HELM_CRICTL_CONFIGURATION
brokerProperties
of each instance, you can see the device nodes (/dev/video1
or /dev/video2
) that the Instance represents. The brokerProperties
of an Instance are set as environment variables in the broker Pods that are utilizing the device the Instance represents. This told the broker which device to connect to. We can also see in the Instance a usage slot and that it was reserved for this node. Each Instance represents a device and its usage.capacity
. There is a capacity
parameter for each Configuration, which defaults to 1
. Its value could have been increased when installing Akri (via --set <discovery handler name>.configuration.capacity=2
to allow 2 nodes to use the same device) and more usage slots (the number of usage slots is equal to capacity
) would have been created in the Instance.<streaming-app-port>
with the port number outputted in the previous step.Note we've noticed issues with port forwarding with WSL 2. Please use a different terminal.
http://localhost:50000/
. The large feed points to Configuration level service (udev-camera-svc
), while the bottom feed points to the service for each Instance or camera (udev-camera-svc-<id>
).udev-camera-svc
service and onvif-camera-svc
service.udevadm info --query=property --name /dev/video0
, passing in the proper devnode name. In this example, ID_VENDOR=Microsoft
was one of the outputted properties. To only find cameras made by Microsoft, the rule can be modified like the following: