Thanks, we vehemently oppose bloat in our JS files ;)

Thanks :)

If you're on linux, you most likely need the H.264 ffmpeg codec package and things like the Cisco OpenH264 plugin for Firefox. Also, try unblocking WebRTC if you block it

Thanks. I just checked and all of these are installed / enabled.

Still, only a black rectangle is shown (also disabled ad blocker).

There are a couple of _warning_ messages in the dev console though, which might explain the origin of the issue:

> An AudioContext was prevented from starting automatically. It must be created or resumed after a user gesture on the page.

> Autoplay is only allowed when approved by the user, the site is activated by the user, or media is muted.

Yea sorry it's our bad, we didn't implement cursor time-slicing in the demo, even though we actually support it on the API: https://www.npmjs.com/package/@hyperbeam/web#setting-permiss...

Hmm, what I was thinking of was that everyone seemed to be competing with each other to click random UI elements on the virtual browser as rapidly as possible, I assume because there wasn't a way to speak with one another / coordinate. Or maybe I just missed the chat area?

Yeah we kept the MVP lean and didn't add chat or audio/video calling. Our goal (which we're not meeting) is to keep the Three.js example line count below 200.

https://github.com/hyperbeam/threejs-example

We'll probably make a new project which is more of a product and less of a code example in the future.

Looks good so far, looking forward to seeing more :)

Thanks for the feedback. We already have this feature, it's just not implemented in this demo currently, but we'll be sure to add it. More info here: https://www.npmjs.com/package/@hyperbeam/web#setting-permiss...

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.

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

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.

Also which OS? I have a hunch your version of Firefox doesn't have the H.264 codec which we need

Thanks! I'm intrigued by what you built (long-time Linux user here), can you share a link?

Whatever I've built is not ready for NH.

Bask in your glory, truly amazing job :)

Hi HN! I'm the CTO of Hyperbeam, happy to answer all the technical questions :)

Thanks! Actually it's neither: we run full Chromium rather than CEF and Mediasoup for webrtc. We have looked into webrtcbin as well, but it wasn't the best fit for us.

Interesting! I've been using webrtcbin for some production work but it's been broadcasting of low latent internally used video with no user input back. I've seen demos of user input with webrtcbin, but have never done it in practice. If you can, do you mind sharing why webrtcbin wasn't a good fit for you (or why MediaSoup was better)?

webrtcbin is nice for one-to-one, but we were looking for something that's a better fit for one-to-many, which is where mediasoup came in. That being said, mediasoup is quite complex from a maintainability perspective since it's designed to handle several use cases, so we plan on making our own webrtc streaming solution in the future that's designed with only one-to-many in mind