mainsail-crew / crowsnest

Webcam Service for multiple Cams
GNU General Public License v3.0
302 stars 71 forks source link

Zoom #239

Closed picclock closed 5 months ago

picclock commented 5 months ago

Is your feature request related to a problem? Please describe

Feature request Zoom to a section of the camera feed. Achieved with mouse over point of interest and zoom with scroll wheel. This would not affect the streaming, just the rendering to the webpage window. I am using webrtc with an OV5647 which has a resolution of 2592 x 1944. but the displayed widow compresses the viewable data to a fraction of that. Its useful to detect printing faults early on and a zoom would enable users to do that.

Thx for an excellent useful product.

Best Regards

picclock

Describe the solution you'd like

Crowsnest web page change to allow zoom of video feed using mouse wheel when over picture.

Describe alternatives you've considered

No response

Additional information

No response

mryel00 commented 5 months ago

This will be a bit longer as you have some misunderstanding of the whole concept of Crowsnest and things around it. Make sure to read everything and ask questions if something is unclear.

This FR is nothing we can implement in Crowsnest. Crowsnest is just some bash scripts that provide you a config and service to start backends easily. Those backends are ustreamer and camera-streamer.

Crowsnest web page change to allow zoom of video feed using mouse wheel when over picture.

So there is no "Crowsnest web page". If you go to the IP directly you watching either at the webpage of camera-streamer or the website of ustreamer that is located inside ustreamer-www folder of Crowsnest. As you are using a picam it would be the website of camera-streamer. So it would be a FR for that Repo. But I think there e might be some trouble with that on the webrtc implementation. Teh mjpg stream can be simply scrolled in.

But now we get to the next point connected to this: If you are from the 3D printing community, like most of our users, you most likely are watching the stream through either Mainsail or Fluidd. So that would be then a FR for those. Afaik for Mainsail nothing like that is planned. I cannot speak for Fluidd. But those might have the same problem for webrtc zooming like camera-streamer.

I am using webrtc with an OV5647 which has a resolution of 2592 x 1944. but the displayed widow compresses the viewable data to a fraction of that.

Now we get to the part most users don't even know of. You stream is not 2592x1944!!! How do I know? The Pi HW encoder, used by camera-streamer to encode WebRTC, can only do 1920x1920@30fps. So anything higher is scaled down with the correct parameters. Without those your stream wouldn't start. We already pass the parameter --camera-snapshot.height=1080 by default that you get an image. This now even get's more tricky. It's not exactly scaled down, but the sensor only support a few specific resolutions. So it's choosing the best fitting lower resolution. That should be 1296x972, as shown by the output of libcamera-hello --list-cameras (this will get be inside crowsnest.log soon) Here the output:

pi@mainsailos:~ $ libcamera-hello --list-cameras
Available cameras
-----------------
0 : ov5647 [2592x1944] (/base/soc/i2c0mux/i2c@1/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [43.25 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [30.62 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]

1920x1080 might be closer but is the wrong aspect ratio. To confirm what I wrote, just turn on the debug log and have a look at the first few lines of the camera-streamer initialization. Here is my 4608x2592 resolution v3 cam for an example:

 device/buffer_list.c: CAMERA:capture: Using: 1920x1080/YUYV, buffers=3, bytesperline=3840, sizeimage=0.0MiB
 device/buffer_list.c: CAMERA:capture: Opened 3 buffers. Memory used: 11.9 MiB
 device/buffer_list.c: CAMERA:capture:1: Using: 4608x2592/BG10, buffers=3, bytesperline=5760, sizeimage=0.0MiB
 device/buffer_list.c: CAMERA:capture:1: Opened 3 buffers. Memory used: 42.7 MiB
 device/v4l2/device.c: SNAPSHOT: Device path=/dev/video31 fd=42 opened
 device/v4l2/buffer_list.c: SNAPSHOT:output:mplane: Requested resolution=1920x1080 is unavailable. Got 1920x1088.
 device/buffer_list.c: SNAPSHOT:output:mplane: Using: 1920x1056/YUYV, buffers=3, bytesperline=3840, sizeimage=3.9MiB
 device/buffer_list.c: SNAPSHOT:output:mplane: Opened 3 buffers. Memory used: 0.0 MiB
 device/buffer_list.c: SNAPSHOT:capture:mplane: Using: 1920x1056/JPEG, buffers=3, bytesperline=0, sizeimage=4.0MiB
 device/buffer_list.c: SNAPSHOT:capture:mplane: Opened 3 buffers. Memory used: 12.0 MiB
 device/v4l2/device.c: VIDEO: Device path=/dev/video11 fd=46 opened
 device/buffer_list.c: VIDEO:output:mplane: Using: 1920x1080/YUYV, buffers=3, bytesperline=3840, sizeimage=4.0MiB
 device/buffer_list.c: VIDEO:output:mplane: Opened 3 buffers. Memory used: 0.0 MiB
 device/buffer_list.c: VIDEO:capture:mplane: Using: 1920x1080/H264, buffers=3, bytesperline=0, sizeimage=0.8MiB
 device/buffer_list.c: VIDEO:capture:mplane: Opened 3 buffers. Memory used: 2.2 MiB

As you can see in the second last line: Using: 1920x1080/H264 So I don't get a 4k WebRTC image, even if I specified it.

We added this parameter without directly showing it to the user, as we would get like tons of requests, why the stream doesn't work without it. Also communicating through a log is a bit tricky as not every person reads it. I might add some note about it with the next version. I will fix some cropping issues there too, if you are using non specified resolutions.