GNOME Bugzilla – Bug 797308
vaapiencoder: Surface concurrency issues, failed to encode frame due to 'surface in use'
Last modified: 2018-11-03 15:56:05 UTC
Created attachment 373971 [details] [review] Add lock to gstvaapisurface patch It seems that gstreamer-vaapi currently does not synchronise access to the vaapi surfaces correctly. Attempting to use a VASurface while it is mapped (with vaMapBuffer) results in a surface is in use error from vaapi. This was causing an issue for us where one branch of the pipeline would map a GstBuffer and another branch of the pipeline would attempt to encode the buffer with the vaapiencoder while it is mapped. The result is that gstvaapiencoder fails to encode the buffer, and the whole pipeline is stopped. I've attached the patch we have used to fix the issue. This adds a mutex to gstvaapisurface that is used to correctly synchronise access. We're using a slightly older version of gstreamer but it doesn't seem like this has changed in the latest master.
Hi, Thanks for the patch. Do you have any pipeline/program that shows the problem?
Hi, Sorry for the delayed response. The problem is that we have quite a complex pipeline with many custom elements. I've tried to find a pipeline with standard gstreamer elements that demonstrates this but most of my attempts have just resulted in a deadlock... In theory you should see the problem if a GstBuffer is mapped in one thread while another tries to encode it. I tried to write a small program to prove this but again I only saw deadlocks. I'll get back to you if I find a reliable way to reproduce the issue.
-- 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/109.