Quoting Mark Thompson (2016-09-18 20:47:36)
> While outwardly bizarre, this change makes the behaviour consistent
> with other VAAPI encoders which sync to the encode /input/ picture in
> order to wait for /output/ from the encoder. It is not harmful on
> i965 (because synchronisation already happens in vaRenderPicture(),
> so it has no effect there), and it allows the encoder to work on
> mesa/gallium which assumes this behaviour.
It is indeed rather weird, but if that's the way it works then fine.
> Following this change, encode works on AMD VCE using current gallium/mesa in
> hardware-only transcode cases with suitable options.
> That is, things like:
> ./avconv -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi
> -hwaccel_output_format vaapi -i in.mp4 -an -c:v h264_vaapi -qp 20 -bf 0
> (On my testing card B-frames are not supported and that capability is not
> reported, so you have to set it explicitly.)
> Using a software decoder and hwupload with something like:
> ./avconv -y -vaapi_device /dev/dri/renderD129 -i in.mp4 -vf
> 'format=nv12,hwupload' -an -c:v h264_vaapi -qp 20 -bf 0 out.mp4
> doesn't currently work because the general case of vaSyncSurface() was broken
> recently by
> (segfaults). Some versions before that change do work.
> I poked the mesa-dev ML about it but haven't heard back; I'll pursue this
> further soon. More interesting cases (multiple encodes, say) might variably
> work, but I think this vaSyncSurface() problem needs to be cleared up before
> doing anything further.
> I've also made some updates to the wiki page
> <https://wiki.libav.org/Hardware/vaapi> to reflect current status.
libav-devel mailing list