Change ffmpeg motion detection control to cover the whole range supported by ffmpeg

[rcatolino]

Change ffmpeg motion sensibility control

This shouldn't be merged as-is

In the current ipcamera binding the item controlling ffmpeg scene detection sensibility is a slider going from 1 to 100, which is divided by 5000 and used with https://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect. So the maximum scene detection probability we can use is 100/5000 = 0.02
This is causing an issue with my camera where even a static scene is regularly detected as a new scene by ffmpeg with a probability of 0.02~0.03. I would like to use 0.1 as the threshold (i.e. -an -vf select='gte(scene\,0.1)',metadata=print -f null -) but this isn't possible with the current divider of 5000.
In this pull request I've changed this divider to be 100 to allow the item to cover the whole range of ffmpeg scene detection probability, but :

• This is going to break existing setups as the motion control item value won't mean the same thing
• It doesn't allow to control the scene detection probability threshold with the same granularity

I don't know what the ideal value should be for the divider, but 5000 seems to high. @Skinah how did you choose this value ? The examples in ffmpeg doc https://ffmpeg.org/ffmpeg-filters.html#Examples-160 uses a threshold of 0.45 so I don't think my threshold of 0.1 is crazy.

[Skinah]

How did I come up with it?

1. I asked for feedback on this forum thread here
   https://community.openhab.org/t/how-to-turn-a-cameras-rtsp-stream-into-motion-detection/89906
2. Then I tested alot and came up with what I found worked.
3. Then I revised the method and descibed it here:

#10683

[rcatolino]

Ok, if this divider is working for most people then nevermind.
For the record my stream is at 12 fps and there are some trees in the background that can't easily be cropped since they are behind the area of interest. Those are surely the reason of the false positives.
I'm going to setup motion instead.

[Skinah]

I would not say it works for most people, as most people don't bother giving feedback and I do not use this feature at all. Yes a dedicated software package is going to give better results and also give more features. You may find a different value works for you as it looks for multiple hints across frames to agree motion is occurring. Object detection helps to reduce false positives.

[J-N-K]

Wouldn't it make sense to have it configurable then?

[rcatolino]

I think what would make the most sense is to have a setting in the ipcamera binding that is the literal ffmpeg sensitivity and is used as the value in ffmpeg scene detection filter. Then, instead of a dimmer for the ffmpegMotionControl channel, a simple switch to toggle the detection.
This would not allow the end user to control the sensitivity but the admin could more easily set a value working for the camera.

But I have a working setup with motion now so I'm not going to work on it. And overall I agree that it's probably best to use a dedicated tool to detect motion than the simple ffmpeg scene filter (like motion or an onvif cam).

[Skinah]

Did changing the value of your PR solve the trees moving in your setup? If so then a change should be made.

My own opinion is that it should be two dimmers.

1. Controls the countOfMotions or how many frames in a row need to agree there is motion.
2. The existing control should control the value only and have a slightly greater range, or it could be a config that controls the resolution of this slider.

The frame rate changes what it would be set to.
If it is night or day it needs to be a different value due to pixel noise at night.
Possibly the resolution effects it as well, definately uses more CPU power to process a higher resolution feed.

As mentioned I do not use this and if people find it needs to be changed then feel free to make a change.