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

[gsedej]

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!

[legume]

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.

[atomsymbol]

Encoding a file is also possible with e.g. this pipeline:

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.

[atomsymbol]

As I said earlier, I can record my screen on my intel + HD 7970M laptop with this gstreamer pipeline:

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:

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.

[atomsymbol]

As I said earlier, I can record my screen on my intel + HD 7970M laptop with this gstreamer pipeline:

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:

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.

[oleid]

Using OMX.

[dungeon]

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

[gsedej]

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

[Gusar]

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.

[gsedej]

What is vaapi over gallium better than normal vaapi?