Skip to content

esp_camera_available_frames implementation #723

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pablogs9
Copy link

@pablogs9 pablogs9 commented Feb 12, 2025

Description

This PR adds a functionality for checking if there is an available frame to be read immediately, allowing the possibility of calling esp_camera_fb_get ensuring that there would be no block.

Related

Testing


Checklist

Before submitting a Pull Request, please ensure the following:

  • 🚨 This PR does not introduce breaking changes.
  • All CI checks (GH Actions) pass.
  • Documentation is updated as needed.
  • Tests are updated or added as necessary.
  • Code is well-commented, especially in complex areas.
  • Git history is clean — commits are squashed to the minimum necessary.

@cnadler86
Copy link
Contributor

This would be a great addition, IMHO. Is this under the Radar?? The code looks for me very straight forward.

@cnadler86
Copy link
Contributor

Did you tested it with fb_count 1 and 2, as well as grab mode latest and when_empty?

@pablogs9
Copy link
Author

@cnadler86 not really, but as far as I see this operation is complementary to the operation performed in cam_take():

xQueueReceive(cam_obj->frame_buffer_queue, (void *)&dma_buffer, timeout);

So, we are checking with this new esp_camera_available_frames that this last xQueueReceive will return immediately.

Do you see any additional consideration when fb_count is greater than one, grab mode is the latest or cam_obj->frame_buffer_queue is empty? If so, please tell me and we can iterate through them.

@cnadler86
Copy link
Contributor

I don't think there will be a impact on any current functionality. I can only imagine that the function might return always true or always false in one of the possible configuration cases. I have not taken a deep look at the code and in come cases testing is better than analyzing. That's why I am asking.

@cnadler86
Copy link
Contributor

I tested the PR at application level and it behaves as expected. The FPS will be a little less, since you need to assess at application level weather to "take a picture" or perform some other activities, but with this non-blocking code is possible. Great PR!

@me-no-dev : could you please take a look and in case it is OK, merge this?

cnadler86 added a commit to cnadler86/esp32-camera that referenced this pull request Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants