From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 102006] gstreamer vaapih264enc segfault Date: Mon, 14 Aug 2017 13:00:38 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1729851777==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id DA0086E17B for ; Mon, 14 Aug 2017 13:00:37 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1729851777== Content-Type: multipart/alternative; boundary="15027156370.d3Dc.17635"; charset="UTF-8" --15027156370.d3Dc.17635 Date: Mon, 14 Aug 2017 13:00:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D102006 --- Comment #2 from Julien Isorce --- Comment on attachment 133180 --> https://bugs.freedesktop.org/attachment.cgi?id=3D133180 proposed patch by Julien Isorce commit 91d93aa62162f98d6377e5c796b63faa263f2c18 Author: Julien Isorce Date: Tue Jul 25 15:31:28 2017 +0100 st/va: change frame_idx from array to hash table The picture_id was assumed to be a frame number so in 0-31. But the vaapi client gstreamer-vaapi uses the surfaces handles as identifier which are unsigned int. This bug can happen when using a lot of vaapi surfaces within the same process. Indeed Mesa/st/va increments a counter for the surface ID: mesa/util/u_handle_table.c::handle_table_add which starts from 0 and incremented by 1 at each call. So creating more than 32 surfaces was a problem. The following bug contains a test that reproduces the problem by running a couple of vaapih264enc in the same process. The above also explains why there was no pb when running them in separated processes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D102006 Signed-off-by: Julien Isorce Tested-by: Tomas Rataj Acked-by: Christian K=C3=B6nig Reviewed-and-tested-by: Boyuan Zhang --=20 You are receiving this mail because: You are the assignee for the bug.= --15027156370.d3Dc.17635 Date: Mon, 14 Aug 2017 13:00:37 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 2 on bug 10200= 6 from Julien Isorce
Comment on attac=
hment 133180 [details] [review=
]
proposed patch by Julien Isorce

commit 91d93aa62162f98d6377e5c796b63faa263f2c18
Author: Julien Isorce <ju=
lien.isorce@gmail.com>
Date:   Tue Jul 25 15:31:28 2017 +0100

    st/va: change frame_idx from array to hash table

    The picture_id was assumed to be a frame number so in 0-31.
    But the vaapi client gstreamer-vaapi uses the surfaces handles
    as identifier which are unsigned int.

    This bug can happen when using a lot of vaapi surfaces within
    the same process. Indeed Mesa/st/va increments a counter for the
    surface ID: mesa/util/u_handle_table.c::handle_table_add which
    starts from 0 and incremented by 1 at each call.
    So creating more than 32 surfaces was a problem.

    The following bug contains a test that reproduces the problem
    by running a couple of vaapih264enc in the same process. The
    above also explains why there was no pb when running them in
    separated processes.

    Bugzilla: https://bugs.freedesktop.org/show_bug.=
cgi?id=3D102006
    Signed-off-by: Julien Isorce <jisorce@oblong.com>
    Tested-by: Tomas Rataj <rat=
aj28@gmail.com>
    Acked-by: Christian K=C3=B6nig <christian.koenig@amd.com>
    Reviewed-and-tested-by: Boyuan Zhang <Boyuan.Zhang@amd.com>


You are receiving this mail because:
  • You are the assignee for the bug.
= --15027156370.d3Dc.17635-- --===============1729851777== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1729851777==--