[Bug 778830] v4l2dec: Fix race when going from PAUSED to READY
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Feb 21 19:47:26 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=778830
Thibault Saunier <tsaunier at gnome.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #346071|needs-work |none
status| |
Attachment #346071|0 |1
is obsolete| |
--- Comment #4 from Thibault Saunier <tsaunier at gnome.org> ---
Created attachment 346389
--> https://bugzilla.gnome.org/attachment.cgi?id=346389&action=edit
v4l2dec: Fix race when going from PAUSED to READY
Running `gst-validate-launcher -t
validate.file.playback.change_state_intensive.vorbis_vp8_1_webm`
on odroid XU4 (s5p-mfc v4l2 driver) often leads to:
ERROR:../subprojects/gst-plugins-good/sys/v4l2/gstv4l2videodec.c:215:gst_v4l2_video_dec_stop:
assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
This happens when the following race happens:
- T0: Main thread
- T1: Upstream streaming thread
- T2. v4l2dec processing thread)
[The decoder is in PAUSED state]
T0. The validate scenario runs `Executing (36/40) set-state: state=null
repeat=40`
T1- The decoder handles a frame
T2- A decoded frame is push downstream
T2- Downstream returns FLUSHING as it is already flushing changing state
T2- The decoder stops its processing thread and sets `->processing = FALSE`
T1- The decoder handles another frame
T1- `->process` is FALSE so the decoder restarts its streaming thread
T0- In v4l2dec-> stop the processing thread is stopped
NOTE: At this point the processing thread loop never started.
T0- assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
Here I am removing the whole ->processing logic to base it all on the
GstTask state to avoid duplicating the knowledge.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list