| Summary: | h264 libva capture corrupted results | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | U. Artie Eoff <ullysses.a.eoff> |
| Component: | weston | Assignee: | Ander Conselvan de Oliveira <conselvan2> |
| Status: | VERIFIED FIXED | QA Contact: | Wayland bug list <wayland-bugs> |
| Severity: | critical | ||
| Priority: | medium | CC: | conselvan2 |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | screenshot of capture.h264 playback | ||
|
Description
U. Artie Eoff
2014-04-15 18:49:36 UTC
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.