Add new webcam driver.

[btsimonh]

Description:

To use the old one, define USE_WEBCAM_LEGACY

This is a re-submisison of the webcam PR, with the implementation of it changed to by default replace the old one, making this PR generate a directly testable and usable binary.

Runs all camera stuff from a task.

Never fails at startup on my (very bad) esp32cam board.

Enables motion detect, Timelapse, direct image saving etc. from Berry scripts and as TAS commands.

Increased reliability. Increased flexibility.

Documented here: https://github.com/btsimonh/TasmotaBerryPLay/blob/master/tasdocs/esp32cam.md

Example Timelapse and Motion here (needs more description, but works very well. Can use staticfileserving from the other PR to provide direct viewing and download of complete image sets.

Should work with Scripts, but not tested for a while (@gemu2015 ?).

Checklist:

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works with Tasmota core ESP32 V.2.0.10
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[Jason2866]

What's the impact of size (Flash) and RAM of the new driver compared to the actual one?

[btsimonh]

@Jason2866
this build (webcam on MacOS from above checks):
RAM: [== ] 19.7% (used 64668 bytes from 327680 bytes)
Flash: [==== ] 43.8% (used 1291873 bytes from 2949120 bytes)
FileUI PR (webcam on MacOS from #19014)
RAM: [== ] 19.7% (used 64572 bytes from 327680 bytes)
Flash: [==== ] 43.4% (used 1278941 bytes from 2949120 bytes)

so a small reduction in RAM (until aspects are in use...)
and a larger increase in flash (+12k).

But the webcam build is actually still fairly small.
I suspect that some of the original driver was not linked in unless scripts were enabled (e.g. motion detection routines may have not been referenced unless scripts were enabled). The differences between this and the original are not vast, but how they are used is quite different - the aim being to avoid conflicts by centralising access to the camera, and protecting against conflicting actions - whilst enabling Tas commands to do quite advanced stuff (save jpg to flash/sd, enabling motion detect using 3 different forms, etc.)

I've been running the driver for weeks, and it's quite stable, but have just setup my garden cam with timelapse and motion recording using the mentioned berry script. So far, so good. Combined with directly serving the SD card content, it provides a very sweet solution.

[btsimonh]

I've been away for a week, and left motion detect and timelapse running using the new driver and my Berry code.
It was still happily saving images on my return.
I've been doing some updates on the viewing javascript and html to improve download efficiency (limiting to serially downloading from tas - doubles download performance).

[github-actions]

This PR has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[btsimonh]

Please keep this open.
I'll publish results from long running soon.

[btsimonh]

finally, I checked my cam:

Program Version	13.0.0.1(webcam)
Build Date & Time	2023-07-09T12:41:58
Core/SDK Version	2_0_10/4.4.5.230614
Uptime	28T02:58:00

This is running timelapse hourly pictures stored to SD card, plus motion images stored to SD, all controlled via Berry.
it stored 481 timelapse images (it's restricted to lighter hours - ~17.5 Mbytes @ 640x480), and around 900 movement images since 9th july.
the 28 days uptime is since I last rebooted (adjusted script that day), and hence did not fail once.
The example below was downloaded direct via TAS with webserving enabled and configured.

Example timelpase output, roughly 1.5 days per second:
https://github.com/arendst/Tasmota/assets/3137332/da8422a9-65bb-4f3b-88ce-a99ca3172f5b

ffmpeg cmd on windows to convert images to video:

ffmpeg ^
 -framerate 25 -start_number 1 -i "images/frame%%d.jpg" ^
 -c:v libx264 -pix_fmt yuv420p out.mp4

I guess it needs to be rebased on top of latest dev?

[arendst]

I guess it needs to be rebased on top of latest dev

Not sure if needed but pls do and once complete I'll merge.

[btsimonh]

closing as replaced by #19280
No changes, but just buoilt and basic testing done on current dev.