Mark Thompson wrote:
On 27/09/16 00:49, Andy Furniss wrote:
Mark Thompson wrote:
---
A simple fix to the problem described here:
<https://lists.freedesktop.org/archives/mesa-dev/2016-September/128076.html>.
With this applied, the driver no longer hangs/crashes when vaSyncSurface() is
called in places other than for the first time after an encode operation
(including a second call on the same surface).
Once I could get ffmpeg (patched) or avconv to roughly work (before the dual
instance commit), but I can't get either to work now = produces unreadable file.
Testing with git avconv I am trying -
./avconv -vaapi_device :0 -f rawvideo -framerate 50 -s 2560x1440 -pix_fmt nv12
-i /mnt/ramdisk/trees-1440p50.nv12 -vframes 5 -vf 'hwupload' -c:v h264_vaapi
-profile:v 66 -b:v 40M -bf 0 -g 30 -f h264 -y /mnt/ramdisk/out.264
but debugging printfs show refs = 2 and bframes enabled (I also notice with
your baseline patch that -profile:v 66 fails).
Do you have an example that works for you with avconv + this patch?
Yes: this patch
<https://lists.libav.org/pipermail/libav-devel/2016-September/079207.html> is
also required to match the vaSyncSurface() change. The rest of the that series to
libav and the one to mesa for config setup makes it all a bit more sensible (doesn't
submit a load of packed headers which are ignored), but it does mostly work without.
Ok, thanks, so with that I am back to where I was before it stopped working.
In summary baseline works but JM ref decoder doesn't like the pocs.
b frames don't work properly, but then they don't with gst vaapi either.
They do work with gst omx.
Looking at output from printfs some differences I see vs gstreamer.
maxrefs is hardcoded to 2 which has sideffects =
enc_pic.pc.enc_b_pic_pattern = 1 vs 0 - seems harmless in practice.
There is code that for my h/w disables dual instance when maxrefs > 1
which means half speed, but there seems to be a bottleneck elsewhere
that makes avconv 3x slower than gstreamer anyway.
gop, it seems that avconv with -g doesn't set h264->intra_idr_period in
handleVAEncSequenceParameterBufferType which gets used to set
context->desc.h264enc.gop_size and enc_pic.rc.gop_size
pocs gstreamer increments h264->CurrPic.TopFieldOrderCnt in 2s avconv
1s. The code divides this by 2 in handleVAEncPictureParameterBufferType
With all of those, the commands:
./avconv -y -vaapi_device /dev/dri/renderD129 -i in.mp4 -an -vf
'format=nv12,hwupload' -c:v h264_vaapi -bf 0 out.mp4
./avconv -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi
-hwaccel_output_format vaapi -i in.mp4 -an -c:v h264_vaapi -bf 0 out.mp4
./avconv -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi
-hwaccel_output_format vaapi -i in.mp4 -an -vf 'scale_vaapi=w=1280:h=720' -c:v
h264_vaapi -bf 0 out.mp4
work sensibly for me (also with -b for CBR, -qp for CQP, -g for GOP size); I
imagine raw video as in your example would also be fine. On profile,
constrained baseline on the command line is 578 (== 66 | 0x200, for
constraint_set1_flag).
Thanks,
- Mark
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
