LockerGnomeFor serious tech professionals with a silly side.
Subscribe

Search

Softwarewebrtcobsffmpegvideo-callsopen-standards

Shitty Screenshare, From the Developer Behind WHIP in OBS, Says Your Blurry Video-Call Share Is the Browser's Fault and OBS or FFmpeg Can Send It Instead

A one-page site from Pion's Sean DuBois puts a browser screenshare beside an OBS one and points at WHIP, the open standard that lets OBS and FFmpeg push WebRTC video straight to a service with settings you pick.

Chris holds up a crisp, sharp monitor showing a clean grid beside a smeared, blurry one, a video camera cable running from the sharp screen out of frame
Illustration: LockerGnome

The page opens on two looping videos of the same spreadsheet. The one labelled “BROWSER SCREENSHARE” is the mush everybody has squinted at in a Tuesday meeting. The one labelled “OBS” is a spreadsheet you can read.

“Why is my screenshare blurry?” the FAQ asks itself, and answers: “A lack of control. Your browser is picking a bitrate, codec or resolution that doesn’t match what you need.” The fix it sells is three words in big type: “You need WHIP.”

The site doesn’t sign a name. It says “I work on WHIP in OBS” and links siobud.com, the contact page of Sean DuBois, which lists OBS WebRTC among his current projects beside Pion WebRTC, the Go implementation of WebRTC. His reason for the site is one line: “I’m tired of shitty screenshares when it is easily fixed.”

WHIP is published as RFC 9725, dated March 2025, a “simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services.” The setup reads like any stream key. “Your provider gives you a server URL and a stream key, called a bearer token,” the site says. Before that, “each client had to run custom code. That means FFmpeg/OBS would never be able to join.”

FFmpeg has the other half. Its format docs list a whip muxer for “sub-second latency streaming according to the WHIP” spec, marked “an experimental feature,” and ask for H.264 without B-frames and Opus audio.

The site also heads off the obvious workaround. OBS Virtual Camera feeds your scene into the meeting app as a webcam, “but the conferencing app still handles encoding,” so the app’s choices still win.

Then comes the catch. “Where can I stream with WHIP today?” points to the OBS WHIP guide, which lists Cloudflare, Dolby OptiView, Red5, Tencent, Twitch, Broadcast Box and Stage TEN. Zoom, Teams and Google Meet aren’t on it. For everyone stuck on those, the site’s advice: “Send them an angry email. Tell them you don’t want their crappy proprietary client.”

WHIP was written for getting video into streaming services and CDNs, and the RFC says so in its first sentence. The pressure on meeting apps runs the other way: once streamers get used to picking their own encoder for Twitch, a blurry share in a client they can’t tune starts to look like a choice the vendor made. The likely first movers are the WebRTC platforms that already sell to developers, since a WHIP endpoint is a feature they can bolt on and a sales line they can write.

The page never says whether its angry-email campaign has moved anyone. The list it links is the scoreboard, and the first meeting app to show up on it will be the one worth watching.

More Software

Every Software story →