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

  • #11
    Originally posted by nazar-pc View Post

    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).
    AV1 surely isn't, can't decode anything past 720p on Youtube with my desktop computer.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #12
      Originally posted by darkbasic View Post

      AV1 surely isn't, can't decode anything past 720p on Youtube with my desktop computer.
      On Firefox, I had 720p working on a quad-core Phenom II mobile chip. 2.2 GHz, I think.

      Comment


      • #13
        Odd. Any modern x86_64 dekstop CPU should easily be able to decode 1080p60 8-bit AV1 fairly easily

        To answer some of the statements about codec stuff:

        1. Chrome will be enabling AV1 encoding support. This will likely be enable only through the form of aomenc in realtime mode, which is actually quite fast to encode at low resolutions and low bitrate, and is still more efficient than h.264 and VP9 encoding at these low bitrates, even though it's severely handicapped vs the normal encoder.

        2. Today, AV1 software decoding with dav1d is faster for the same bitrate vs h.265 decoding. VP9 with ffvp9 as a decoder is faster per thread than h.264 decoding, although as you up the thread count, h.264 decoding with ffh264 becomes faster.

        If you have more questions, I can probably answer some of them in this regard.

        Comment


        • #14
          Originally posted by BlueSwordM View Post
          Odd. Any modern x86_64 dekstop CPU should easily be able to decode 1080p60 8-bit AV1 fairly easily
          Well, my overclocked AMD Ryzen 5 2400G couldn't keep up with AV1 decoding at 1080p60 (or maybe it was 1440p60, not 100% sure). At least on Youtube.
          ## VGA ##
          AMD: X1950XTX, HD3870, HD5870
          Intel: GMA45, HD3000 (Core i5 2500K)

          Comment


          • #15
            Originally posted by darkbasic View Post

            Well, my overclocked AMD Ryzen 5 2400G couldn't keep up with AV1 decoding at 1080p60 (or maybe it was 1440p60, not 100% sure).
            Hmm, was this on Chrome or Firefox? My i5 6500, which was no HT and considerably lower clocks played 1080p60 8-bit just fine on YT on Firefox.

            Comment


            • #16
              Originally posted by BlueSwordM View Post
              Odd. Any modern x86_64 dekstop CPU should easily be able to decode 1080p60 8-bit AV1 fairly easily

              To answer some of the statements about codec stuff:

              1. Chrome will be enabling AV1 encoding support. This will likely be enable only through the form of aomenc in realtime mode, which is actually quite fast to encode at low resolutions and low bitrate, and is still more efficient than h.264 and VP9 encoding at these low bitrates, even though it's severely handicapped vs the normal encoder.

              2. Today, AV1 software decoding with dav1d is faster for the same bitrate vs h.265 decoding. VP9 with ffvp9 as a decoder is faster per thread than h.264 decoding, although as you up the thread count, h.264 decoding with ffh264 becomes faster.

              If you have more questions, I can probably answer some of them in this regard.
              Problem is aomenc is very very slow. Rav1e is somewhere in middle and SVT-AV1 is by far faster. Using aomenc for realtime encoding seems to be by far worst choice.

              Comment


              • #17
                For those who like Chrome, check out Edge it is a better version of Chrome.

                Microsoft Edge Insider build is now available for Linux.

                Comment


                • #18
                  That's not true actually if you actually know what you're doing.

                  Remember, the defaults for aomenc are awful in terms of speed efficiency. Never use them for actual speed comparisons.
                  For aomenc-av1, the default is CPU-0, the slowest preset, which is abominably slow.
                  ffmpeg's libaom-av1 has the default as CPU-1, the 2nd slowest preset, which is also abominably slow.
                  Also, don't use stable releases. For new codecs with still relatively immature encoders, using the latest versions is often important to gauge the speed and efficiency

                  If you actually use realistic presets(CPU-4 to CPU-6) for encoding, aomenc is actually decently fast, especially if you can take advantage of chunked encoding.
                  For high quality encoding, it's actually your best bet overall if you want the most quality without being abominably slow, as can be seen here: https://preview.redd.it/77nf5mohghc6...9fe3b7c4e5be3b

                  Comment


                  • #19
                    In addition to what you said, the realtime set of tools makes a big difference compared to other encoders, which are usually tuned for an "easier" target like movies, where you have an "infinite" amount of time to work, making aomenc suitable for different use cases.

                    Comment


                    • #20
                      Originally posted by piotrj3 View Post

                      Problem is aomenc is very very slow. Rav1e is somewhere in middle and SVT-AV1 is by far faster. Using aomenc for realtime encoding seems to be by far worst choice.
                      Rav1e is significantly slower than reference encoding right now. you can even check on openbenchmarking.

                      Svt-av1 is probably a good alternative, but its lacking in some quality, it is much faster at traditional linear rendering. although Aomenc is faster when using per scene encoding, thats not very useful for live streaming.

                      I am assuming they decided SVT-AV1 is still too immature for their use case, though i see this changing in the future

                      Comment

                      Working...
                      X