Electric Gremlin

Today in "The spiky lemon takes breaks from fantasizing about shiny witch outfits to do bad things with WebRTC":

I did a group hangout stream purely off my browser-based window capture solution and discovered something annoying. The capture is both variable framerate, and refuses to go above 50fps. You can set a media constraint to say "Put out 60" but it'll dutifully be ignored past a certain point and that point seems to be 50fps, motion requiring.

This seems to be unique to getDisplayMedia(), the method to capture desktops/windows. getUserMedia(), the method to get webcam, does not seem to have this problem.

A lot of reading later it seems to boil down to "This was designed to empower some idiot in a suit to share their powerpoint with a team, not game streams"

A solution must exist because Discord does it. I'll have to dig. I suspect it's building a custom encoder capability string and that sounds gross.

Mar 9 at 8:01pmWeb
Show threadElectric GremlinMar 9

Honestly if I got a stable 50fps because of some asinine constraint Google mandated vis a vis the WebRTC foundation, I could live with that. It's not stable. It spikes down to 20 even during high motion. Like something is resisting keeping the framerate high with some kind of backoff algorithm.

It's not network and it's not SDP. I can sit and watch the encoder itself fluctuate.

Show threadFacadeMar 9
@trysdyn idk if discord uses something available in the browser for >50fps, pretty sure screen sharing specifically is when they step out of electron and use some sort of OS-specific library
Show threadElectric GremlinMar 9
@lycansubscribe Hm. I hadn't used the browser client in ages but it looks like there are settings you just don't have without the electron client, including higher framerates so you may be right.