Announcement

Collapse
No announcement yet.

GStreamer VA-API Plug-In Update Adds New Features

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

  • GStreamer VA-API Plug-In Update Adds New Features

    Phoronix: GStreamer VA-API Plug-In Update Adds New Features

    Gwenole Beauchesne has released an updated version of the GStreamer VA-API that provides major changes to this plug-in set that allows for hardware-accelerated video decoding with the Video Acceleration API when using GStreamer...

    http://www.phoronix.com/vr.php?view=MTc1MjA

  • #2
    Originally posted by phoronix View Post
    Phoronix: GStreamer VA-API Plug-In Update Adds New Features

    Gwenole Beauchesne has released an updated version of the GStreamer VA-API that provides major changes to this plug-in set that allows for hardware-accelerated video decoding with the Video Acceleration API when using GStreamer...

    http://www.phoronix.com/vr.php?view=MTc1MjA
    It doesn't work flawlessly but seems better than last time i tested it. Firefox CPU usage seems kind of high with HD videos. At least it doesn't crash it.

    Comment


    • #3
      Kind of off-topic, but can anybody give me a concise summary of the differences between VA-API and VDPAU? They both seem to be hardware-acceleration APIs, and most FOSS drivers end up supporting them both, so why do they both exist? Is it a ffmpeg/libav type of thing (basically the same with 90% of the differences being extremely minor)?

      Comment


      • #4
        Originally posted by 89c51 View Post
        It doesn't work flawlessly but seems better than last time i tested it. Firefox CPU usage seems kind of high with HD videos. At least it doesn't crash it.
        Unfotunately i still experience crashes with hd videos on youtube using proprietary nvidia blob (and libva-vdpau-driver)

        Comment


        • #5
          Originally posted by Daktyl198 View Post
          Kind of off-topic, but can anybody give me a concise summary of the differences between VA-API and VDPAU? They both seem to be hardware-acceleration APIs, and most FOSS drivers end up supporting them both, so why do they both exist? Is it a ffmpeg/libav type of thing (basically the same with 90% of the differences being extremely minor)?
          There are actually four and all are pretty similar:

          VDPAU - Decode only. Designed by nvidia. Currently supported by radeon, nouveau, nvidia drivers.
          VA-API - Encode and Decode. Designed by Intel. Currently supported by intel driver.
          OpenMAX - Encode and Decode. Multi-platform Khronos standard. Currently supported by radeon driver.
          XvBA - Decode only. Designed by AMD. Currently supported by catalyst driver.

          The main difference is who designed them. They tend to be somewhat tailored to the designer's hardware.

          Comment


          • #6
            Originally posted by kokoko3k View Post
            Unfotunately i still experience crashes with hd videos on youtube using proprietary nvidia blob (and libva-vdpau-driver)
            For me it doesn't crash. Quality isn't good. At least not consistent. I see some artifacts and its blur some times.

            Bad:


            Good:


            + a flickr on the screen each time i start a video.

            Need to test more though. gst-play-1.0 is broken also.

            Comment


            • #7
              Originally posted by kokoko3k View Post
              Unfotunately i still experience crashes with hd videos on youtube using proprietary nvidia blob (and libva-vdpau-driver)
              Why use such roundabout way? Can't gstreamer use vdpau directly? There's a libgstvdpau.so in gst-plugins-bad.

              Comment


              • #8
                Originally posted by agd5f View Post
                There are actually four and all are pretty similar:

                VDPAU - Decode only. Designed by nvidia. Currently supported by radeon, nouveau, nvidia drivers.
                VA-API - Encode and Decode. Designed by Intel. Currently supported by intel driver.
                OpenMAX - Encode and Decode. Multi-platform Khronos standard. Currently supported by radeon driver.
                XvBA - Decode only. Designed by AMD. Currently supported by catalyst driver.

                The main difference is who designed them. They tend to be somewhat tailored to the designer's hardware.
                gst-vaapi vs gst-omx?? radeon r600 works semi-OK with gst-vaapi.

                Comment


                • #9
                  Originally posted by 89c51 View Post
                  It doesn't work flawlessly but seems better than last time i tested it. Firefox CPU usage seems kind of high with HD videos. At least it doesn't crash it.
                  An indication of CPU usage without the current CPU frequency is kind of useless you know. It could be 54% of CPU @ 774 Mhz vs. 114% of CPU @ 1.8 Ghz, that's not quite the same.

                  Comment


                  • #10
                    In case anyone that can do something reads here.

                    The quality issue is that when changing to the big player it doesn't use the 720p resolution but a smaller one. And when using the small player the quality is shit. Might has to do with scaling of the video or something. Not sure if this is a gst-vaapi issue or a youtube one.

                    Comment


                    • #11
                      Originally posted by 89c51 View Post
                      For me it doesn't crash. Quality isn't good. At least not consistent. I see some artifacts and its blur some times.

                      Bad:


                      Good:


                      + a flickr on the screen each time i start a video.

                      Need to test more though. gst-play-1.0 is broken also.
                      Bad vs. good refers to what?

                      Note: current Firefox implementation (from 31.0 sources) doesn't care of tracking GstVideoAlignment changes. A better approach would be to use GstVideoMeta and GstVideoCropMeta. Anyway, real performance improvements could only be obtained through Firefox changes. At least, there is no reason gst-vaapi should crash or hang, which was fixed.

                      Comment


                      • #12
                        Originally posted by 89c51 View Post
                        In case anyone that can do something reads here.

                        The quality issue is that when changing to the big player it doesn't use the 720p resolution but a smaller one. And when using the small player the quality is shit. Might has to do with scaling of the video or something. Not sure if this is a gst-vaapi issue or a youtube one.
                        AFAICS, 360p is used by default. 720p is the maximum without MSE support in Firefox at this time.

                        Comment


                        • #13
                          Originally posted by gbeauche View Post
                          An indication of CPU usage without the current CPU frequency is kind of useless you know. It could be 54% of CPU @ 774 Mhz vs. 114% of CPU @ 1.8 Ghz, that's not quite the same.
                          while playing BBB in 720p in youtube


                          while playing a simpsons 1080p trailer with gst-play-1.0 (which sometimes works sometimes it doesn't)



                          Thanks for your work.

                          Comment


                          • #14
                            Originally posted by gbeauche View Post
                            Bad vs. good refers to what?
                            Refers to quality. I think its obvious in the pics.

                            Comment


                            • #15
                              Originally posted by 89c51 View Post
                              while playing BBB in 720p in youtube


                              while playing a simpsons 1080p trailer with gst-play-1.0 (which sometimes works sometimes it doesn't)



                              Thanks for your work.
                              Firefox will not use hardware accelerated rendering and requires the decoded frames to be transferred to their own buffers. i.e. reading every single frame from GPU memory is necessary. If you want to compare Firefox behaviour's to the "optimal" one, you could probably use gst-launch-1.0 uri=file:///path/to/Video.mp4 video-sink="ximagesink" (similar to firefox behaviour), vs. gst-launch-1.0 uri=file:///path/to/Video/mp4 video-sink="vaapisink" (the default).

                              Yes, we have NV12 -> I420 (HW accelerated through GPU memory) -> read back to I420 buffer -> I420 to RGB32 conversion through SSE2 code it seems. Not the fastest pipeline, but patches are welcome for Firefox.

                              Comment

                              Working...
                              X