Hacker News Reader

Comment by pacifika | Hacker News Reader

What are (if any) the technical blockers for Firefox to be considered on the same level of support?

You cannot achieve true E2E encryption on Firefox as it doesn't support insertable streams, so I guess this is where the limitation is.

EDIT: bug on bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1631263

E2E is on by default as in all P2P webrtc calls. What you can't do is use a SFU and still get E2E. Perhaps I'm just missing something but why would you want a SFU AND E2E? Why not just use TURN in those cases (if the problem the SFU is meant to fix is routing)?

An SFU lets your video/audio streams scale. If there were only ever two people, sure, you could use a TURN server if P2P failed, but if you invite 4 people on the call, an SFU will allow each person to upload their stream to the SFU which will then distribute it at various bitrates to the other people on the call.

Just to add some context for muggles such as myself who were unaware of what an SFU is, it stands for "Selective Forwarding Unit".

https://webrtcglossary.com/sfu/

https://stackoverflow.com/questions/60013467/one-to-many-liv...

Except that if the call is E2E then the SFU can't do things like reencode to a different bitrate. Also wouldn't the decryption keys need to be distributed to all the participants of the call via the centralized service anyway since the stream is already in progress? Or am I just being thick in not understanding how a SFU and E2E would bring all of the benefits of both?

The originating browser is responsible for encoding all the desired quality levels and sending them to the SFU to decide what to forward to the other participants - that is the difference between a SFU and a MCU, and why SFUs can scale. SVC-capable codecs are coming to WebRTC too, which makes this a lot more efficient for the browser to do.

Encryption keys are distributed out of band of the media, so it's the same as whatever the tradeoffs are for multi-party E2E-encrypted text chat there (I don't know what those are though!)

Then how come Zoom works in FF?

Because the Zoom web client doesn't support end-to-end encrypted calls. Only their apps do.

https://support.zoom.us/hc/en-us/articles/360048660871-End-t...

That can‘t be why – one benefit of their weird way of using WebRTC is that it would actually allow them to provide end to end encryption in all browsers, regardless of support for WebRTC insertable streams.

Zoom does very weird things in the browser. They essentially don‘t use WebRTC, but rather grab raw camera frames, H.264 encode them in software (using WASM!) and shove them down a Websocket (or WebRTC Data Connection. This lets them use their own encryption as well.

More details: https://webrtchacks.com/zoom-avoids-using-webrtc/

It looks like mozilla has marked that standard as worth prototyping: https://github.com/mozilla/standards-positions/issues/330

Firefox can require more bandwidth for WebRTC calls I think, see https://bugzilla.mozilla.org/show_bug.cgi?id=1600698

I also have some memory of asking all participants in Jitsi meetings to not use firefox, because the call would start to lag for all participants if bandwidth was an issue for the firefox users in the call. Don't know if that is still the case or not though.

This should be fixed.

Sorry, your comment is ambiguous; "should be" as in "needs to be fixed" or as in "has been fixed"?

The issue is open so it can only mean that it needs to be fixed.

If you read to the end, it looks like the expected underlying reason is now fixed, but it hasn't been confirmed yet whether it resolved the problem. If someone knows how to reproduce, they could try it out and comment there.

At a guess, codecs seem the most likely explanation.

Firefox has a h.264 decoder, but not an encoder I think.

Maybe... Google Duo works in Firefox (and even Opera) though.

Important: Google Duo is available on Google Chrome, Microsoft Edge, Firefox, Opera, and Safari.

Source: https://support.google.com/duo/answer/6386089

Does Duo send H.264?

As far as I've read about Duo it seems to be AV1:

https://www.xda-developers.com/google-duo-lyra-codec-better-...

...though I'm not sure whether they use it consistently.

How does this happen? AV1 encoding codec was still work in progress, and most chips don't support any hardware acceleration for this. Can we get reasonable frame rates on core CPU for av1 encoding already?

Duo uses AV1 for very low bandwidth calls. And then a mix of H.264 / VP8 / VP9 etc.. depending on many parameters. Disclaimer: worked on the product. https://blog.google/products/duo/4-new-google-duo-features-h...

Why can't firefox invoke the system dll or libraries for H.264 encode/decode? Like many video players do.

Why must every browser ship its own codec or even Unicode collection is beyond me.

For H.264, it's a question of patents IIRC. Cisco granted a free of charge decoder, but not necessarily an encoder.

Hi ow can I pay to get the encoder into my FF? Like I paid to get some en/decoding in my raspberry pi’s.

I personally believe Raspberry Pi made the wrong decision in using non-free hardware which required non-free firmware to operate key features such as video encoding/decoding.

Why would we encourage Firefox or others to do the same and develop a business model based on patents? Especially so when these patents are owned by huge conglomerates of corporate psychopaths (hello MPEG-LA) and the software editor we're talking about (Mozilla) had to lay-off a lot of staff during the confinement by lack of funds.

To be fair, Firefox is more than capable to encode/decode into free codecs and there's no reason why a third party plugin couldn't support H264 encoding as well. It falls on Apple to support proper standards for their communications platform and not on Firefox to support every piece of proprietary tech they can come up with.

But well, we all know what Apple thinks of standards. With their AirPlay, iMessage, iCloud and other Apple-specific solutions. If only we had free-software, standards-compliant solutions to all these computing problems. /s

For the record, I very much agree with you.

Because of a long tradition of the system libraries being fucked.

All this stuff started in the days of Windows XP, which shipped with such a meagre selection of codecs you couldn't even play DVDs.

And the codecs you could download? Either they cost money (i.e. most users wouldn't have them), or they were dodging license costs by some questionable means, or they had bigger aspirations than just providing a mere codec (flash/realplayer/quicktime)

VLC arose out of that and became popular because, by ignoring the system codecs, it could actually play the damn file.

VLC also has the advantage of being developed in France, where the legal system does not recognise software patents.

Really! My respect for France has gone up a few notches.

Don't get too excited, in France there's a tax on all storage devices (sd cards, usb sticks, hdds, laptops, phones etc) to help subsidise the record and film industry...

We have that in Italy too, but at least that means that ripping CDs or DVDs is entirely legal. It's actually called private copy contribution.

Yep it actually came from Germany, and was afterward adopted by a lot of european countries

Germany has that too. Even on paper, since you could copy pages under copyright.

Note that internal HDDs aren't taxed under this tax, only external ones. (So if you don't want to pay it, you can just buy a SATA HDd and an adaptor). Phones are taxed though (yes this doesn't make any sense technically)

Is the tax on a phone's storage capacity or its overall retail price?

On the storage capacity

Honestly, I'd take that trade. A narrow, stupid tax is definitely the lesser of two evils here. (Especially as it means I'd have a moral license to pirate whatever I wish!)

There was a lot of back and forth [0] over this back when Firefox added support for system libraries. The FOSS purists only wanted to support codecs they could include in Gecko (long before OpenH264) while the pragmatists wanted to make a useful web browser.

Support for system libraries first appeared on mobile platforms because it was essential. At the time (ca 2011/12) the likes of YouTube and Vimeo were only delivering MP4 to mobile clients.

The purists seemed to think that somehow if Firefox held the line on (likely but not guaranteed) unencumbered formats/codecs that every content producer would see the light and go with those objectively worse codecs with no hardware acceleration for video content.

This completely ignored the fact that Flash was common on desktops and supported encumbered codecs just fine. It was in fact the primary delivery vehicle for them. The NPAPI content hole let the purists be intransigent while actually using content on the web. They were also ignoring the design of the HTML5 video tag that encouraged inclusion of multiple source formats and some sort of fallback including object embeds.

As for Microsoft they were still pushing the various Windows Media codecs as the One True Way in the Windows XP and Vista eras. They had to support MP4 with Windows 7 because every smartphone and most stand alone cameras were capturing video in MPEG-4 codecs if not file formats.

[0] https://groups.google.com/g/mozilla.dev.platform/c/-xTei5rYT...

Microsoft still doesn't include basic codecs like H.264 in some Windows editions ("N" and "KN" for some regions in the EU and Korea), but those users can download Microsoft's Windows Media Feature Pack to get the codecs:

https://support.mozilla.org/en-US/kb/fix-video-audio-problem...

I'm pretty sure it does use system libraries for decode

Firefox used to be able to do this, but they don't anymore for strategic or political reasons. They don't want website authors to depend on certain codecs that some users have on their PC but some others don't. I can understand the rationale, but think it is a bit sad.

It's possible and it's compile time option, source package managers like portage allow you to do that.

That's why it downloads the openh264 encoder binary from Cisco

If there are any (as opposed to "just" the added customer support burden), I wonder if they're the same issues that prevent Slack from allowing calls in Firefox...

As a corollary, I wonder if Slack will now implement calling functionality once Mozilla adds the necessary APIs for Apple to do its job here, which is probably very likely since I don't think Apple chose to ignore a non-Google browser on purpose.

All necessary parts are there, which is why e.g. jitsi meet or Google meet work without problem.

It's more like they don't care than anything else.

Slack uses Amazon Chime as backend Chime is using h264 firefox still can not encode h264 videos in real time.

Yes, so it's precisely another case of "we tested on chrome and it works", which falls under "don't care" software development best practices.

No, it's very practical. A lot of devices are just too weak to encode anything other than H.264 so that's the one codec you must support.

Other codecs are better, but you have to do more testing and enable those codecs only on calls where all members are using a device that supports it.

> A lot of devices are just too weak to encode anything other than H.264

Not that your point is wrong, but a lot of devices are too weak to encode/decode H264 as well. It's very recent for me to have access to second-hand hardware with H264 support and still i'm in western Europe where it's easier to come by.

Though as the other commenter pointed out, if you can afford to use hardware en/decoders then it's always the better option.

Are you sure you're not thinking of H265?

I'm kinda curious which devices don't support H264

Unfortunately, hardware VP9 decoding isn't really well-supported except in high-end phones (in context of multiple decoding, single decoding works fine) due to bugs in Mediatek's implementation. There's software decoding, but that's still taxing to a phone, and transcoding to H.264 server-side but that doesn't bode well to end-to-end encryption.

Slack calls didn't used to work on Firefox even if you bypassed their user-agent block.

In recent months, after bypassing the user-agent check, calls will at least work albeit not very well. (bit laggy, long connection time)

Apple Business Manager recently stopped working in Firefox and that is a basic portal.

Not a blocker, but certainly a consideration. Chrome and Edge both share a common ancestor: WebKit (Safari).

Reply on news.ycombinator.com