After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774241 - metabug: vaapi: fix failures of gst-validate-launcher TCs
metabug: vaapi: fix failures of gst-validate-launcher TCs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 759533 769266 774254 775203 775204 776303
Blocks:
 
 
Reported: 2016-11-11 02:26 UTC by Hyunjun Ko
Modified: 2017-04-26 10:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vaapisink: Finish event thread during change of state READY to NULL (1.39 KB, patch)
2016-11-11 02:50 UTC, Hyunjun Ko
committed Details | Review

Description Hyunjun Ko 2016-11-11 02:26:24 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
Comment 1 Hyunjun Ko 2016-11-11 02:36:40 UTC
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.

  • #0 g_logv
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #1 g_log
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #2 gst_vaapisink_reconfigure_window
    at gstvaapisink.c line 899
  • #3 gst_vaapisink_x11_handle_events
    at gstvaapisink.c line 429
  • #4 gst_vaapisink_event_thread
    at gstvaapisink.c line 918
  • #5 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #6 start_thread
    at pthread_create.c line 333
  • #7 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109

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.
Comment 2 Hyunjun Ko 2016-11-11 02:50:16 UTC
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
Comment 3 Hyunjun Ko 2016-11-11 02:53:14 UTC
(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! :(
Comment 4 Víctor Manuel Jáquez Leal 2016-11-11 09:16:21 UTC
(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.
Comment 5 Tim-Philipp Müller 2016-11-11 09:20:52 UTC
\o/
Comment 6 Hyunjun Ko 2016-11-28 06:52:59 UTC
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
Comment 7 Hyunjun Ko 2016-12-20 06:47:04 UTC
I've run "simple" testsuites, which includes 30 testcases.

Some(2 or 3) compositor testcases failed.
See bug #776303
Comment 8 Hyunjun Ko 2017-01-04 07:13:52 UTC
Update:
If patches in bug #775203 and #775204 are merged, all transcode testsuites is passed.

But still require review.
Comment 9 Víctor Manuel Jáquez Leal 2017-04-26 10:38:52 UTC
Since all the dependencies are closed, this metabug should be closed too. Great work!