Bug 96703 - [BSW]run2run is not bit match in h264 encoder
Summary: [BSW]run2run is not bit match in h264 encoder
Status: CLOSED FIXED
Alias: None
Product: libva
Classification: Unclassified
Component: intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: haihao
QA Contact: Sean V Kelley
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-28 03:33 UTC by Jun Zhao
Modified: 2016-07-29 21:49 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jun Zhao 2016-06-28 03:33:57 UTC
gstreamer-vaapi/libyami transcode sample have this issue too.

Used libva/intel-driver master branch.

for gstreamer-vaapi(master branch), reproduce step as follow:

a). DISPLAY=:0 gst-launch-1.0 filesrc location=~/bits/320x240.264 ! h264parse ! vaapidecode ! vaapiencode_h264 ! filesink location=a.264

b). DISPLAY=:0 gst-launch-1.0 filesrc location=~/bits/320x240.264 ! h264parse ! vaapidecode ! vaapiencode_h264 ! filesink location=b.264

c). diff a.264 b.264

for libyami(both master/apache branch) transcode sample, reproduce step as follow:

/*******yamiencode*******/
$ sudo ./yamiencode -i /home/media/skyfall2-trailer.mp4_1920x1080.I420 -W 1920 -H 1080 -o /home/media/test.264;md5sum -b /home/media/test.264
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
encode done
e70a9d6124b4461b2558d8933a005689 */home/media/test.264

$ sudo ./yamiencode -i /home/media/skyfall2-trailer.mp4_1920x1080.I420 -W 1920 -H 1080 -o /home/media/test.264;md5sum -b /home/media/test.264
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
encode done
e70a9d6124b4461b2558d8933a005689 */home/media/test.264
/*********yamitranscode***********/
$ sudo ./yamitranscode -i /home/media/skyfall2-trailer.mp4 -o 1280x720.264 ; md5sum -b 1280x720.264
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
3614 frame decoded, fps = 100.70. fps after 5 frames = 100.79.
transcode done
bf220c01ee342d08b4abe6e03d124202 *1280x720.264
$ sudo ./yamitranscode -i /home/media/skyfall2-trailer.mp4 -o 1280x720.264 ; md5sum -b 1280x720.264
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
3614 frame decoded, fps = 101.20. fps after 5 frames = 101.31.
transcode done
4b9953ee52fac83d91b166cfefb633e8 *1280x720.264
Comment 1 mingruo.sun@intel.com 2016-07-04 08:50:43 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?
Comment 2 Jun Zhao 2016-07-05 01:29:42 UTC
I can reproduce this issue in Ubuntu 14.04/SKL, Ubuntu 16.04/IVY, and this issue need to run sometimes to reproduce.
Comment 3 Jun Zhao 2016-07-05 01:30:53 UTC
(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.
Comment 4 mingruo.sun@intel.com 2016-07-13 09:48:51 UTC



(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.
Comment 5 mingruo.sun@intel.com 2016-07-21 05:16:19 UTC
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));
Comment 6 haihao 2016-07-26 00:55:39 UTC
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.
Comment 7 mingruo.sun@intel.com 2016-07-26 03:12:50 UTC
(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.
Comment 8 Sean V Kelley 2016-07-29 21:49:32 UTC
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.