The libva h264 capture feature in weston generates corrupt results. I'm not sure where the corruption occurs in the pipeline (i.e. encode or decode) or which software or hardware component causes the regression. I know I tested this a while back and it was working at that time. Unfortunately, I've been unsuccessful in revitalizing the s/w stack that used to work for me... every rollback I tried still produced the corruption. Is it possible the regression was caused by a kernel component? I did not try rolling those back. I've tested and reproduced this issue on Ivybridge and Haswell. ::Steps:: 1. Launch weston 2. Start h264 capture with: <mod>+<shift>+<space> q 3. Do stuff (i.e. launch apps, move windows, etc.) 4. Stop h264 capture with: <mod>+<shift>+<space> q 5. Playback capture.h264 $ gst-play-1.0 capture.h264 or $ gst-launch-1.0 filesrc location=capture.h264 \ ! h264decode ! vaapidecode ! vaapisink 6. Transcode capture.h264 to capture.mp4 $ gst-launch-1.0 filesrc location=capture.h264 \ ! h264decode ! mp4mux ! filesink location=capture.mp4 ::S/W Stack:: kernel: 3.13.6-200.fc20.x86_64 wayland (master) 1.4.91-0-g5e2cfd2 drm (master) libdrm-2.4.52-0-g46d451c mesa (10.1) heads/10.1-0-g0c6be6e libva (master) libva-1.2.1-0-g88ed1eb intel-driver (master) 1.2.2-0-g121e70d cairo (1.12) heads/1.12-0-g59e2a93 libinput (master) heads/master-0-g9c61146 weston (master) heads/master-0-ga5c3a3c gstreamer (1.2) heads/1.2-0-gd854327 gst-plugins-base (1.2) heads/1.2-0-g0c9dcac gst-plugins-good (1.2) heads/1.2-0-g71d318c gst-plugins-bad (1.2) heads/1.2-0-g1247c42 gst-ffmpeg (1.2) heads/1.2-0-g9946e5b gstreamer-vaapi (master) tags/0.5.8-0-gc9af9a8
Created attachment 97420 [details] screenshot of capture.h264 playback Unfortunately the capture.h264 and .mp4 files are too big to upload as attachments. But here is a screenshot of the capture.h264 playback that represents what the frames look like.
(In reply to comment #0) > 5. Playback capture.h264 > $ gst-play-1.0 capture.h264 > or > $ gst-launch-1.0 filesrc location=capture.h264 \ > ! h264decode ! vaapidecode ! vaapisink > 6. Transcode capture.h264 to capture.mp4 > $ gst-launch-1.0 filesrc location=capture.h264 \ > ! h264decode ! mp4mux ! filesink location=capture.mp4 > Correction... /h264decode/h264parse/
...ok, I found the s/w stack that worked in the past and still works now even on the newer kernel: wayland (1.3) heads/1.3-0-g84247b7 drm (master) libdrm-2.4.46-0-gc6d73cf mesa (9.2) heads/9.2-0-ga2224cf libva (master) libva-1.2.1-0-g88ed1eb intel-driver (master) 1.2.1-0-g8f306e3 cairo (master) 1.12.16-0-g8e11a42 weston (1.3) 1.3.1-0-g5e3ff49 gstreamer (master) 1.0.9-0-gf3c4f74 gst-plugins-base (master) 1.0.9-0-gffc5262 gst-plugins-good (master) 1.0.9-0-gff2598f gst-plugins-bad (master) 1.0.9-0-g7ba6694 gst-ffmpeg (master) 1.0.9-0-gd1c488b gstreamer-vaapi (master) tags/0.5.3-0-gaf9202b
Further bisecting reveals: With all other S/W components static, this issue arises when moving from "intel-driver (master) 1.2.1-0-g8f306e3" to "intel-driver (master) 1.2.2-0-g121e70d"
First bad commit is: commit fdde376c8c59a076f09e08cf5dbc62fd5f031f6d Author: Xiang, Haihao <haihao.xiang@intel.com> Date: Wed Nov 13 13:19:16 2013 +0800 Correct the usage of width/height in struct object_surface Add comments for width/height, orig_width/orig_height as well Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com> (cherry picked from commit f886f24eaaacba9544fa5f6405b7382c686f3a1f)
weston set the wrong value to va_attrib_extbuf.pitches[0] and va_attrib_extbuf.data_size. Note the picth is in unit of bytes, not pixels. If weston can pass right parameters to libva, the captured result is right too. I tested it with both libva-1.2.1/libva-intel-drvier-1.2.2 and libva-1.3.0/libva-intel-driver-1.3.0.
Note the bug is hidden when using intel-driver 1.2.1 because intel-driver 1.2.1 ignores the stride from user and set the surface state in a wrong way.
Thanks for pointing that out Haihao. I send a fix for Weston to Wayland mailing list.
commit a61b949eb8f350d4021b303f2a7c4383b2aed6da Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Wed Apr 16 12:05:12 2014 +0300 compositor-drm: Pass the right stride to the vaapi recorder It takes the stride in bytes, not pixels. The bug was hidden when using va intel-driver 1.2.1 because it would ignore the stride from user and set the surface state in a wrong way. https://bugs.freedesktop.org/show_bug.cgi?id=77495
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.