GNOME Bugzilla – Bug 785616
md5 output files, using dmabuf, are always different
Last modified: 2018-11-03 15:50:47 UTC
Each time md5 get from Ubuntu UI mode is different. For example, I run the same h264 decode pipeline several times and get the different md5: # gst-launch-1.0 -q filesrc location=/media//yami_h264_Base_Ext_Main_profile/CABACI3_Sony_B.jsv '!' h264parse '!' vaapih264dec '!' vaapipostproc format=i420 '!' checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE 155495809127a6dd2c99c96b2ca8eae7 # gst-launch-1.0 -q filesrc location=/media//yami_h264_Base_Ext_Main_profile/CABACI3_Sony_B.jsv '!' h264parse '!' vaapih264dec '!' vaapipostproc format=i420 '!' checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE 979beb55e43eee727e046414028d5f9d #gst-launch-1.0 -q filesrc location=/media//yami_h264_Base_Ext_Main_profile/CABACI3_Sony_B.jsv '!' h264parse '!' vaapih264dec '!' vaapipostproc format=i420 '!' checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE c586c2ccdd8bb1e202983ba56f734241
A bug in Ubuntu's glib?? I'm running this command in Debian testing, with (libglib2.0-0:amd64 2.52.3-1 amd64 GLib library of C routines) for i in `seq 0 10`; do gst-launch-1.0 -q filesrc location=~/patterns/bug785616.jsv ! h264parse ! vaapih264dec ! vaapipostproc format=i420 ! checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE; done 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 095fc22b46f0822be4699dcc47d912c1 Which Ubuntu is? what glib version are you linking with? Can you try with another distribution and compare with the md5 I get?
I used Ubuntu 16.04 LTS, and glib version is 2.48.2-0ubuntu1. And I found when set vaapipostproc output format as nv12, the md5 always same. root@gst-skl:~/build# gst-launch-1.0 -q filesrc location=/media//yami_h264_Base_Ext_Main_profile/CABACI3_Sony_B.jsv '!' h264parse '!' vaapih264dec '!' vaapipostproc format=nv12 '!' checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE ec42e4b5ebde82b071e5dcea23763449
(In reply to Fei from comment #2) > I used Ubuntu 16.04 LTS, and glib version is 2.48.2-0ubuntu1. > And I found when set vaapipostproc output format as nv12, the md5 always > same. > root@gst-skl:~/build# gst-launch-1.0 -q filesrc > location=/media//yami_h264_Base_Ext_Main_profile/CABACI3_Sony_B.jsv '!' > h264parse '!' vaapih264dec '!' vaapipostproc format=nv12 '!' checksumsink2 > frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE > ec42e4b5ebde82b071e5dcea23763449 Strange, I got for i in `seq 0 10`; do gst-launch-1.0 -q filesrc location=~/patterns/bug785616.jsv ! h264parse ! vaapih264dec ! vaapipostproc format=nv12 ! checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE; done eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 eea6e740430ec3e9508e79ec3a054747 I'm in a SKL box too. Linux miau 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux libva commit id b65a3d9 intel-vaapi-driver commit id 51b5d37a gstreamer-vaapi commit id 7d6a80e1
Might also be related to the hardware decoder?
I run the same cmd on SKL ubuntu 14.04(same commit id with my test on ubuntu 16.04), md5 look correct.
@Victor, did you configure gst-vaapi with enable egl? I disabled egl with "--disable-egl" option, then md5 correct on Ubuntu 16.04.
(In reply to Fei from comment #6) > @Victor, did you configure gst-vaapi with enable egl? I disabled egl with > "--disable-egl" option, then md5 correct on Ubuntu 16.04. I do. But I'm not using it. Are you working under Wayland?
I just tested in wayland and got the same MD5 (095fc22b46f0822be4699dcc47d912c1)
(In reply to Víctor Manuel Jáquez Leal from comment #7) > (In reply to Fei from comment #6) > > @Victor, did you configure gst-vaapi with enable egl? I disabled egl with > > "--disable-egl" option, then md5 correct on Ubuntu 16.04. > > I do. But I'm not using it. Are you working under Wayland? No, I working under X mode.
fixed with "apt-get install mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev" and rebuild gst-plugin-bad.
I'm reopening the issue. Finally I could reproduce it. It happens when vaapipostproc uses GstVaapiDmaBufAllocator in its source pad buffer pool. Perhaps it is a bug in chekcsumsink2, or in the kernel, producing dmabuf-base buffers slightly different than those mapped from VA surface.
I had created a side-by-side diff of the frames checksum, (dmabuf map vs va surface map) and there are some odd differences (attached) Also, the output between runs using dmabuf randomly change.
Created attachment 356842 [details] dmabuf vs va surface
Created attachment 356843 [details] dmabuf vs dmabuf two different executions with dmabuf
this regression is because, vaapi plugins use dmabuf as much as possible, but now some new problems, like this, are appearing.
Do we end up de-tiling and re-tiling later when vaapi needs to look into the ref frames ? Does the don't optimization has been merged ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/62.