Show HN: Browse HN Together in Three.js

Re:Show HN: Browse HN Together in Three.js by still_grokking on Saturday August 27, 2022 @04:34PM (#32622920)

It does not work in Firefox on Linux.

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:

  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.

[ Parent | on HN ]

Re:Show HN: Browse HN Together in Three.js by ambyjkl on Saturday August 27, 2022 @04:43PM (#32623002)

You most likely need this plugin: https://support.mozilla.org/en-US/kb/open-h264-plugin-firefo...

Seems like in Firefox, H.264 in WebRTC is supported in an entirely different fashion than other kinds of H.264, like in an MP4 file.

[ Parent | on HN ]

Re:Show HN: Browse HN Together in Three.js by still_grokking on Saturday August 27, 2022 @04:56PM (#32623116)

Besides that WebRTC is a tire fire¹ on any browser, why don't you just use VP8?

Should be available everywhere.

Enabling anything with "Cisco" in its name is out of scope for many (and anyway not available on Google's mobile OS).

___

¹ All implementations have severe quirks and some (like Safari) outright showstopper bugs. BTDT

[ Parent | on HN ]

Re:Show HN: Browse HN Together in Three.js by ambyjkl on Saturday August 27, 2022 @05:02PM (#32623165)

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.

[ Parent | on HN ]

Re:Show HN: Browse HN Together in Three.js by still_grokking on Saturday August 27, 2022 @06:03PM (#32623686)

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.

[ Parent | on HN ]