ESP32-P4 Guide: 1080p H.264, MIPI Camera Examples, and Bench Numbers
2026-10-28
A P4 core board costs about as much as an ESP32-S3 devkit and it will not connect to Wi-Fi. That is the first thing to internalise. Espressif spent the silicon budget on a video pipeline: MIPI CSI in, ISP, PPA, JPEG and H.264 encoders, MIPI DSI out. Wireless is somebody else's job, usually an ESP32-C6 hanging off SDIO.
That trade is the whole point of the part. It also means most "getting started with ESP32" advice does not transfer, and a lot of the numbers people repeat about P4 are from the pre-release datasheet.
TL;DR: P4 is a camera and display SoC, not a bigger S3. Budget for a companion C6, use ESP-IDF rather than Arduino for anything video, size your framebuffers before you size your code, and expect 1080p30 H.264 encode with roughly 140 KB of working memory.
What the chip is
Everything below comes from the ESP32-P4 datasheet v0.7 (pre-release). Treat the electrical numbers as provisional; the architecture is what matters.
| Item | ESP32-P4 |
|---|---|
| HP CPU | RISC-V dual-core, 5-stage pipeline, 400 MHz, RV32IMAFC + Zc/Zb |
| Custom extensions | XespV (128-bit AI/DSP vector ops), XespLoop (hardware loops) |
| CoreMark | 6.92 CoreMark/MHz dual-core, so about 2,770 at 400 MHz |
| LP CPU | RISC-V single-core, 2-stage pipeline, 40 MHz, RV32IMAC |
| Internal memory | 128 KB HP ROM, 768 KB HP L2MEM, 16 KB LP ROM, 32 KB LP SRAM, 8 KB SPM at 400 MHz |
| Cache | 16 KB L1 I-cache (4-way), 64 KB L1 D-cache (2-way), two-level |
| PSRAM | 16 or 32 MB in-package, 16-bit DDR at 250 MHz |
| GPIO | 55 programmable, 5 strapping |
| Radios | None |
| Package | QFN104, 10 × 10 mm, –40 to 85 °C |
Two variants exist today: ESP32-P4NRW16X with 16 MB PSRAM and ESP32-P4NRW32X with 32 MB. Both run PSRAM at 1.8 V and ship as chip revision v3.x.
The LP core is not a token. It runs RV32IMAC at 40 MHz, has its own ROM, SRAM, UART, I2C, SPI, I2S, ADC and touch controller, and keeps running in deep sleep. You can put your sensor polling and your wake logic there and leave the 400 MHz cores powered down.
The pipeline, block by block
This is where the money went, and it is the part that decides whether your product is possible.
| Stage | Block | Datasheet limit |
|---|---|---|
| Capture | MIPI CSI | CSI-2, DPHY v1.1, 2 lanes × 1.5 Gbit/s |
| Capture | DVP camera | 8/16-bit parallel via LCD_CAM |
| Clean | ISP | 1920 × 1080, RAW8/10/12 in, RGB/YUV out |
| Transform | PPA | rotate 0/90/180/270, mirror, scale, alpha blend |
| Move | 2D-DMA | colour-space conversion, macroblock reorder |
| Compress | JPEG | 4K still, 1080p@40 encode and decode |
| Compress | H.264 | 1080p@30 encode, baseline profile |
| Show | MIPI DSI | 2 lanes × 1.5 Gbit/s, video mode |
The ISP is a full pipeline, not a pass-through: black level, dead-pixel correction, Bayer, lens shading, demosaic, white balance, colour correction matrix, gamma, sharpen, crop, plus AE/AF/AWB and histogram statistics. That matters when your sensor is a bare SC2336 with no ISP of its own. With an OV5647, which has its own ISP, you have two pipelines to tune against each other.
The H.264 encoder does I and P frames, CAVLC, motion estimation at half and quarter pixel, and up to eight rectangular regions of interest with per-region QP. Dual-stream mode exists, but both streams share the 1080p30 budget. PPA handles rotation and blending so the CPU never touches a framebuffer, and the 2D-DMA does colour conversion while it moves macroblocks. Those three blocks together are what make a 400 MHz chip feel like it has far more headroom than 400 MHz.
There is one asymmetry worth knowing before you design: the JPEG codec both encodes and decodes, the H.264 block only encodes. H.264 playback is software.
Framebuffer math you should do first
PSRAM bandwidth is 16 bits × 2 edges × 250 MHz, so 8 Gbit/s, or 1 GB/s if you prefer bytes. That sounds enormous next to an S3. It stops feeling enormous once you count frames.
- One 1280 × 720 RGB888 frame is 2.64 MiB.
- One 1920 × 1080 RGB888 frame is 5.93 MiB.
- 32 MB of PSRAM holds about five 1080p RGB888 frames, or twelve 720p frames.
Triple buffering a 1080p RGB888 pipeline eats 17.8 MiB before you allocate a single decode buffer. If you are also holding a JPEG source, a YUV420 working frame and an H.264 output buffer, you are close to full. The 768 KB of L2MEM is not a substitute; it is where your stacks, DMA descriptors and hot code live.
Two habits save projects here. Convert to RGB565 before the framebuffer if the panel is 16-bit anyway, which halves everything. And let the PPA and 2D-DMA write directly into the buffer the LCD driver scans out, so a frame is touched once instead of three times.
The DSI link needs the same treatment. Two lanes at 1.5 Gbit/s is 3.0 Gbit/s of raw capacity.
- 720p at 60 Hz in RGB888 needs 1.33 Gbit/s. That is 44% of the link, comfortable.
- 1080p at 60 Hz in RGB888 needs 2.99 Gbit/s. That is 99.5% of raw capacity, before blanking and protocol overhead. It does not fit.
- 1080p at 60 Hz in RGB565 needs 1.99 Gbit/s. That fits with room to spare.
So a 1080p60 panel is a 1080p60-in-RGB565 design, or a 1080p30-in-RGB888 design. Decide that on day one, not in the week before the demo.
What people are actually building
Specs do not tell you whether a chip is fun to work with. These projects do.
- Retro handhelds. RetroGo now runs SNES, Mega Drive and DOOM on P4 hardware, including a GB300 shell transplant documented on Hackaday. 16-bit emulation was the ESP32's ceiling; on P4 it has headroom.
- A $40 art frame. p3a plays animated pixel art and museum images on a 720 × 720 panel from a Waveshare ESP32-P4-WIFI6-Touch-LCD-4B. It boots straight into the picture, which a Pi cannot do.
- A tablet-shaped OS. NucleoOS P4 turns a 7-inch Guition panel into an app platform with a WASM app store, offline text-to-speech and an MJPEG/MPEG-1 video player using the hardware JPEG decoder and PPA.
- Twenty-two apps on one board. The CrowPanel suite treats an Elecrow 7-inch P4 panel as a field computer: camera, synth, ADS-B radar, ebook reader, game console.
- Camera products. The ESP32-P4-EYE is Espressif's own pocket camera devkit, and most vendor boards ship with a MIPI camera and a DSI panel because that is the workload.
The pattern is consistent. People reach for P4 when they want a screen and a camera in a device that starts instantly and runs for weeks on a battery.
Software support, honestly
| Platform | State | Use it for |
|---|---|---|
| ESP-IDF v6.x | Primary target | Everything video, USB, Ethernet |
| Arduino-esp32 3.2.0+ | P4 listed as supported | GPIO, I2C, SPI, simple UI |
| MicroPython v1.27.0+ | Supported since Dec 2025 | Scripting, bring-up, teaching |
| CircuitPython 10.x | Alpha port, mipidsi added for P4 |
Experiments, not products |
| ESPHome | Partial, evolving | Simple HMI, not camera pipelines |
The pattern is consistent: ESP-IDF first, everything else later and thinner. If your product depends on the ISP or the H.264 encoder, ESP-IDF is not a preference, it is the only path. If you are blinking LEDs or reading a sensor, Arduino is fine.
Examples that actually run
These are the ESP-IDF paths worth cloning. Set the target first with idf.py set-target esp32p4.
| Example | What it proves |
|---|---|
examples/peripherals/camera/mipi_isp_dsi |
Sensor to display through the ISP, the core P4 demo |
examples/peripherals/camera/dvp_dsi |
Parallel camera to DSI, cheapest sensor path |
examples/peripherals/isp/multi_pipelines |
Two ISP pipelines at once |
examples/peripherals/jpeg/jpeg_encode and jpeg_decode |
Hardware codec round trip with pytest golden images |
examples/peripherals/h264 |
Hardware vs software encoder behind one API |
examples/peripherals/ppa/ppa_transform |
Rotation, mirror and scale in hardware |
examples/peripherals/ppa/ppa_color_key |
Layer blending with colour-key filtering |
examples/peripherals/lcd/mipi_dsi |
DSI panel bring-up without a camera |
examples/peripherals/dma/async_color_convert |
2D-DMA colour conversion |
examples/peripherals/usb/host/uvc |
USB UVC camera into the same pipeline |
examples/system/ulp/lp_core/lp_touch |
LP core running while HP cores sleep |
For production, espressif/esp_video is the better abstraction. It wraps CSI, DVP, SPI cameras, the ISP and both codecs behind V4L2 device nodes, so a capture app looks like Linux: /dev/video0 for the sensor, /dev/video10 for the JPEG encoder, /dev/video11 for H.264, /dev/video12 for the JPEG decoder. If you have ever written a V4L2 capture loop, you already know the P4 API.
idf.py add-dependency "espressif/esp_video=*"
Then enable the interfaces you need under Component config → Espressif Video Configuration.
Five experiments worth a weekend
Each one answers a question you cannot answer from the datasheet.
1. Sensor to panel, end to end. Run mipi_isp_dsi on an ESP32-P4-Function-EV-Board with an OV5647 and the EK79007 panel. Watch for tearing on fast pans and log the frame interval with esp_timer_get_time() between VSYNC events. If the interval jitters by more than a frame, you are bandwidth-bound, not CPU-bound.
2. JPEG round trip and the padding trap. Encode a 1920 × 1080 still, decode it back, compare with the source. The decoder rounds output up to block boundaries — 16 pixels for YUV420, 8 for YUV444 and GRAY — so a 1080-row image needs a buffer sized for 1088 rows. Size for the padded dimensions, not the visible ones, or the driver writes past your allocation.
jpeg_decode_picture_info_t info;
jpeg_decoder_get_info(src, src_len, &info);
size_t w = (info.width + 15) & ~15u; /* padded, not visible */
size_t h = (info.height + 15) & ~15u;
jpeg_decode_memory_alloc_cfg_t mem_cfg = {
.buffer_direction = JPEG_DEC_ALLOC_OUTPUT_BUFFER,
};
uint8_t *out = jpeg_alloc_decoder_mem(w * h * 3, &mem_cfg, &out_size);
3. H.264 bitrate ladder. Encode the same 1080p30 clip at 512 kbit/s, 2 Mbit/s and 8 Mbit/s. Compare file size, encode frame rate and free PSRAM after esp_h264_enc_hw_new(). The published figure is 1080p30 with about 140 KB of working memory, which is small enough that your bottleneck will be the capture path, not the encoder.
4. PPA versus software rotation. Rotate a 1280 × 720 RGB565 frame 90° twice: once with the PPA, once with a CPU loop. The memory-bandwidth floor for the hardware path is 3.69 MB moved per rotation, which is about 3.7 ms at 1 GB/s. Anything the CPU does will be slower and will evict your working set. This experiment is the fastest way to convince a colleague that the PPA is not optional.
5. Deep sleep with the LP core awake. Flash lp_touch and measure current with a PPK2 or Joulescope. Deep sleep with the LP timer and LP memory powered is 12 µA; light sleep with everything on is 800 µA. If you measure anything near 800 µA in "deep sleep", something in the HP domain is still clocked. The LP core can poll a sensor and wake the HP cores only when the value crosses a threshold, which is the pattern most battery products on this chip should use.
Stretch goal: point a USB UVC camera at usb/host/uvc, decode MJPEG with /dev/video12, re-encode to H.264 with /dev/video11, and stream over the C6. That is a complete product architecture in one pipeline, and it exercises every block on the chip.
Boards that exist
| Board | What you get | Watch out for |
|---|---|---|
| ESP32-P4-Function-EV-Board | P4 + C6, MIPI DSI panel, camera, ES8311 codec, RJ45 10/100 | The reference for examples; not cheap |
| ESP32-P4-EYE | Camera-first devkit, LCD, mic, SD, C6 | Small enclosure, needs a thin battery |
| M5Stack Tab5 | 5" 1280 × 720 DSI tablet, 2 MP camera, RS-485, battery | ~$60; two hardware revisions in the wild |
| Waveshare P4-NANO / P4-ETH | Cheap core boards, 100 Mbit Ethernet variant | Verify which PSRAM size you ordered |
| DFRobot FireBeetle 2 P4 | Compact, C6 onboard, I3C exposed | Fewer video interfaces broken out |
For a first board, buy the one whose examples you intend to run. A cheap P4 module with no panel and no camera saves $30 and costs a week.
Street prices at the time of writing: about $9 for a Waveshare ESP32-P4 core board, about $56 for the Espressif Function-EV-Board, about $60 for the M5Stack Tab5, and $69 for the Elecrow starter kit. The P4 silicon itself is roughly $8–12, which is why boards cluster so tightly.
Videos worth the time
- ESP32-P4 HD Camera Processing & Encoding — Espressif's own MIPI-CSI, ISP and 1080p encode demo. Watch the latency, not the resolution.
- ESP32-P4-EYE Hands-On — real 1080p capture, MP4 recording and an LVGL UI on the camera devkit.
- New ESP32-P4 DevKit, unboxing & MIPI-DSI 1280x800 demo — the official devkit's touch panel and camera preview in one short clip.
- ESP32-P4 First Look — a Waveshare board walked through spec by spec, including the C6 pairing.
- FireBeetle 2 ESP32 P4 — the compact board, I3C, and an honest note that video work belongs in ESP-IDF.
Where it bites
The missing radio is a design decision, not a footnote. On the Function-EV board the C6 talks to the P4 over SDIO. That adds latency compared with native Wi-Fi and it adds a second firmware image you have to keep in sync. If your product needs wireless, budget for flashing and versioning two chips. Our C6 Thread and Zigbee notes cover the radio side of that pairing.
MIPI CSI wants 2.5 V. The CSI D-PHY rail is separate and the driver expects it. On reference boards an internal LDO provides it; on your own board, wire it and configure the regulator before esp_cam_new_csi_ctlr().
SDIO and the SD card can collide. Both can land on the same SDMMC slot, and the failure looks like a broken card rather than a pin conflict. If Wi-Fi dies when the card is mounted, move one of them to slot 0.
Ethernet is 10/100. MII or RMII, one at a time, via an external PHY. There is no gigabit MAC. If you need throughput, USB High-Speed is the faster pipe at 480 Mbit/s.
The datasheet contradicts itself on PSRAM clock. Section 4.1.3.1 says 250 MHz and 8 Gbit/s; the memory specification table says 80 MHz. The 8 Gbit/s figure is the one used in Espressif's bandwidth worked example. Quote it with the derivation, not as a bare number.
It is a pre-release datasheet. Revision v0.7 says so on the cover, and Section 5 opens with a note that values may change. Architecture is safe to design against. Electrical limits are not.
ESP32-P4 vs ESP32-S3
| ESP32-P4 | ESP32-S3 | |
|---|---|---|
| CPU | Dual RISC-V, 400 MHz | Dual Xtensa LX7, 240 MHz |
| Internal RAM | 768 KB L2 + 8 KB SPM | 512 KB SRAM |
| PSRAM | 16/32 MB in-package | Up to 8 MB typical |
| Camera | MIPI CSI + DVP | DVP only |
| Display | MIPI DSI + parallel RGB | SPI / parallel RGB |
| Video encode | JPEG + H.264 1080p30 | None |
| USB | HS OTG 480 Mbit/s | FS OTG 12 Mbit/s |
| Radio | None | Wi-Fi + BLE |
| Ecosystem | Young, ESP-IDF-first | Mature, everywhere |
Pick the S3 when the product is a connected sensor with a small display and you want one chip, one firmware and a year of Stack Overflow answers. Pick the P4 when a frame ever needs to be compressed, rotated, or pushed to a real panel at 60 Hz. If you need both, the P4 plus C6 pair is the shape Espressif ships, and it works.
When a Raspberry Pi Zero is the better answer
This comparison comes up in every beginner thread, and the honest answer is that they are different classes of device.
| ESP32-P4 | Pi Zero 2W | |
|---|---|---|
| Operating system | None (bare metal or RTOS) | Linux |
| Time to first frame | Under a second | Tens of seconds |
| Deep sleep | 12 µA | No real sleep state, ~95 mA idle |
| RAM | 32 MB PSRAM | 512 MB |
| Video encode | Hardware H.264 and JPEG | Software, via ffmpeg |
| Wi-Fi | Via companion C6 | Built in |
| Board price | $9–60 | About $15 |
The Pi gives you Python, OpenCV, ffmpeg and apt. The P4 gives you instant boot, a 12 µA sleep floor and a hardware encoder that does not fight for CPU. A battery camera that wakes on motion is a P4 product. A camera that runs a neural network in Python overnight is a Pi product. Neither is the wrong choice; picking by "which is more powerful" is.
FAQ
Does ESP32-P4 have Wi-Fi or Bluetooth? No. There is no radio in the datasheet at all. Boards add an ESP32-C6 or ESP32-C5 module over SDIO, SPI or UART using ESP-Hosted.
Can ESP32-P4 decode H.264?
Not in hardware. The hardware block is an encoder only. Decoding runs on the CPU through esp_h264's tinyH264-based software decoder, which manages around 10 fps at 720p. Decode JPEG in hardware instead when you control the format.
Is ESP32-P4 supported by Arduino? Yes, since arduino-esp32 3.2.0, which lists P4 as supported. GPIO, I2C, SPI and basic display work. The ISP, PPA and encoder paths are documented for ESP-IDF and that is where they are tested.
How much PSRAM should I order? 32 MB unless you have done the framebuffer math and proved 16 MB is enough. The 16 MB part saves very little and the difference is two 1080p RGB888 frames.
Can I run two cameras?
The ISP has three input channels (MIPI-CSI, DVP, AXI-DMAC) and isp/multi_pipelines demonstrates concurrent pipelines, but the CSI PHY is a single 2-lane interface. Two sensors means one on CSI and one on DVP, or time-multiplexing.
Is ESP32-P4 good for edge AI? For classical vision, yes: the ISP, PPA and codecs mean the CPU is free for detection loops. For neural networks, it has no NPU, so you are running quantised models on the vector extensions with ESP-DL. It is a capable image processor with spare CPU, not an accelerator.
Is ESP32-P4 a Raspberry Pi replacement? No. It runs no operating system, has no native Wi-Fi and far less RAM. What it does better is start in under a second, sleep at 12 µA, and compress video without loading the CPU. Use a Pi when you need Linux, Python or apt; use a P4 when the device has to feel like hardware.
What can I build with an ESP32-P4? Anything that needs a real screen or a camera and cannot afford a Linux boot: doorbells, dash cams, shop displays, touch panels, POS terminals, robot vision, retro handhelds, art frames, voice terminals. If the product has a battery and a display, P4 is usually the cheaper answer than a Pi.
Where do I start if I only have the chip?
Buy a board with a camera and a panel. The bring-up order that works is: USB Serial/JTAG console, then PSRAM test, then lcd/mipi_dsi for the panel, then camera/mipi_isp_dsi, then your own pipeline.
References
- ESP32-P4 Series Datasheet v0.7 (pre-release), Espressif Systems, 102 pages
- ESP32-P4 product page — https://www.espressif.com/en/products/socs/esp32-p4
- ESP-IDF ESP32-P4 programming guide — https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/
- ESP-IDF examples — https://github.com/espressif/esp-idf/tree/master/examples/peripherals
- ESP-Video components (V4L2 on P4) — https://docs.espressif.com/projects/esp-video-components/en/latest/esp32p4/ESP_Video/index.html
- ESP_H264 component — https://components.espressif.com/components/espressif/esp_h264
- ESP32-P4-Function-EV-Board guide — https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32p4/esp32-p4-function-ev-board/user_guide.html
- ESP32-P4-EYE guide — https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32p4/esp32-p4-eye/index.html
- ESP-Hosted (C6 companion) — https://github.com/espressif/esp-hosted-mcu
- MicroPython v1.27.0 release — https://github.com/micropython/micropython/releases/tag/v1.27.0
Sizing a camera product on P4? Send us the sensor, the panel and the frame rate. We reply with a bandwidth budget and a firmware estimate.