search

marek-simonik / record3d

Accompanying library for the Record3D iOS app (https://record3d.app/). Allows you to receive RGBD stream from iOS devices with TrueDepth camera(s).
https://record3d.app/
GNU Lesser General Public License v2.1
382 stars 55 forks source link

WebRTC calls over HTTP causing security warnings #11

Open twmmason opened 3 years ago

twmmason commented 3 years ago

Thanks for the work - nice app. Purchased full version today.

Is there anyway to get the iOS app to serve over HTTPS as it's failing in Chrome etc due to mixed content security. It is possible to set Chrome flags to get around but is not the best for obvious reasons. Happy to help if needed. I suppose there may be a way of using a proxy service.within React/Angular etc.

marek-simonik commented 3 years ago

First of all, thank you for purchasing and using Record3D.

I could not think of any easy and user-friendly solution that would support HTTPS, please see the discussion in this Issue: https://github.com/marek-simonik/record3d-simple-wifi-streaming-demo/issues/1

In a nutshell, as far as I know, I could only use self-signed HTTPS certificate in the iOS app, which would cause browser issues as well. An intermediary HTTPS server ([Record3d on iOS] --- [HTTPS proxy on a PC] --- [WebRTC peer receiving the stream]) would solve this issue, but this would not be easy for non-tech people to get working.

That is why I published the Wi-Fi Streaming demo on an HTTP-only website, so that you can try it without mixed content errors: http://record3d.xyz.

I know it is not a real solution, but only a workaround, however, this is the best I could come up with.

andybak commented 3 years ago

Thanks. I've just had a play and it seems to work well.

Out of curiosity - why are you encoding depth as hue via RGB > HSV?

Why not just treat the RGB as a 24bit int (or float)? Aren't some of the available bits in the RGB being wasted?

ixxy.co.uk • t 01273 906061 • m 07968 119324

On Mon, Feb 1, 2021 at 11:01 AM Marek Šimoník notifications@github.com wrote:

First of all, thank you for purchasing and using Record3D.

I could not think of any easy and user-friendly solution that would support HTTPS, please see the discussion in this Issue: marek-simonik/record3d-simple-wifi-streaming-demo#1 https://github.com/marek-simonik/record3d-simple-wifi-streaming-demo/issues/1

In a nutshell, as far as I know, I could only use self-signed HTTPS certificate in the iOS app, which would cause browser issues as well. An intermediary HTTPS server ([Record3d on iOS] --- [HTTPS proxy on a PC] --- [WebRTC peer receiving the stream]) would solve this issue, but this would not be easy for non-tech people to get working.

That is why I published the Wi-Fi Streaming demo on an HTTP-only website, so that you can try it without mixed content errors: http://record3d.xyz.

I know it is not a real solution, but only a workaround, however, this is the best I could come up with.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/marek-simonik/record3d/issues/11#issuecomment-770770207, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOVA2AO6DSA4KNWDA5FOTS42CXDANCNFSM4W35CYPQ .

marek-simonik commented 3 years ago

Some bits are definitely being wasted. However, I think it is better than to store the raw 24bit value into RGB due to compression artifacts of the most significant bytes.

If I am not mistaken, then mp4 does not compress the 24bit value at once, but rather it compresses each of the R, B and B color planes separately. So you would need to slice the 24bit value (e.g. 0b011101011011101011101011) into 3x 8bits (i.e. R = 0b01110101, G = 0b10111010 and B = 0b11101011). Compression artifacts occurring in the R and G bytes would hinder the accuracy and would introduce unbearable noise.