Feature Request: Only run when needed

[bodograumann]

Currently, the script always activates the webcam the whole time and uses processing resources.
Is it possible to pause the processing, while the output video device is not used?
Or maybe even automatically start the script when a process opens the device and exit afterwards.

[intermezzio]

That's a good idea. At this point I don't know if v4l2 supports streaming to a webcam on demand like that. At the very least, the virtual webcam doesn't stream data unless this script is run, and the script can be started or stopped whenever you want. If you have any ideas for how to implement this, or if you want to add this feature, any thoughts in this issue or a pull request would be much appreciated.

[bodograumann]

This is an approach using inotifywait. I need to see how well it works and how robust it is though.

#!/usr/bin/env sh

set -e

cleanup() {
  if [ -n "$pid" ]
  then
    kill "$pid"
  fi
}

while true
do
  printf "Waiting for camera to be opened...\n"
  inotifywait -qq -e open /dev/video7
  weffe -B portrait &
  pid=$!
  inotifywait -qq -e close /dev/video7
  kill $pid
  pid=""
done

[intermezzio]

This is a clever solution, thanks for sharing it with me. It didn't seem to work when I tried it locally (maybe it's because filestreams aren't treated the same way as files) but this is a good general structure for how something like that would work. I couldn't find a way to get inotifywait to follow the filestream /dev/video7 but I've found this solution with lsmod and another implementation here which may be able to be swapped in for inotifywait. The only downside is that this command would have to be run periodically as it checks if the webcam is on as opposed to asynchronously waiting for the webcam to turn on. It's still a performance improvement over keeping it on at all times though.

[bodograumann]

Curious. I was at least able to correctly detect the open event on /dev/video7. Closing was not as reliable. Probably because some timing issues.
Also I have the problem, that the actual ffmpeg call is nested in subprocesses and the kill will not stop it. I tried different solutions with pkill -P $$ and setsid, but haven’t yet found a working solution. Directly putting the logic in the main script would of course work around that problem.

The lsmod approach seems interesting as well.
Though it cannot detect when a process is trying to open /dev/video7 and failing because we are not writing any data to it yet. The usage count of the kernel module will stay at 0. Only opening of the actual camera can be detected with it. Not sure if that might be useful.
For detecting the end of camera usage, this might work though:

baseUsers=$(mod_users v4l2loopback)
while true
do
  sleep 1
  users=$(mod_users v4l2loopback)
  if [ "$baseUsers" -gt "$users" ]
  then
    break
  elif [ "$baseUsers" -lt "$users" ]
  then
    baseUsers=$users
  fi
done

[bodograumann]

Another thing we could do is always outputting a minimal placeholder (e.g. static image), which would probably consume very few resources.

[intermezzio]

It turns out inotifywait works, I was just fiddling with other v4l2 settings at the same time so it didn't work. I've implemented the inotifywait solution in a pull request I'm attaching, and the relevant code is here:

if [[ $persistent == false ]]
	while true
	do
		printf "Waiting for camera to be opened...\n"
		sh -c "$alt_ffmpegstr" &
		pid=$!
		sleep 0.1 # wait for camera to stop thinking it's still open
		inotifywait -qq -e open /dev/video$output
		printf "Camera opened\n"
		kill $pid
		sh -c "$ffmpegstr" &
		pid=$!
		printf "Waiting for close\n"
		inotifywait -qq -e close /dev/video$output
		printf "Closed, revert to simple film\n"
		kill $pid &
		tail --pid=$! -f /dev/null
	done
else
	sh -c "$ffmpegstr"
fi

I still have to run some tests to make sure this code works in all conditions before merging the pull request.

[intermezzio]

If you would like to test this yourself, you can clone the issue 12 branch and run ./weffe locally from within the repository. You're welcome to add more, make changes, or otherwise let me know your thoughts on this change. Currently, I'm planning to make this the new default way weffe runs with an option -P (persistent) for making weffe run all the time, as it does now.

[bodograumann]

I will definitely try it out.
Note that this means we have to add inotify-tools as a dependency.

[bodograumann]

It already works pretty good.
Two things I noticed:

• The alternative stream actually uses more cpu resources than the normal camera stream. Maybe the framerate needs to be limited?
• Sometimes the camera is active even though it is not being used. I think the problem is not, that the closing was not detected, but that the camera was stopped and than started again, even though nothing was actually reading the stream. Not sure where that spurious open event comes from. Maybe from our ffmpeg itself, which opens it to write?

[intermezzio]

• In the alternative stream I have it generate a background with a single color, I'll see if having it feed an image to the virtual camera is more efficient, although it will need to be resized to fit the resolution. Is the alternative stream using more resources even when filters are added (e.g. blur, etc?)
• I think this is because the camera itself doesn't "turn off" until a fraction of a second after the ffmpeg script stops, so when inotifywait runs it still thinks it's open. I can increase the sleep time to see if that fixes it, but it works on my end.

[bodograumann]

The alternative stream is basically using one whole core.
The actual stream has blur and an overlay, but doesn’t need as much resources.

I’ll keep an eye the close issue. Maybe another idea would be to have a counter that listens to every open and close event. Then the difference between the counts tells us whether the device is opened or closed.

[bodograumann]

Today after coming out of suspend, weffe was caught in loop of opening and closing the camera.
The following output repeated:

Camera opened
Waiting for close
Closed, revert to simple film
Waiting for camera to be opened...
./static/blur_portrait.png: Immediate exit requested

I have encountered that Immediate exit requested before, but not sure what it means exactly.

[bodograumann]

One important thing to note, is that ffmpeg itself generates an open event when started and close_write, close events when stopped. These might trip us up.

Here is a way to observe the events and their timings:

inotifywait -me open,close /dev/video7 | while read line; do echo $(date +%T.%N) $line; done

Or to count the number of reading processes:

> inotifywait -q -me open,close /dev/video7 | awk 'BEGIN { count = 0 } /OPEN/ { count++ } /CLOSE/ { count-- } { print count " [" $0 "]" }'
1 [/dev/video7 OPEN ]
2 [/dev/video7 OPEN ]
1 [/dev/video7 CLOSE_WRITE,CLOSE ]
2 [/dev/video7 OPEN ]
1 [/dev/video7 CLOSE_WRITE,CLOSE ]
0 [/dev/video7 CLOSE_WRITE,CLOSE ]
1 [/dev/video7 OPEN ]
0 [/dev/video7 CLOSE_WRITE,CLOSE ]

What you can see above is:

1 weffe starts writing placeholder
2 video call client opens dev for reading
1 weffe stops writing placeholder
2 weffe starts passing through from camera
1 video call client closes dev
0 weffe stops passing through from camera
1 weffe starts writing placeholder
0 weffe stops writing placeholder