lobsters score: 2 · tags: browsers, web
Where can I use WHIP? Cloudflare, Dolby OptiView, Red5, Tencent, Twitch, Broadcast Box, Stage TEN
None of these seem to be… end-user conference call apps?
Jitsi Meet seems to have rejected it :(
score 1 · canonical
Yeah, the screen share functionality with Zoom, Teams, Discord, etc. results in sharp enough video, or they have toggles to make it sharp. I don’t see what this is solving.
score 1 · canonical
At work, we often have the issue with Teams. But that’s very unlikely they will adopt anything that would help the user. If they could just fix the fact it’s slow as molasses even for chat.
score 1 · canonical
Teams does do the nice thing of supporting NDI output so you can get a nice clean feed for each participant.
* Last I checked, the audio stream is muxed so every video has the same audio.
** It also needs to be enabled by your Teams admin.
*** It adds a scary “Broadcast Capabilities Enabled” banner that can confuse users.
score 1 · canonical
I disagree with this. Text is regularly very blurry and pretty difficult to read, and sometimes that’s luckily fixed when an I-frame arrives (relying on luck and timeouts sucks but it is OK in practice). And worse: jumping mouse cursors which make tracking movements very difficult.
There’s definitely room for improvement. But does it require WHIP? I get the impression the difference would be that the encoder would be smarter and wouldn’t try to use an encoder tweaked for scenes from a webcam with a single person mostly to show presence, when it needs to show sharp screen content. But like, isn’t that just a basic client issue/limitation? Of course two different encoders could be each tuned more specifically but there’s no reason it requires independant processes and a token granting dance.
(but WHIP itself looks nice, especially when you want to introduce another capture since capturing and encoding your screen playing an existing capture is pretty shitty)
score 1 · canonical
Discord has different encoder profiles explicitly with the regular encoder tuned for games/videos and one oriented towards text fidelity (at a lower framerate though, so you do get cursor tracking problems). Zoom seems to default to a text-oriented one, with I think an option tuned towards video.
score 1 · canonical
Interesting. These are the ones I have less experience with. Google meets and Teams have always been pretty bad for screensharing IME. For discord, it makes sense that, by default, it is so tuned towards games and videos that it also needs to detect static content to not be too bad with them.
score 1 · canonical
It was closed by the stale-bot, yes, but the subsequent discussions from the developers made it clear that it isn’t a feature they are interested in and would entail a lot of extra complexity on their end.
score 1 · canonical
deleted by creator
Even if the bot hadn’t closed the request, if I was the maintainer, I’d have likely closed it myself. It felt like yet another drive-by request where the requester wasn’t particularly invested in the outcome. The requester couldn’t even be bothered to explain what problem(s) WHIP attempts to solve. The least they could do is have lain out some use cases where adding WHIP to Jitsi would solve some known problems or fill a known gap, by referencing existing issues. The OP didn’t even bother engaging with the issue after it was open.
Maintainers have to be forgiven for not engaging with these sort of uninvested feature requests.
score 1 · canonical
Send them an angry email. Tell them you don’t want their crappy proprietary client. You want open standards that let you bring the tools you prefer.
This is the energy I like to channel
score 1 · canonical
Sometimes politeness doesn’t show that you care enough? I send one of these (sometimes polite, sometimes angry) about every other week to some service… one time I got so fed up with my bank not responding appropriately to my message that they had been sending emails in plaintext (no TLS), I went to a bank branch & told them I wasn’t leaving until the stuff sent a formal request up to HQ ’cause bank comms shouldn’t be without encryption—that stubbornness got them to enable TLS a week later.
(Ironic since I am now trying to leave that bank after pleading for 5 years for them to get an open alternative to SMS 2FA (TOTP or FIDO2). Instead of heeding my complaints, they are shutting down internet banking due to new regulations making better 2FA a requirement & the bank now labeling it less work to shut it down in favor of a locked down app instead of building out the feature)
score 1 · canonical
Why is my screenshare blurry?
A lack of control. Your browser is picking a bitrate, codec or resolution that doesn’t match what you need.
I don’t think very many people would like to manually set the bitrate, codec, and resolution in their work screenshare.
score 1 · canonical
But I don’t think that’s what this is proposing. I’ll admit it’s unclear from the site, but from what I gleaned from the linked Jitsi issue above, this is allowing apps to natively share their output (video or audio) without getting “translated” by the video conferencing app. It would seem like we effectively are manually setting all those things, only to a single group of settings chosen by Teams or Zoom or whomever.
On the flip side, this feels like a wonderful avenue for security issues so I can see the resistance. On the third hand, with proper authentication controls, maybe not.
score 1 · canonical
The problem with allowing WHIP directly for the likes of Zoom, Google Meets, and Teams is that they need to balance between producers and consumers. They need to ensure the encoded media is using an encoder configuration that the consumers, or themselves in the case of transcoding, can decode. They also need a way to control bandwidth towards consumers, for example by having several quality levels to pick between. All of this to say: to create a good conferencing experience you need to control the way media is encoded and decoded, allowing arbitrary media ingress is not compatible.
score 4 · canonical