It seems you never tested your stuff. The console is full of errors:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194. (Reason: CORS request did not succeed). Status code: (null).
None of the “sha512” hashes in the integrity attribute match the content of the subresource. -oXZ36ekQX2btnYIZSdj2g
WEBGL_debug_renderer_info is deprecated in Firefox and will be removed. Please use RENDERER. chunk-vendors.9d9d262d.js:6:31482
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194. (Reason: CORS request did not succeed). Status code: (null).
None of the “sha512” hashes in the integrity attribute match the content of the subresource. -oXZ36ekQX2btnYIZSdj2g
Some cookies are misusing the recommended “SameSite“ attribute 4
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://416c35e0.hyperbeam.com/ok?vm=0. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.
Object { type: "New", payload: {…} }
app.fc7f578d.js:1:42733
Object { type: "Create", payload: {…} }
app.fc7f578d.js:1:42733
WebRTC: Using more than two STUN/TURN servers slows down discovery 2 vendorlate.27cb1e73.js:14
WebRTC: Using five or more STUN/TURN servers causes problems 2 vendorlate.27cb1e73.js:14
Object { type: "Consume", payload: {…} }
app.fc7f578d.js:1:42733
Consume error: cannot consume1
The "cannot consume1" is the error that shows also on the three.js demo.
The problem with VP8 is it's almost never hardware accelerated, neither on the encoding nor on the decoding side, so it's undesirable. Also, the software encoder x264 is quite far ahead of libvpx vp8 in terms of the encoding cost vs bitrate vs quality tradeoffs in our testing. We really hope AV1 solves all these issues once and for all in the years to come.
I guess you will need to make some compromises to make this work reliably.
My personal experience with WebRTC was: "One can be glad if one gets anything working at all across different environments". 0 stars, would not touch again (or only with a very very long pole; everybody has his price… ;-)).
The other thing that came to my mind is: Why do all that on the server? Seems costly.
One could build a "browser in browser", and share that (partly) P2P through the WebRTC screen-sharing feature. The "browser in browser" would be needed to be able to make that thing interactive as the screen-sharing feature transmits only a video. You would need to capture mouse and keyboard on the webpage within the "virtual browser" (and transmit it though an additional WebRTC stream). Capturing the inputs outside of the browser is not possible afik with WebRTC.
First of all some spyware stuff from cloudflare gets blocked by the ad-blocker.
But this is not the root of the problem as it doesn't work either without the ad-blocker active.
Minified JS Script dies with some cryptic backtrace.
I've tried on the hyperbeam.com website and it does not work either.
It lies straight in my face about a missing H.264 codec. (Which works fine according to https://test-videos.co.uk/bigbuckbunny/mp4-h264).
It seems you never tested your stuff. The console is full of errors:
The "cannot consume1" is the error that shows also on the three.js demo.