A stream inside a browser page inside a stream inside a browser page. The delay isn't that bad.

Wasn't too hard by updating the screen material, just need to fix the flipped video. Damn that's exciting!

And when break is done, the camera would seamlessly zoom to the screen. No OBS scene transitions, only a single browser source with WebRTC feeds.

There's also an other way for the desktop GUI: I could stream the scene to the 3D scene, but it would add even more delay.

Ah tiens, oui en effet (developer.mozilla.org/en-US/docs/M...). J'avais toujours pensé le contraire. Et bien je me coucherais moins con ce soir dans ce cas.

L'extension navigateur utilise le good old jQuery des familles, respect. Par contre devoir gérer deux codebases (une pour Firefox et une pour Chromium) alors que le namespace commun `browser` existe (avec github.com/mozilla/webe... pour le support pré-Chromium 144) l'est un peu moins.

Elle est actuellement dans la spirale Rhythm Doctor.

Et là plot twist, le recruteur était également un LLM et ils parleront jusqu'à la fin des temps.

Dommage que l'initiative a été avortée, en plus de n'avoir aucune préservation.

And realtime audio visualizer done, using the same principle as the game capture. I don't know if there's a prettier way to render the frequency (currently doing `Math.pow(value / 255, 0.6)` from `analyser.getByteFrequencyData()`)

By doing that, only the host handles the actual server communication so clients can just do the following as long the parent document have an active client to communicate:

To quickly explain how it's working: there's a top document acting as host and the actual graphic is inside a iframe and the worker is created by the latter, it's like a tree where each nodes has to be aware of their children to correctly propagate messages.

I think the new version is working. Only took me a day of torture to make a decent working protocol.