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
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.