Greetings everyone,
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 up
or2020.1 and up
. So I end up using2019.4.24f1
- 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 anhttps://
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 fromhttp://
url (but the how-to post encourageshttps
) - 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-Type
header must be'application/json'
. - 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.
Another smart bypass solution that I see mainly on javascript applications is the cors-anywhere proxy or any custom proxy server that will have the functionality for browserâs CORS policy but also communicating with ThetaV for the MJPEG streaming. But I havenât found a way to implement this embedded to my WebGL build.
In conclusion, I make this post hoping that some of you could help me with this.
Best regards,
Dimitris