Announcement

Collapse
No announcement yet.

Chrome Working On JPEG Encode Accelerator With VA-API/V4L2 Support

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

  • Chrome Working On JPEG Encode Accelerator With VA-API/V4L2 Support

    Phoronix: Chrome Working On JPEG Encode Accelerator With VA-API/V4L2 Support

    Landing in the Chromium browser code-base this morning is a JPEG encode accelerator interface...

    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
    I admit it sounds a bit silly to me to do just JPEG HW encoding, I mean, a single JPEG of normal resolution shouldn't be that much of a burden even for a low end CPU these days. And I'm not sure what to think of direct-in-browser-screenshots, I mean, that functionality offers a lot of abuse potential.
    But HW acceleration like that might be nice for programs that really deal often with larger amounts of images (movies). So I would have rather expected this to show up in image manipulation programs, converters, movie editors and the likes first, rather than encoding in a browser.
    But maybe the code can be re-used in other projects...?
    Stop TCPA, stupid software patents and corrupt politicians!

    Comment


    • #3
      Originally posted by Adarion View Post
      But HW acceleration like that might be nice for programs that really deal often with larger amounts of images (movies).
      This is acceleration for encoding, and movies don't use Jpeg compression (which is for images).

      Also, from the commit description it seems it is for creating jpeg images from physical cameras, not to make screenshots.

      Comment


      • #4
        Originally posted by Adarion View Post
        I admit it sounds a bit silly to me to do just JPEG HW encoding, I mean, a single JPEG of normal resolution shouldn't be that much of a burden even for a low end CPU these days. And I'm not sure what to think of direct-in-browser-screenshots, I mean, that functionality offers a lot of abuse potential.
        But HW acceleration like that might be nice for programs that really deal often with larger amounts of images (movies). So I would have rather expected this to show up in image manipulation programs, converters, movie editors and the likes first, rather than encoding in a browser.
        But maybe the code can be re-used in other projects...?
        Direct connection of a webcam to encoding hardware sounds nice.
        Now whether this should be done at Chrome level, is another story... Is it through DMA-BUF at least?

        Comment


        • #5
          Would be more interesting if they enabled the accelerated decoders they already have on more than just ChromeOS.

          And note the V4L2 that Google is using in Chrome, really should have another name because it is not remotely compatible with open source implementation in the real linux kernel.

          Comment


          • #6
            This looks like a very odd thing.

            Comment


            • #7
              Could be useful if you're doing something like MJPEG capture.

              Comment


              • #8
                Originally posted by carewolf View Post
                Would be more interesting if they enabled the accelerated decoders they already have on more than just ChromeOS.

                And note the V4L2 that Google is using in Chrome, really should have another name because it is not remotely compatible with open source implementation in the real linux kernel.
                I'm pretty sure it's actually the same thing. Google, Red Hat, and a number of others have been moving to standardize hardware video decode and encode interfaces in the kernel through V4L2. I believe there's upstream support for AVC(and maybe HEVC) decode on recent snapdragon chipsets through V4L2 as a result of some of this work. Google's motivation in this is to have a consistent, standard kernel interface for video decode on Chromebooks (and maybe Android, though I'm not sure). Samsung has shown interest in it as well, and I think they want it for Android because they're sick of having to ship different OpenMAX blobs for different versions of a phone.

                Related: https://events.linuxfoundation.org/i...012_debski.pdf
                Last edited by microcode; 18 October 2017, 02:27 PM.

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  This is acceleration for encoding, and movies don't use Jpeg compression (which is for images).

                  Also, from the commit description it seems it is for creating jpeg images from physical cameras, not to make screenshots.
                  MJPEG has rather obvious uses, especially in HTTP Streaming. Every image is converted to a JPEG before sequenced into a set thus MJPEG streaming.

                  It's used within Blender, FCP X, Natron, any modern Nonlinear Video Editing solution.

                  JPEG encode acceleration can be used to reduce camera still capture encoding latency.
                  This improves the two-way video conferencing, to live streaming feeds uploading, etc. Reduced latency improves quality of the streaming broadcast, reduces conversion rates, etc.

                  Comment


                  • #10
                    Originally posted by microcode View Post

                    I'm pretty sure it's actually the same thing. Google, Red Hat, and a number of others have been moving to standardize hardware video decode and encode interfaces in the kernel through V4L2. I believe there's upstream support for AVC(and maybe HEVC) decode on recent snapdragon chipsets through V4L2 as a result of some of this work. Google's motivation in this is to have a consistent, standard kernel interface for video decode on Chromebooks (and maybe Android, though I'm not sure). Samsung has shown interest in it as well, and I think they want it for Android because they're sick of having to ship different OpenMAX blobs for different versions of a phone.

                    Related: https://events.linuxfoundation.org/i...012_debski.pdf
                    Well, it is not compatible. We can activate the VAAPI acceleration in Chromium, but the V4L2 code is using a lot of extensions and API not present in any Linux distro.

                    Comment

                    Working...
                    X