Announcement

Collapse
No announcement yet.

Chrome 89 Preparing To Ship With AV1 Encoder For WebRTC Usage

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chrome 89 Preparing To Ship With AV1 Encoder For WebRTC Usage

    Phoronix: Chrome 89 Preparing To Ship With AV1 Encoder For WebRTC Usage

    Now that Chrome 88 released, attention is turning to Chrome 89 of which an interesting technical change is the enabling of AV1 encode support within the web browser...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available

    Comment


    • #3
      Originally posted by FireBurn View Post
      Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available
      As someone who works with WebRTC I can assure you that not every hardware acceleration is suitable, is used or doesn't cause various issues including browser crashes.
      It is nice when it works, but most often it doesn't for WebRTC.

      Comment


      • #4
        Originally posted by FireBurn View Post
        Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available
        They are not moving to AV1, just enabling it. The other codecs will remain available.

        Comment


        • #5
          Originally posted by FireBurn View Post
          Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available
          WebRTC applications can set a preference. e.g. Jitsi Admins can set either VP8 or h.264 as preferred codec. Of course the one that can be used best with every participant will be used

          Originally posted by nazar-pc View Post

          As someone who works with WebRTC I can assure you that not every hardware acceleration is suitable, is used or doesn't cause various issues including browser crashes.
          It is nice when it works, but most often it doesn't for WebRTC.
          While that might be true, h.264 undoubtedly should be much faster either way since it's much easier to encode

          Comment


          • #6
            Originally posted by Artim View Post
            While that might be true, h.264 undoubtedly should be much faster either way since it's much easier to encode
            Encoding is not always the most intensive operation in multi-party WebRTC communication
            And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.

            Comment


            • #7
              Originally posted by nazar-pc View Post

              Encoding is not always the most intensive operation in multi-party WebRTC communication
              And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.
              What should be the most intensive one then? Decoding because of the multiple streams?
              ## VGA ##
              AMD: X1950XTX, HD3870, HD5870
              Intel: GMA45, HD3000 (Core i5 2500K)

              Comment


              • #8
                Originally posted by darkbasic View Post

                What should be the most intensive one then? Decoding because of the multiple streams?
                Often yes, and VPx are sometimes faster to decode. Also rendering depending on how optimized it is (there was a lot of tuning in Chromium related to this recently).

                Comment


                • #9
                  Originally posted by nazar-pc View Post

                  Encoding is not always the most intensive operation in multi-party WebRTC communication
                  And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.
                  well, I can tell you from experience that it's true at least for older hardware. On my Laptop with a Core i5-4210U there is no way I can use Jitsi in Chrome when using VP8, I would have to resort to my phone. Otherwise, both my audio and video quality is horrible and the video quality of others is very bad. No problem when forcing it to h.264. Or when using Zoom, which for all I know uses h.264...as long as you don't use the browser version (at least it was unusable for me about a year ago).

                  But I can't tell you if there were any improvements in the last half year, the compatibility of Jitsi is just too bad, so we currently use Zoom for everything.

                  Comment


                  • #10
                    Originally posted by nazar-pc View Post

                    Encoding is not always the most intensive operation in multi-party WebRTC communication
                    And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.
                    Exactly. Wall plugs are everywhere and ISP bandwidth quotas are usually ridiculously expensive.

                    Comment

                    Working...
                    X