espressif / esp32-camera

Apache License 2.0
1.77k stars 616 forks source link

`cam_hal: EV_VSYNC_OVF` when trying to capture in RGB565 or YUV422, in 1024x768 or 1600x1200, while capturing in 1280x1024 is okay #643

Open SYPark0795 opened 4 months ago

SYPark0795 commented 4 months ago

ESP-IDF version: v6.2, v6.1.3 Board: ESP32S3 Xiao Sense Chip: ESP32-S3

Source code: https://pastebin.com/R87rAp32

When capture succeeds:

Heap: 336779/458963, 208896 max block
PSRAM: 5763768/8388608, 5636096 max block
Resolution: 1280x1024
Heap: 336779/458963, 208896 max block
PSRAM: 5763768/8388608, 5636096 max block
capturing in 10 seconds...
capturing in 9 seconds...
capturing in 8 seconds...
capturing in 7 seconds...
capturing in 6 seconds...
capturing in 5 seconds...
capturing in 4 seconds...
capturing in 3 seconds...
capturing in 2 seconds...
capturing in 1 seconds...
capturing in 0 seconds...
Camera Frame Information:
Width: 1280
Height: 1024
Format: 0
Size: 2621440 bytes
Buffer: 0x3c050d70

When capture fails:

cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
E (11898) cam_hal: FB-SIZE: 2272000 != 3840000
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
W (15778) cam_hal: Failed to get the frame on time!
Camera capture failed
Heap: 335527/458963, 208896 max block
PSRAM: 4545208/8388608, 4456448 max block
capturing in 10 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
capturing in 9 seconds...
cam_hal: EV-VSYNC-OVF
capturing in 8 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
capturing in 7 seconds...
cam_hal: EV-VSYNC-OVF
capturing in 6 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
capturing in 5 seconds...
cam_hal: EV-VSYNC-OVF
capturing in 4 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
capturing in 3 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
capturing in 2 seconds...
cam_hal: EV-VSYNC-OVF
capturing in 1 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
capturing in 0 seconds...
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
cam_hal: EV-VSYNC-OVF
W (34778) cam_hal: Failed to get the frame on time!
Camera capture failed

I have changed Default/Maximum Log Verbosity in menuconfig to Verbose. It only increased the amount of log during the boot, but nothing more comes out around the capturing part.

As far as I can tell, multiple modules I own exhibit the same behavior.

Please give me any insights you have. Where in the source code I could take a look, where I could probe more, etc. I could look into the library itself, too. I'd be happy to hear even just "I have no idea".

macksal commented 3 months ago

EV-VSYNC-OVF is output when a VSYNC event can't be posted to the internal event queue. Events are posted by DMA and VSYNC interrupts and consumed by the camera task. The camera task is ultimately responsible for initiating DMA. The event overflow means that the CPU can't keep up with the events coming from the queue.

What's your XCLK/framerate? Remember RGB565 in particular is 2 bytes per pixel.

On the ESP32-S3, you can enable "psram mode", I think by setting xclk=16mhz. This removes the extra copy from "bounce buffers" during the frame, so the bottleneck usually becomes the memory bus rather than the CPU. Keep in mind the memory bus has a hard write limit of 80MB/s, but you're still competing with the same SPI bus used by the cpu to access psram/flash and the practical limit is much lower in non-ideal scenarios.

I haven't used RGB565 or YUV formats myself, and it is possible there's a bug. Since you're only seeing the issue at higher resolutions though, I think you are likely maxing out the bandwidth of either the CPU or memory bus.

SYPark0795 commented 2 months ago

I think I experimented with config.xclk_freq_hz both on 20mhz and 16mhz. EDIT: For the framerate, I'm not doing anything fast. I'm just experimenting if high quality / RAW capturing is possible at all. I do have config.grab_mode = CAMERA_GRAB_WHEN_EMPTY; in the code, if this matters. What I'm interested in is high quality photo, and high framerate is not needed whatsoever - 1 shot / 10 min at best.

The issue is not only at higher resolutions. Why does it have the same issue on 1024x768, but not on 1280x1024? Why is YUV422, having half the size, behaving the same regarding the resolutions if the bandwidth is the problem?

(Just in case, I have not transferred the image to confirm if the image looks okay. Is it possible that 1280x1024 is being "captured" but actually garbled?)

SYPark0795 commented 2 months ago

I have just tried config.xclk_freq_hz at 16MHz, and it makes the MCU fail to detect the camera

Initializing the camera...
Heap: 368271/423603, 270336 max block
PSRAM: 8385720/8388608, 8257536 max block
I (6891) s3 ll_cam: DMA Channel=0
I (6891) cam_hal: cam init ok
I (6901) sccb: pin_sda 40 pin_scl 39
I (6901) sccb: sccb_i2c_port=1
E (6921) camera: Camera probe failed with error 0x105(ESP_ERR_NOT_FOUND)
E (6921) gdma: gdma_disconnect(305): no peripheral is connected to the channel
Camera initialization failed

With xclk at 20MHz, both RGB565 and YUV422 are still failing on 1024x768, succeeding on 1280x1024, failing on 1600x1200. I remember experimenting on 16MHz as well, so this is odd... I'll be experimenting a bit more with the menuconfig options, and update if anything different happens.

github-actions[bot] commented 3 weeks ago

This issue appears to be stale. Please close it if its no longer valid.

SYPark0795 commented 2 weeks ago

I still would like to hear the answer...