8 ms·

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

ilikepi 5y ago
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...
- nexuist 5y ago
  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.
  - dathinab 5y ago
    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.
    - DeliriumTrigger 5y ago
      Slack uses Amazon Chime as backend Chime is using h264 firefox still can not encode h264 videos in real time.
      - southerntofu 5y ago
        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.
        NavinF 5y ago
        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.
        southerntofu 5y ago
        > 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.
        NavinF 5y ago
        Are you sure you're not thinking of H265? I'm kinda curious which devices don't support H264
        zinekeller 5y ago
        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.
  - ChrisMLane 5y ago
    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)
  - mattl 5y ago
    Apple Business Manager recently stopped working in Firefox and that is a basic portal.
ZeroGravitas 5y ago
At a guess, codecs seem the most likely explanation. Firefox has a h.264 decoder, but not an encoder I think.
- deadmutex 5y ago
  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 https://support.google.com/duo/answer/6386089
  - nielsbot 5y ago
    Does Duo send H.264?
    - fwn 5y ago
      As far as I've read about Duo it seems to be AV1: https://www.xda-developers.com/google-duo-lyra-codec-better-call-quality/ https://www.xda-developers.com/google-duo-lyra-codec-better-... ...though I'm not sure whether they use it consistently.
      - bhaavan 5y ago
        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?
        slac 5y ago
        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-help-you-stay-connected/ https://blog.google/products/duo/4-new-google-duo-features-h...
- 5y ago
bwindels 5y ago
Firefox can require more bandwidth for WebRTC calls I think, see https://bugzilla.mozilla.org/show_bug.cgi?id=1600698 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.
- solarkraft 5y ago
  This should be fixed.
  - alimbada 5y ago
    Sorry, your comment is ambiguous; "should be" as in "needs to be fixed" or as in "has been fixed"?
    - sharken 5y ago
      The issue is open so it can only mean that it needs to be fixed.
      - sfink 5y ago
        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.
nklmilojevic 5y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1631263
- SahAssar 5y ago
  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)?
  - ryanar 5y ago
    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.
    - px43 5y ago
      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://webrtcglossary.com/sfu/ https://stackoverflow.com/questions/60013467/one-to-many-live-video-strearming-webrtc-or-websocket https://stackoverflow.com/questions/60013467/one-to-many-liv...
    - SahAssar 5y ago
      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?
zamalek 5y ago
Not a blocker, but certainly a consideration. Chrome and Edge both share a common ancestor: WebKit (Safari).

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...

nexuist 5y ago
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.
- dathinab 5y ago
  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.
  - DeliriumTrigger 5y ago
    Slack uses Amazon Chime as backend Chime is using h264 firefox still can not encode h264 videos in real time.
    - southerntofu 5y ago
      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.
      - NavinF 5y ago
        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.
        southerntofu 5y ago
        > 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.
        NavinF 5y ago
        Are you sure you're not thinking of H265? I'm kinda curious which devices don't support H264
      - zinekeller 5y ago
        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.
- ChrisMLane 5y ago
  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)
- mattl 5y ago
  Apple Business Manager recently stopped working in Firefox and that is a basic portal.

ZeroGravitas 5y ago

At a guess, codecs seem the most likely explanation. Firefox has a h.264 decoder, but not an encoder I think.

deadmutex 5y ago
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 https://support.google.com/duo/answer/6386089
- nielsbot 5y ago
  Does Duo send H.264?
  - fwn 5y ago
    As far as I've read about Duo it seems to be AV1: https://www.xda-developers.com/google-duo-lyra-codec-better-call-quality/ https://www.xda-developers.com/google-duo-lyra-codec-better-... ...though I'm not sure whether they use it consistently.
    - bhaavan 5y ago
      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?
      - slac 5y ago
        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-help-you-stay-connected/ https://blog.google/products/duo/4-new-google-duo-features-h...
5y ago

bwindels 5y ago

Firefox can require more bandwidth for WebRTC calls I think, see https://bugzilla.mozilla.org/show_bug.cgi?id=1600698 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.

solarkraft 5y ago
This should be fixed.
- alimbada 5y ago
  Sorry, your comment is ambiguous; "should be" as in "needs to be fixed" or as in "has been fixed"?
  - sharken 5y ago
    The issue is open so it can only mean that it needs to be fixed.
    - sfink 5y ago
      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.

nklmilojevic 5y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1631263

SahAssar 5y ago
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)?
- ryanar 5y ago
  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.
  - px43 5y ago
    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://webrtcglossary.com/sfu/ https://stackoverflow.com/questions/60013467/one-to-many-live-video-strearming-webrtc-or-websocket https://stackoverflow.com/questions/60013467/one-to-many-liv...
  - SahAssar 5y ago
    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?

zamalek 5y ago

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