H.264 VA-API Encode Comes To Gallium3D

[legume]

Neither omx or vaapi currently do high - so try omitting the
! "video/x-h264,profile=high" ! It messes up my test with that command - though not in the same way as your vid = looked OK but very jerky + player moaning about invalid timestamps.

Edit: forgot to say "20-25% CPU usage" is meaningless! Unless you know what freq it's running (assuming you use cpufreq)

[legume]

So it seems that both gstreamer screencap and bgr0 > nv12 conversion are faster that ffmpeg. So I can just cap at 1080p60 with omx. 68 fps seems to be my limit testing just cap /conversion like -

time gst-launch-1.0 ximagesrc display-name=:0 num-buffers=600 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! queue ! videoconvert ! queue ! video/x-raw,format=NV12,framerate=60/1 ! fakesink

and increasing framerate + num-buffers=10*framerate and noting when time taken starts being > 10 seconds.

To be fair to ffmpeg I don't know what either do in the conversion eg subsampling the chroma involves changing pixel positions and it could be the filter used is more complicated.
Also I don't know what matrix gstreamer uses by default (should really check it's Rec.709 full -> limited as that's what players would tend to assume for the reverse for 1080p).

By default omx will make fixed qp=28 though with the latest patches you can specify bitrates and it sort of works, though high fps can confuse things a bit.

I don't know the capabilities of all VCE versions - I have a fast card = R9 285 Tonga. Though I can now do 1080p - I would still be constrained bu CPU capping if santa brought me a 2560x1440 oled monitor :-)

FWIW benching from ramdisk 500 frames 2560x1440 raw nv12 with omx I get > 100fps conversion rate, so the GPU can do 1440p60 easily enough. (there's a bug which currently prevents testing 2160p).

Here's the result of a test record to stress GL a bit + UVD as well as VCE with content that's not simple to encode, showing qp=28 may make big files as needed.

The vid playing is roughly as high as h264 legally goes 2160p60 300mbit level 5.2 - I could never play that on CPU. vmp is just a bash alias for mpv which is doing an expensive hq scale down. (though ignore the colour quality as I messed up when making the master and was too lazy to do it all again).

GPU + CPU set to perf everything cached in/going to ram.

https://drive.google.com/file/d/0BxP5-S1t9VEETV80N0NtN0V0QVk/view?usp=sharing

[haagch]

Oh, I don't know where that came from. I copied stuff from the pipelines I used in earlier tries with omx and that must have snuck in there.

Anyway, I tried
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 ! omxh264enc ! h264parse ! matroskamux ! filesink location=output.mkv
and it looks much better:

https://youtu.be/Js4tviEMIQA

It's a mobile Ivy Bridge i7 3632QM and its max clock speed is 3.2GHz with turbo boost. It wasn't meant as a very accurate measurement anyway, just that CPUs maybe 1/3 as powerful as mine should be able to handle it.

If I just ignore the errors caused by my .omxregistry it works fine now.
Thanks.

Edit: The gstreamer-screenrecording is working fine too. And that definitely did not work when I last tried it.
Edit: The colors look quote different from the intel vaapi recordings: https://www.youtube.com/watch?v=UA5PRrIrpVM. The green lines in the overlays noticeably brighter and the red is a lot more pale. But then it's fed with I420 to the intel encoder with vaapipostproc format=i420
and converted to NV12 on the CPU for omx.

[legume]

Strong green and red are the most noticeable difference between 601 and 709 mix ups. There's also the chance of some full range vs limited range difference.

Not related to above as such, but do you have a sample made by intel h/w encode (that hasn't been recoded by youtube)? I am just curious what it looks like from an h264 point of view.

[haagch]

vaapi: http://haagch.frickel.club/files/rec...-19_230813.mkv

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=30/1 ! vaapipostproc format=i420 ! video/x-raw,format=I420,framerate=30/1 ! multiqueue ! vaapih264enc dct8x8=true ! h264parse ! multiqueue ! matroskamux name=muxer muxer. ! progressreport name=Rec_time ! filesink location=/home/chris/daten/rec_2016-07-19_230813.mkv

omx: http://haagch.frickel.club/files/rec...-19_230855.mkv

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=30/1 ! videoconvert ! video/x-raw,format=NV12,framerate=30/1 ! multiqueue ! omxh264enc ! h264parse ! multiqueue ! matroskamux name=muxer muxer. ! progressreport name=Rec_time ! filesink location=/home/chris/daten/rec_2016-07-19_230855.mkv

Enjoy.

[legume]

Thanks, so h264 is quite similar to omx, no b frames or cabac fixed qp, 26 for intel, 28 omx.

On the colors, looking at the yuv the intel is full range and by default players/vo will assume limited.

Correcting for that the colors are still different - so there some csc difference. The best way I could tell what's going on there is if you could set up the same "scene" and upload a screen shot made with -

xwd -root -out screenshot.xwd

TIA

[haagch]

I don't actually care that much. As far as I am concerned the GPU encoders aren't even trying to get a "faithful" encoding, just a very quick one. But if it's something in the setup, improvements are always nice.

Anyway, towards the end of both clips, both have a couple of seconds of the same view on the browser window. Yes, the mouse pointer and terminal window in the background may cause differences, but in general you can see the differences especially in the green colors and in the overall brightness of some colors, if you e.g. open them in two paused player windows, put them in fullscreen and switch between them.

[legume]

Yea, I can clearly see the difference from pausing/overlaying in the first second, there are I guess other ways I can infer what matrix each is using, but by far the easiest would be if you could take a screenshot with xwd with the browser showing the content as it does at the start of the vids as I would then have the rgb values that were the starting point of the encode.

Correcting for intel using full range yuv brings the images close in some ways = the ramps and the border colors of the browser.

What you see may also vary depending on player and just to muddle things further, may also vary with the same player using different -vo methods.

mplayer tends not to use 709 unless you tell it with vdpau/gl but using pre glamor xv as vo would have got 709 as xv its self decided based on based on size (I am not sure if glamor xv does this).

In the absence of metadata mpv will choose based on size between 601 and 709.

[legume]

I don't actually care that much. As far as I am concerned the GPU encoders aren't even trying to get a "faithful" encoding, just a very quick one. But if it's something in the setup, improvements are always nice.

On this point I guess that using vaapipostproc format=i420 is causing the issue - nice if it's h/w accelerated, but not nice because it seems to be using full range yuv and a 601 (SD) matrix.

Maybe you would get a full -> limited 709 conversion by letting videoconvert do it -

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue ! videoconvert ! video/x-raw,format=I420,framerate=30/1 ! multiqueue ! vaapih264enc dct8x8=true ! ....

[haagch]

Oh that's what you mean. The google results are already in a different order, but the first two are the same position.-

http://haagch.frickel.club/files/screenshot.xwd