[Bug 778830] v4l2dec: Fix race when going from PAUSED to READY

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778830

--- Comment #1 from Thibault Saunier <tsaunier at gnome.org> ---
Created attachment 346071
  --> https://bugzilla.gnome.org/attachment.cgi?id=346071&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)

The taken solution in that patch is to delay the setting of
`v4l2dec->process` to the time where the processing loop is
actually started.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.