GNOME Bugzilla – Bug 774241
metabug: vaapi: fix failures of gst-validate-launcher TCs
Last modified: 2017-04-26 10:38:52 UTC
There are lots of failures in current TCs in gst-validate. So I'm starting to fix failures of current TCs through vaapi elements. This thread is to monitor the progress of all these things. I'll start with "playback" TCs first. $ gst-validate-launcher -t playback A lot of failures happen, but I can summarize them as 3 problems. 1. Failures of all TCs with "intensive_state_change" scenario 2. Deadlock while playing specific media : GH1_00094_1920x1280.MTS 3. Doesn't support YUY2, UYVY render in vaapisink - See bug #759533
Problem 1: Failures of all TCs with "intensive_state_change" scenario Most tcs with intensive_state_change scenario lead to failure as following. gst_vaapi_window_get_size: assertion 'window != NULL' failed, or deadlock sometimes. Callstack is following.
+ Trace 236847
This occurs because the xevent thread is not destroyed when the pipeline shuts down. Currently, when the vaapisink element is destroyed, the thread is destroyed.
Created attachment 339589 [details] [review] vaapisink: Finish event thread during change of state READY to NULL Thread to handle window event should be finished during pipeline shutdown, otherwise it would be alive during pipeline shutdown and re-activation, which could lead to unexpected problem. This patch also fixes failures of intensive_state_change scenario of gst-validate
(In reply to Hyunjun Ko from comment #1) > Problem 1: Failures of all TCs with "intensive_state_change" scenario > > Most tcs with intensive_state_change scenario lead to failure as following. > gst_vaapi_window_get_size: assertion 'window != NULL' failed, or deadlock > sometimes. > This can be reproduced by just running this testcase. # gst-validate-launcher -t validate.dash.playback.change_state_intensive.dash_exMPD_BIP_TC1 That is the first testcase in gst-validate-launcher as default! :(
(In reply to Hyunjun Ko from comment #2) > Created attachment 339589 [details] [review] [review] > vaapisink: Finish event thread during change of state READY to NULL > > Thread to handle window event should be finished during pipeline shutdown, > otherwise it would be alive during pipeline shutdown and re-activation, > which could lead to unexpected problem. > > This patch also fixes failures of intensive_state_change scenario of > gst-validate Good catch! @Hyunjun, please open a bug per issue. You can keep this bug as a meta-bug for tracking all the issues, since each one may need to be discussed individually.
\o/
I've run transcode testsuites with vaapi. (Note that I rank up vaapi encoders to run) Failures over 50 occur, I summarized them as below 1) Most of failures are this : vaapi encoder doesn't support some video raw format, This is known, See bug #769266. 2) NOT NEGOTIATED happens due to vaapi-bufferpool is dropped on videorate. See bug #775203 3) NOT NEGOTIATED happens due to misorder of buffer and caps event. See bug #775204
I've run "simple" testsuites, which includes 30 testcases. Some(2 or 3) compositor testcases failed. See bug #776303
Update: If patches in bug #775203 and #775204 are merged, all transcode testsuites is passed. But still require review.
Since all the dependencies are closed, this metabug should be closed too. Great work!