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

[phoronix]

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

The latest work landing in Mesa Git has been for H.264 VA-API video encoding...

http://www.phoronix.com/scan.php?page=news_item&px=G3D-H264-VAAPI-Lands

[schmidtbag]

Interesting.... would this happen to benefit any DLNA servers?

[Adarion]

A list of userspace programs using OpenMAX or vaapi would be interesting. So one can actually be sure to use the HW ASIC and not block CPU cores for video encoding.
euses vaapi, euse -I vaapi don't really throw out all that much.

[haagch]

Galloum3D

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/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/884843-h-264-va-api-encode-comes-to-gallium3d?p=885559#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.

[Serafean]

Does this also benefit r600 class cards with VCE?

[haagch]

Ah, I found the problem.
When I run
DRI_PRIME=1 glxgears
and start encoding with vaapi it is really slow.
0.79s user 0.30s system 2% cpu 53.595 total

When I run
DRI_PRIME=1 vblank_mode=0 glxgears
and start encoding with vaapi it is a lot faster:
1.00s user 0.26s system 45% cpu 2.794 total

Edit: https://bugs.freedesktop.org/show_bug.cgi?id=97075

[gsedej]

What is vaapi over gallium better than normal vaapi?

[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]

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

[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/gstreamer-screenrecording/issues/4