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. nice -- Anton Khirnov _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
