WebRTC calls over HTTP causing security warnings

[twmmason]

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]

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]

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 [email protected] 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]

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.