I am working with a Ricoh Theta V, firmware 3.60.1, focusing on wireless streaming with WiFi Client Mode.
I have found this Unity Project, updated by @KEI, in which a Monobehaviour script handles the MJPEG stream of camera.getLivePreview (Web API v2.1) utilizing the HttpWebRequest of System.Net (with or without Digest Auth).
I wanted to create an updated version of the project with WebGL and WebXR.
I will try to report most of the route I followed:
- in order to use WebXR Export you need Unity Editor version
2019.4.7 and upor
2020.1 and up. So I end up using
this how-to post explains pretty well building an unity project with WebXR except from the part where you must implement your own web server and not unity’s local
Build and Run. I personally used Apache from XAMPP and created a Symbolic Link folder in Windows to easily export and run the WebGL project.
And now the issues part:
- According to WebGL Networking you can’t use HttpWebRequest. WWW is obsolete so the only solution is UnityWebRequest, a class implemented from XMLHttpRequest.
- UnityWebRequest doesn’t a have a Digest Auth feature as far as I searched into it. So I had to disable authentication in ThetaV with camera.setOptions and _authentication parameter via Postman. But be ware, I only succeeded in AP (blue led) WiFi mode.
- When built and run from Chrome and Firefox (which are WebXR compatible) both browsers threw errors for Mixed Content (if you hit
http://RICOH.THETA.IP.ADDRESS/osc/commands/execute from an
https://url). You can turn the error to a warning if you allow “Insecure Content” from browser=>settings=>site settings. Or simply just run WebGL project from
http://url (but the how-to post encourages
- With that done, the CORS policy of the browser started complaining. You are most likely to come across this error:
Access to XMLHttpRequest at ‘http://RICOH.THETA.IP.ADDRESS/osc/commands/execute’ from origin ‘https://MY.PC.IP.ADDRESS’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
I will not go into details about the CORS but it is built into browsers and difficultly surpassed. The 3 ways that I know of are:
- Make your requests to be “simple requests” in order to not trigger a preflight OPTIONS request and thus CORS policy.
- Moesif CORS and Allow CORS extentions for Chrome.
- Add some
'Access-Control-Allow-...'headers on the response of the server side (in this case the OSC server on Theta V).
As you can tell, for me doing this post I have not come to a solution.
- The POST /osc/commands/execute can not be a simple request because the
Content-Typeheader must be
- These extentions provide you the wanted Response-headers but a preflight OPTIONS request is still triggered. The Web API v2.1 conforms the OSC API which only uses GET and POST requests but not responding to OPTIONS requests (check also with Postman), resulting to the below error:
Access to XMLHttpRequest at ‘http://10.64.45.228/osc/commands/execute’ from origin ‘https://10.64.45.107’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.
I didn’t commented on the 3rd listed solution, because I don’t know for sure that I can’t mess with the ThetaV HTTP server of the Web API running on port 80. If that is the case, I could maybe add functionality for responding to OPTIONS request and add the necessary response headers for CORS.
In conclusion, I make this post hoping that some of you could help me with this.