H.264 VA-API Encode Comes To Gallium3D

[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

[legume]

Thanks, that confirms it, to get the intel vid to match with mpv you would need

mpv --vf=format=colorlevels=full:colormatrix=bt.601 --vo=opengl rec_2016-07-19_230813.mkv

With mpv at least the omx vid will just work and looks roughly the same. The different qp shows quite a bit on the tree background and the chroma sub-sampling looks different, but the colors are close.

On the qp with omx you can change it with options quant-i-frames= and quant-p-frames= (which are the only options out of those shown by gst-inspect-1.0 omxh264enc that currently work properly)