ESP32CAM-RTSP: turning a camera module into an RTSP server with a web console

Three protocols from one camera module

Flashing this software on an ESP32CAM module turns it into an RTSP streaming camera server, an HTTP Motion JPEG streamer and an HTTP image server. That is the whole product, and the three protocols exist for three different consumers.

The RTSP server speaks the industry standard protocol that lets CCTV systems and applications such as VLC connect directly to the ESP32CAM camera stream, and it is also possible to stream directly to a server using ffmpeg. The README spells out what that buys you: the module becomes a camera server allowing recording, and the stream can be stored on a disk and replayed later.

Underneath, the video is encoded as Motion JPEG, RTP payload 26, and streamed over RTP/UDP by default or over RTP/RTSP/TCP. The URL is rtsp://<ip address>:554/mjpeg/1, and authentication is optional, with clients required to provide credentials when it is enabled.

The audio path is narrower and worth knowing about. Boards with an onboard microphone, and the Seeed Studio XIAO ESP32S3 SENSE is named, can additionally stream G.711 a-law audio, RTP payload 8.

The HTTP side is simpler and is what a browser or a script will use. The HTTP JPEG streamer makes it possible to watch the camera stream directly in your browser at http://<ip address>/stream, and the HTTP image endpoint returns a single JPEG of the camera at http://<ip address>/snapshot. The second one is the endpoint for anything that wants a still, and it costs a fraction of what a stream does.

The configuration lives in a web server, not in a config header

The software provides a configuration web server, and the list of what it can do is long enough to show the design intent.

It gives information about the state of the device, the WiFi connection and the camera. It sets the WiFi parameters and the timeout for connecting to the access point, and it sets an access password. On the imaging side it selects the image size, the frame rate and the JPEG quality, and it enables the use of the PSRAM and sets the number of frame buffers.

Then there is the camera option list, which is where the project shows how much of the sensor it actually exposes: brightness, contrast, saturation, a special effect with Normal, Negative, Gray-scale, Red/Green/Blue tint and Sepia, white balance and automatic white balance gain, white balance mode, exposure control, auto exposure and its level, manual exposure value, gain control, manual gain control, auto gain ceiling, black and white pixel correction, gamma correction, lens correction, horizontal mirror, vertical flip, downsize enable and a colour bar.

The reason this matters is that none of these values can be changed by a compile-time flag or by editing a header. A camera installed in a ceiling needs its exposure and white balance set from wherever the device is, and a config file baked into the firmware means reflashing to change a brightness setting. Putting the configuration behind a web server turns the device into something you can deploy and then adjust, and it is the difference between a demo board and something you put in a hallway.

The access password is part of the same surface, and the RTSP authentication section is separate, so the two should not be assumed to cover the same ground.

mDNS is how you find the thing on the network

The software also provides an mDNS server to be easily discoverable on the local network, and it advertises HTTP on port 80 and RTSP on port 554.

That is a small feature with a large practical effect. The alternative to mDNS here is typing an IP address into a player, and on a network with DHCP that address changes. An ESP32CAM that announces itself as a camera on the local segment can be found by a laptop, by a phone, or by the NVR software you are integrating with, without a static address, a discovery protocol on the server side, or a note about which address the camera ended up with.

It also fixes the two port numbers that everything else in the README refers to. The web configuration interface and the HTTP endpoints live on port 80, and the RTSP server on 554, which is the standard RTSP port, so a player that expects a camera on a standard port finds it without configuration.

The boundary of mDNS is worth stating as well. It resolves on the local segment, and it is not a way to reach the camera from another network or from the internet. If the plan is to view this from somewhere else, the address has to be discovered some other way, and the authentication settings become the only thing standing between the stream and anybody who can reach the port. The RTSP authentication exists precisely for that case, and the README describes it as optional.

The board table is the document that matters

The README warns about the name ESP32-CAM directly: there are a lot of boards available that are all called ESP32-CAM, however there are differences in CPU, type, speed and cores, how the camera is connected, and presence of PSRAM or not.

The table that follows is the practical answer, and it lists each board with its CPU, SRAM, flash, PSRAM, camera and extras. The AI-Thinker ESP32-CAM has an ESP32 CPU, 520KB of SRAM, 4MB of flash, 4MB of PSRAM and an OV2640. The Espressif ESP32-Wrover CAM has the same CPU and camera but 8MB of PSRAM rather than 4MB. The ESP32-S3-CAM V3 is a different CPU altogether, the ESP32-S3R8, with 8MB of flash, 8MB of PSRAM and either an OV2640 or an OV3660, plus a flash LED.

PSRAM is the column to read twice, because it decides whether the high resolution frames fit in memory at all, and the configuration web server has an explicit switch to enable the use of the PSRAM. The frame buffer count is configurable as well, which is the other memory-sensitive setting.

The supported list in the README is long, seventeen modules including AI THINKER, several Espressif variants, the M5STACK family, the Freenove WROVER KIT, the TTGO T-CAMERA and T-JOURNAL, and the Seeed Studio XIAO ESP32S3 SENSE. And there is a branch to know about. A develop branch is available with the newest boards, including the Seeed Studio XIAO ESP32S3, and the README notes it may be ahead of main and that feedback and testing are welcome.

That last point is the one to plan around. The main branch is the one with the released behaviour, and the branch with the newest hardware is the one the author would like tested.

PlatformIO for the firmware, Python for the tooling

The requirements section is short. You need an ESP32-CAM module or similar, a USB to Serial, TTL level, converter or the piggyback board ESP32-CAM-MB or other way to connect to the device, and the PlatformIO software, which is a free download.

The README has a whole section on putting the ESP32-CAM in download mode, which is the step most people get stuck on, because the module has to be in that mode before the firmware can be written. The README does not spell out the jumper and button procedure in the section that was published, so follow the section itself rather than assuming, and PlatformIO handles the rest of the compile and deploy cycle.

The Python side is smaller and is worth understanding because it contains one of the more interesting pieces of the project. The pyproject.toml describes itself as Python tooling for the ESP32CAM-RTSP project, and it lists two helper scripts that need third-party packages: tools/srtp_client.py, which needs cryptography for RFC 3711 AES-CM decrypt, and minify.py, which needs minify-html for the generate_html pipeline.

The SRTP client is the notable one. It is a tool for talking to the camera's encrypted stream, which is what you need to test the authenticated path rather than assuming it works. The minifier is the other half of the web interface, the pipeline that generates and compresses the configuration pages that get served from flash.

The tooling installs the conventional way, and the pyproject file says it is compatible with pip, Poetry and uv:

pip install .
poetry install
uv sync

The project metadata names the distribution esp32cam-rtsp-tools, version 0.1.0, requiring Python 3.9 or later, with cryptography 41.0 or later and minify-html 0.12 or later.

A licence badge that disagrees with the repository metadata

Two things in this repository are worth pausing over, and neither is a criticism so much as a warning to check the files yourself.

The first is the licence. The README's badge says license MIT, while the repository's licence metadata is classified as GPL-3.0. Those are different licences with different obligations, so one of the two is out of date. The LICENSE file in the repository is the text that governs, and it is the one to read before you put this firmware into a product.

The second is the version numbering, which is not monotonic. The release list has 1.0.6 from 2024-02-13, described as the last release 1.0.6 with a note to switch to version 2, then 1.0.7 from 2026-09-29, described as a new RTSP streamer with sound, RTPS and authentication, and then 1.0.8 from the same day, described as the latest build with prebuild images.

So a release telling you to move to version 2 sits between two releases numbered 1.0.x, which means the project has been reorganised at some point, most likely by moving to a version 2 line and then, apparently, returning to the 1.0.x numbering for the newer work. If you are picking this up today, the tag list is not a reliable guide to which line to use, and the README's own note about the develop branch being ahead of main is a further reason to read the repository rather than assume.

For the record on maintenance, the last push to the repository was on 2026-10-12, and the two most recent releases were both published on 2026-09-29, so the work is current even though the numbering is confusing.

Editorial conclusion

ESP32CAM-RTSP fits a maker with an ESP32-CAM module who wants a stream other applications can open, including VLC and ffmpeg, without buying a camera. It does not fit a deployment that needs a commercial camera's guarantee, nor a board that is not in the supported list. Before you flash anything, check the board table for the PSRAM configuration and the camera type, because the README says the modules differ in CPU, camera connection and the presence of PSRAM, and choose the branch deliberately, since the develop branch is documented as ahead of main and carrying the newest boards.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. rzeldent/esp32cam-rtsp on GitHub