Announcement

Collapse
No announcement yet.

H.264 VA-API Encode Lands For Gallium3D, Benefits RadeonSI

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

  • gsedej
    replied
    Originally posted by dungeon View Post

    Radeon have decoding via vaapi or via vdpau.



    OMX. With gstreamer let say... something like this:

    https://github.com/pontostroy/gstrea...rding/issues/4
    Thanks for an answer. I taught vaapi _encoding_ was already possible. It's great news indeed!

    Leave a comment:


  • legume
    replied
    ffmpeg doesn't have all the needed patches merged from libav yet. With them/testing with avconv there are still some issues that gstreamer doesn't have. It's early days.

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by haagch View Post
    Encoding a file is also possible with e.g. this pipeline:
    Code:
    DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 -e filesrc location=SampleVideo_1280x720_1mb.mp4 ! decodebin ! queue ! videoconvert ! queue ! video/x-raw,format=NV12 ! vaapih264enc rate-control=2 ! h264parse ! matroskamux ! filesink location=output.mkv
    When using this sample video http://www.sample-videos.com/video/m...y_720p_1mb.mp4 it takes 1:09 minutes, which is not very good because the video is 5 seconds long...

    The same with the slightly different pipeline that was posted here:
    https://www.phoronix.com/forums/foru...559#post885559
    and that apparently only took 1.284s total.

    I know that it's not the VCE support itself, because OMX encoding actually works fine now.

    So I guess I should report a bug now that it has landed and still is so slow.
    I tried launching ffmpeg-3.1.1 with VA-API hwaccel encoding but it failed. It is too premature to try VA-API now, I am going to wait a while and try later.

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by haagch View Post
    As I said earlier, I can record my screen on my intel + HD 7970M laptop with this gstreamer pipeline:
    Code:
    DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! queue ! videoconvert ! queue ! video/x-raw,format=NV12,framerate=30/1 ! vaapih264enc rate-control=2 ! h264parse ! matroskamux ! filesink location=output.mkv
    All seems to work fine, but the framerate ends up being something like 2-3 FPS.

    Encoding a file is also possible with e.g. this pipeline:
    Code:
    DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 -e filesrc location=SampleVideo_1280x720_1mb.mp4 ! decodebin ! queue ! videoconvert ! queue ! video/x-raw,format=NV12 ! vaapih264enc rate-control=2 ! h264parse ! matroskamux ! filesink location=output.mkv
    When using this sample video http://www.sample-videos.com/video/m...y_720p_1mb.mp4 it takes 1:09 minutes, which is not very good because the video is 5 seconds long...

    The same with the slightly different pipeline that was posted here:
    https://www.phoronix.com/forums/foru...559#post885559
    and that apparently only took 1.284s total.

    I know that it's not the VCE support itself, because OMX encoding actually works fine now.

    So I guess I should report a bug now that it has landed and still is so slow.
    I tried launching ffmpeg-3.1.1 with VA-API hwaccel encoding but it failed. It is too premature to try VA-API now, I am going to wait a while and try later.

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by haagch View Post
    As I said earlier, I can record my screen on my intel + HD 7970M laptop with this gstreamer pipeline:
    Code:
    DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! queue ! videoconvert ! queue ! video/x-raw,format=NV12,framerate=30/1 ! vaapih264enc rate-control=2 ! h264parse ! matroskamux ! filesink location=output.mkv
    All seems to work fine, but the framerate ends up being something like 2-3 FPS.

    Encoding a file is also possible with e.g. this pipeline:
    Code:
    DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 -e filesrc location=SampleVideo_1280x720_1mb.mp4 ! decodebin ! queue ! videoconvert ! queue ! video/x-raw,format=NV12 ! vaapih264enc rate-control=2 ! h264parse ! matroskamux ! filesink location=output.mkv
    When using this sample video http://www.sample-videos.com/video/m...y_720p_1mb.mp4 it takes 1:09 minutes, which is not very good because the video is 5 seconds long...

    The same with the slightly different pipeline that was posted here:
    https://www.phoronix.com/forums/foru...559#post885559
    and that apparently only took 1.284s total.

    I know that it's not the VCE support itself, because OMX encoding actually works fine now.

    So I guess I should report a bug now that it has landed and still is so slow.
    I tried to launch ffmpeg-3.1.1 with VA-API hwaccel encoding but it failed. Trying VA-API now is too premature, I am going to wait a few weeks before trying again.

    Leave a comment:


  • oleid
    replied
    Using OMX.

    Leave a comment:


  • dungeon
    replied
    Originally posted by gsedej View Post
    Oh, radeon did not yet have vaapi support?
    Radeon have decoding via vaapi or via vdpau.

    How did people sceencast using hw encoder before in radeons?
    OMX. With gstreamer let say... something like this:

    https://github.com/pontostroy/gstrea...rding/issues/4

    Leave a comment:


  • gsedej
    replied
    Oh, radeon did not yet have vaapi support? How did people sceencast using hw encoder before in radeons?

    Leave a comment:


  • Gusar
    replied
    Originally posted by gsedej View Post
    What is vaapi over gallium better than normal vaapi?
    What do you mean by "normal vaapi"?

    It's an API. You implement support for hardware decoding in your driver and expose this support via the API. For gallium drivers, it makes sense to do the implementation in gallium. For non-gallium drivers, it'll obviously be implemented elsewhere. To applications it makes no difference, they'll use the same API no matter where a particular implementation is. That's the point of APIs, to abstract away the underlying implementation.
    Last edited by Gusar; 25 July 2016, 10:23 AM.

    Leave a comment:


  • gsedej
    replied
    What is vaapi over gallium better than normal vaapi?

    Leave a comment:

Working...
X