Skip to content
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

Camera UI Backend #4

Open
4 tasks
logbasem opened this issue Aug 23, 2024 · 1 comment · May be fixed by #5
Open
4 tasks

Camera UI Backend #4

logbasem opened this issue Aug 23, 2024 · 1 comment · May be fixed by #5
Assignees
Labels
enhancement New feature or request

Comments

@logbasem
Copy link

logbasem commented Aug 23, 2024

FROM BARRETT NOTES:

Currently, we have a "video streamer" that just grabs photos on the Rover from statically assigned camera numbers, then sends them to someone in a web browser.

This setup has a number of issues...

Problems + Thoughts

  • Streamer is extremely slow.
    • Sending photos is slow.
    • Instead, use a live stream.
    • Rust is much better at grabbing, processing, and sending images. Consider using it for the backend.
    • QUIC is preferable for communication. If we don't use one of the popular streaming protocols, use QUIC in our own implementation.
  • There is no information on camera status.
    • Use ROS to get info about them. (this is impossible with the '23 microcontroller setup)
  • Only one person can be looking at the information.
    • Stop using flask for fuck's sake
  • You have to relaunch the entire web server to reset the camera numbers.
    • opencv isn't very flexible here.
      • If you're on Windows, there are no "camera paths" to check.
      • You have to manually manage the camera IDs.
      • It has no unique identifiers.
        • NOTE: The CAP_PROP_CHANNEL property is NOT the video capture identifier. It's just for fancy streaming boxes with multiple inputs (such as IP cameras).
    • libobs might be an incredible choice.
      • It's not used much in robotics, but offers better support for interacting with capture devices.
      • It also has a readable codebase. ;)
@megustaloscheetos
Copy link

Hi everyone! Sorry for the lack of updates regarding this issue. I have been working on it though! But I wanted to say that I have made / found a working solution in Rust with WebRTC (h264) and v4l! While it may not be QUIC, I thought it would still be a good enough choice compared to just sending jpeg frames. Currently, I am just working on an implementation for cleanly streaming to multiple web clients.

@megustaloscheetos megustaloscheetos linked a pull request Oct 3, 2024 that will close this issue
@onkoe onkoe added the enhancement New feature or request label Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants