Major refactoring proposal

[abratchik]

Hi, @easytarget , I'd like to propose these changes in order to further expand the idea of can web server based on ESP32 CAM board and its clones.

Key changes in this PR:

1. Using SD card or built-in LittleFS storage for hosting the web server pages (HTML, CSS, JS) instead of byte arrays in memory. This makes the WebUI development much more convenient; standard development IDE for Web apps can be used. Besides, WebUI part can be swapped just by replacing the SD card with different UI design.
2. Replaced myconfig.h configuration approach with JSON-based configs, similar to the one used for camera settings. Details are in README.md
3. Refactored Web UI while keeping the original design and concept. The new Web UI is also easily customizable and very compact so that it can fit the LittleFS storage.
4. Refactored the code from C to C++ object hierarchy, eliminating extensive use of global variables. Root abstract class CLAppComponent has been introduced. Key application components - CAppCam (camera manager), CLAppHttpd (webserver) and CLAppConn (network manager) inherit from CLAppComponent. This allows to encapsulate the global variables based on their purpose and ensure proper visibility and protection.
5. Ported Web Server to ESPAsyncWebServer library. This library is light-weight and very powerful and flexible, allowing to reduce the required amount of HTTP server boilerplate code dramatically.
6. Ported JSON parsing to Espressive native json_parser and json_generator libs. They are very light weight but allow to parse and generate JSON quite easily and effectively.
7. Ported video streaming to Web Socket (thanks to ESPAsyncWebServer). This allows to eliminate the requirement of two HTTP ports - just one is sufficient. This reduce the load on the web server and allows to achieve maximum possible frame rates and resolution on the given hardware.
8. Refactored the /dump page so it is no longer refreshing the whole page but just pulls the JSON data from the server instead. This allows to increase the refresh rate without significant load on the web server.
9. Updated documentation (README, API). I apologize for dropping some of photos but I think it is better to make this example less personalized since it can be used in many other projects.
10. Added doxygen-generated documentation in the ./Docs/html folder.
11. Added configuration of the WiFi/Network parameters through the web page.
12. Added support of PWM on GPOI pins - - this can be very useful for implementing some of the use cases (for example, PTZ servo control)
13. Added multi-stream support (viewing video in 2 or more separate browser sessions, depending on the configuration)
14. Support basic user authentication.
15. Support of newer ESP32-S3 SoC chip (tested on LILYGO T-SIMCAM development board)

Fixes
#272 - fixed. AP configuration is perfrmed in JSON config files, see README
#279 - internal CLAppConn class does the same job but is within the project class hierarchy thus making the code more compact and managed under the project.
#158 - fixed
merges PRs:
#249 - changes proposed in the PR ported to the new UI.
#192 - implemented, see API documentation.
#51 - implemented
#54 - implemented

[daschr]

Great work! This looks like a great progress to a more stable project. Out of curiosity, what framerates do you get while streaming the video? For me, the multistream-feature is really the most desired one, would be great if it gets finally implemented as default in the firmware.

[abratchik]

Hi @daschr thank you. Maximum resolution (1600x1200) on 12 fps is what I was getting. I found that the camera module gets heated and starts responding with delays if you set the FPS and resolution too high. Besides, the color noise increases, which is expected. In my projects, 800x600 on 25 fps is good enough.
Multi-stream feature can be also implemented as the same frame can be broadcasted to all websocket clients, this is a standard feature. I just don't need it for my project, may be we can add a bit later.

[daschr]

Hi @abratchik, that sounds awesome! I'll try your fork out when I'm home.

[TungstenE2]

great work! thx a lot.
did you consider #249 as well?

[TungstenE2]

@easytarget push for this ;-)

[abratchik]

great work! thx a lot. did you consider #249 as well?

Hi @TungstenE2, I checked the PR #249 - will have to merge it manually as there is no more HTML in C/C++ code. All the HTML/CSS/JS moved to the /data folder, which needs to be copied either to the SD card or to the internal storage formatted as LittleFS.

The changes you proposed will go to the /data/js/cam.js - ths is where all camera-related parameter controls are defined.

[TungstenE2]

@abratchik how about an auto reboot option?
See: #266

[TungstenE2]

@abratchik does your new version also support OTA updates as the old version did? I have 2 cams installed in places that are not easy to access for wired updating.

[abratchik]

@abratchik does your new version also support OTA updates as the old version did? I have 2 cams installed in places that are not easy to access for wired updating.

of course. Moreover, you can also configure it via GUI. Navigate to the http://<your-ip:your-port>/setup - OTA is configured right there.
However, there is a little problem. You can update the sketch but not the data (which is hosting the front end). For that, some development still needs to happen.

On the other hand, you can keep your front end UI anywhere on your network, not necessarily on the device itself. Basically, you just need JSON API calls and Websocket operations for the image and video streaming. The front end could be good for demo and trial purposes but not for production, due to security considerations. I'd say security is one of the biggest issues in the current implementation. We will need to lock JSON and Websocket and change HTTP to HTTPS, otherwise this implementation will not be good for production. Same problem was also valid for the previous versions.

[TungstenE2]

@abratchik tried to follow instructions on https://github.com/abratchik/esp32-cam-webserver/tree/8f39567ff1b99d146bea02aacda1163ca8be5341

Get 2 error:

Mehrere Bibliotheken wurden für "WiFi.h" gefunden
In file included from C:\Users\xxx\Documents\Arduino\esp32-cam-webserver-8f39567ff1b99d146bea02aacda1163ca8be5341\esp32-cam-webserver\esp32-cam-webserver.ino:6:
Benutzt: C:\Users\xxx\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.6\libraries\WiFi
C:\Users\xxx\Documents\Arduino\esp32-cam-webserver-8f39567ff1b99d146bea02aacda1163ca8be5341\esp32-cam-webserver\src\app_httpd.h:9:10: fatal error: ESPAsyncWebServer.h: No such file or directory
#include "ESPAsyncWebServer.h"
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Nicht benutzt: C:\Program Files (x86)\Arduino\libraries\WiFi
exit status 1
Fehler beim Kompilieren für das Board ESP32 Dev Module.

[Kenajcrap]

Oh, and you can also play/record the stream directly with ffmpeg f.e. using ffplay http://:81/ which is also quite handy for video surveillance.

how were you able to play the contents of this fork with ffmpeg? Trying to to input it in a similar way to the mjpeg stream of the original repo (but adding http basic auth) yielded:

[http @ 0x559798cf00] Last chunk received, closing conn
2023-09-11 21:12:18.750965942  [AVIOContext @ 0x5597989d50] Statistics: 5164 bytes read, 0 seeks
2023-09-11 21:12:18.750979775  http://[REDACTED_USER]:[REDACTED_PASS]@[REDACTED_IP]/view?mode=stream: Invalid data found when processing input```

[easytarget]

@abratchik @TungstenE2 @daschr and Co..

Apologies for going offline here, I got rather overwhelmed by life issues and this Project was one of the things I had to give up.. I should have archived it or something but I was thinking entirely correctly. ESP completely breaking, the re-breaking the Camera code didn't help my sense of humour either.

Looking through this it seems obvious to me that I should really be pointing people to @abratchik 's fork and making it clear that I am not really maintaining this. I'm cleaning some stuff up at the moment..

Thoughts? is that A good idea, Is there an even better fork I should consider? Is there a better page where all the different firmwares are discussed?..

In the meantime I intend to try this PR and see how it goes, but I want to point new arrivals at a better fork.

[corrado-c]

Hi @abratchik . I use ESP32-CAM with ESPHome because I also need sensors, LEDs and Home Assistant integration on the same board.

Your project seems to have improvements on the streaming/webserver side. Do you think the camera streaming backend could be separated from the rest of the project and reused elsewhere?

I’m mainly wondering whether an ESPHome-oriented integration, or at least a reusable MJPEG/RTSP backend, would be technically realistic or whether your current architecture is too tightly coupled.

Thanks.

[abratchik]

Hi @corrado-c , you may reuse it according to the open source license. I did decouple the original code from @easytarget as much as possible so it is easer to extract whatever necessary.