| Summary: | [BSW]run2run is not bit match in h264 encoder | ||
|---|---|---|---|
| Product: | libva | Reporter: | Jun Zhao <mypopydev> |
| Component: | intel | Assignee: | haihao <haihao.xiang> |
| Status: | CLOSED FIXED | QA Contact: | Sean V Kelley <seanvk> |
| Severity: | critical | ||
| Priority: | medium | CC: | mingruo.sun, shengquan.yuan |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Jun Zhao
2016-06-28 03:33:57 UTC
I reproduce this issue on Yocto also. The first frame has difference start the 6th MB. I Use the libva/intel-driver master branch. And HW platform is skylake. My command line is: gst-launch-1.0 filesrc num-buffers=1 location=./123_217frame_1920x1080_blue_sky.yuv ! videoparse width=1920 format=nv12 framerate=30 height=1080 ! vaapih264enc ! video/x-h264, profile=main ! filesink location=./tmp/newdri/$i.264 -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/0.264 -rw-r--r-- 1 root root 141282 Jul 4 08:42 tmp/newdri/1.264 -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/2.264 -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/3.264 -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/4.264 -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/5.264 -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/6.264 -rw-r--r-- 1 root root 141282 Jul 4 08:42 tmp/newdri/7.264 -rw-r--r-- 1 root root 140798 Jul 4 08:42 tmp/newdri/8.264 -rw-r--r-- 1 root root 141282 Jul 4 08:42 tmp/newdri/9.264 And, I did not see such issue on Ubuntu machine with OTC driver. Is the coded buffer management different btw ubuntu and yocto? Does coded buffer need to flush before write? I can reproduce this issue in Ubuntu 14.04/SKL, Ubuntu 16.04/IVY, and this issue need to run sometimes to reproduce. (In reply to Jun Zhao from comment #2) > I can reproduce this issue in Ubuntu 14.04/SKL, Ubuntu 16.04/IVY, and this > issue need to run sometimes to reproduce. And I used OTC driver with master branch. (In reply to mingruo.sun@intel.com from comment #1) > I reproduce this issue on Yocto also. The first frame has difference start > the 6th MB. > I Use the libva/intel-driver master branch. And HW platform is skylake. > > My command line is: > gst-launch-1.0 filesrc num-buffers=1 > location=./123_217frame_1920x1080_blue_sky.yuv ! videoparse width=1920 > format=nv12 framerate=30 height=1080 ! vaapih264enc ! video/x-h264, > profile=main ! filesink location=./tmp/newdri/$i.264 > > -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/0.264 > -rw-r--r-- 1 root root 141282 Jul 4 08:42 tmp/newdri/1.264 > -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/2.264 > -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/3.264 > -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/4.264 > -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/5.264 > -rw-r--r-- 1 root root 141434 Jul 4 08:42 tmp/newdri/6.264 > -rw-r--r-- 1 root root 141282 Jul 4 08:42 tmp/newdri/7.264 > -rw-r--r-- 1 root root 140798 Jul 4 08:42 tmp/newdri/8.264 > -rw-r--r-- 1 root root 141282 Jul 4 08:42 tmp/newdri/9.264 > > And, I did not see such issue on Ubuntu machine with OTC driver. Is the > coded buffer management different btw ubuntu and yocto? Does coded buffer > need to flush before write? Just to confirm, I did not reproduce on Ubuntu/Sand Bridge with Gstramer-1.8 and OTC driver. We found the root cause is VME output differences, which is caused by a uninitialized vme constant buffer.
The patch could fix this issue on APL Yocto & SKL Ubuntu. Gen8_vme.c has the same problem.
diff --git a/src/gen9_vme.c b/src/gen9_vme.c
index 5f9b796..94ecd2f 100644
--- a/src/gen9_vme.c
+++ b/src/gen9_vme.c
@@ -1847,7 +1847,7 @@ Bool gen9_vme_context_init(VADriverContextP ctx, struct intel_encoder_context *e
encoder_context->vme_context = vme_context;
encoder_context->vme_context_destroy = gen9_vme_context_destroy;
- vme_context->vme_state_message = malloc(VME_MSG_LENGTH * sizeof(int));
+ vme_context->vme_state_message = calloc(VME_MSG_LENGTH, sizeof(int));
I worked out a new patch based on your finding, could you try the following patch https://lists.freedesktop.org/archives/libva/2016-July/004217.html and Guanxin's patch (https://lists.freedesktop.org/archives/libva/2016-July/004216.html) is also needed for yamiencode case. (In reply to haihao from comment #6) > I worked out a new patch based on your finding, could you try the following > patch > https://lists.freedesktop.org/archives/libva/2016-July/004217.html > > and Guanxin's patch > (https://lists.freedesktop.org/archives/libva/2016-July/004216.html) is > also needed for yamiencode case. Hi Haihao, Did not see the issue on APL/Yocto with your patches. Reviewed, tested. Thanks applied. Sean |
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.