Announcement

Collapse
No announcement yet.

Chrome 107 Released With HEVC Hardware Decoding, Other Additions

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

  • #11
    Looks like HEVC is supposed to be supported in 108 for Linux:
    web browser compatibility support html css svg html5 css3 opera chrome firefox safari internet explorer



    Originally posted by RejectModernity View Post
    Chromium on wayland is still a shitshow. At least on KDE it can't go over 60fps plus vaapi and Vulkan don't work.
    Other than some occasional visual glitches with images, it works perfectly smooth for me. That's at 1080p and Intel Xe though.
    Last edited by schmidtbag; 25 October 2022, 04:23 PM.

    Comment


    • #12
      Originally posted by linuxgeex View Post

      Given most content is actually 24*1000/1001, 30*1000/1001 and 60*1000/1001, which will judder with precise 60hz timers, 300hz isn't the solution you might think it is. Freesync OTOH really does fix it.
      In this case, the timer alignment change shouldn't have been made, or at least should have offered an option to disable it ("performance" mode).

      Originally posted by linuxgeex View Post
      And mpv actually adjusts the audio to align the playback speed to the physical refresh rate, as well as optionally doing temporal frame interpolation. Press I while playing to see what the actual output frame rate is.
      That's only when video-sync is not set to audio.
      One thing I like about mpv's strategy though is that it doesn't result in noticeable pitch changes (unlike VLC, which also does this but in a terrible manner which shifts the pitch all the time like a broken cassette player).

      Originally posted by linuxgeex View Post
      BTW, the Linux scheduler doesn't actually run faster than 100hz (unless you compile your own kernel with CONFIG_HZ set to something higher), so 125 isn't going to help most people on this forum, let alone 300.

      Yes Chrome can busy-wait to achieve higher than 100hz, but the intent is to reduce resource usage, not increase it, so I'm certain that they're using sleep()!
      Few kernels are compiled with a 100Hz timer. The majority run at 250Hz or 300Hz, with some low-latency kernels running at 1000Hz (e.g. Ubuntu/Debian lowlatency).
      Last edited by tildearrow; 25 October 2022, 11:26 PM.

      Comment


      • #13
        "Enabling support for HEVC hardware decoding with supported GPUs/drivers."

        Yes, one step closer to being able to handle photos (heic) painless on a Chromebook.

        Comment


        • #14
          I'm sad by the lack of mentions of Manifest V3 by 2023. Why get excited for a feature on a web browser nobody will be using soon?

          Comment


          • #15
            time to add ffmpeg decoding as a libva driver so we can get swdec, IIRC someone was working on that, collabora dev maybe?

            Comment


            • #16
              Originally posted by linuxgeex View Post
              BTW, the Linux scheduler doesn't actually run faster than 100hz (unless you compile your own kernel with CONFIG_HZ set to something higher), so 125 isn't going to help most people on this forum, let alone 300.
              Actually nanosleep can work (on my system) at a resolution of up to 100µs, or closer to 10µs with the performance CPU governor, so much better resolution than what CONFIG_HZ would suggest.

              These sleep functions use high-resolution hardware timers (AArch64 usually has 41ns resolution), so how often the kernel tick happens is irrelevant.

              Comment


              • #17
                Originally posted by tildearrow View Post
                Few kernels are compiled with a 100Hz timer. The majority run at 250Hz or 300Hz, with some low-latency kernels running at 1000Hz (e.g. Arch Linux and Ubuntu/Debian lowlatency).
                AFAIK, Arch's standard Linux kernel runs in 300 Hz mode, unless they changed it once again.

                Also, Canonical dropped the "lowlatency" kernel flavor starting with Linux 5.17...

                Comment


                • #18
                  Originally posted by archsway View Post

                  Actually nanosleep can work (on my system) at a resolution of up to 100µs, or closer to 10µs with the performance CPU governor, so much better resolution than what CONFIG_HZ would suggest.

                  These sleep functions use high-resolution hardware timers (AArch64 usually has 41ns resolution), so how often the kernel tick happens is irrelevant.
                  I remember that in the past, 1000 Hz still delivered lower latencies.

                  But don't know if this is still true nowadays, because running a 250 Hz kernel with the "preempt=full" option feels as smooth as ever.

                  Comment


                  • #19
                    Originally posted by Linuxxx View Post

                    AFAIK, Arch's standard Linux kernel runs in 300 Hz mode, unless they changed it once again.

                    Also, Canonical dropped the "lowlatency" kernel flavor starting with Linux 5.17...
                    linux-rt from AUR used to run at 300Hz- whoops, you're right. The Arch kernel runs at 300Hz...

                    Comment


                    • #20
                      ARGHH! HEVC support: no!!!! I thought that non-free codecs were going to die on the Internet. Now we're going to be stuck with another 10 years of MPEG payments...

                      The timing kind-of matches with the EU anti-trust investigations. I guess this means that AV1 is now dead - there isn't enough benefit to warrant using AV1 over HEVC anymore...
                      Last edited by OneTimeShot; 26 October 2022, 04:04 AM.

                      Comment

                      Working...
                      X