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 
> out.mp4
> (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 
> <https://cgit.freedesktop.org/mesa/mesa/commit/?id=c59628d11b134fc016388a170880f7646e100d6f>
>  (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.


Anton Khirnov
libav-devel mailing list

Reply via email to