1. 05 Jun, 2017 1 commit
  2. 26 May, 2017 1 commit
  3. 24 May, 2017 6 commits
  4. 20 May, 2017 2 commits
  5. 17 May, 2017 1 commit
  6. 16 May, 2017 1 commit
  7. 08 May, 2017 3 commits
  8. 10 Apr, 2017 1 commit
  9. 07 Apr, 2017 1 commit
    • Thibault Saunier's avatar
      v4l2dec: Fix race when going from PAUSED to READY · 7b7a8098
      Thibault Saunier authored
      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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=778830
      7b7a8098
  10. 05 Apr, 2017 4 commits
  11. 24 Mar, 2017 1 commit
  12. 18 Mar, 2017 1 commit
  13. 14 Mar, 2017 2 commits
  14. 09 Mar, 2017 1 commit
  15. 27 Feb, 2017 1 commit
  16. 22 Feb, 2017 1 commit
  17. 21 Feb, 2017 1 commit
  18. 10 Feb, 2017 1 commit
  19. 24 Jan, 2017 1 commit
    • Jean-Christophe Trotin's avatar
      v4l2allocator: reference memory before the buffer is queued · 7f763f27
      Jean-Christophe Trotin authored
      In gst_v4l2_allocator_qbuf(), the memory is referenced after the
      buffer is queued. Once queued (VIDIOC_QBUF), the buffer might be handled
      by the V4L2 driver (e.g. decoded) and dequeued (gst_v4l2_allocator_dqbuf),
      through a different thread, before the memory is referenced (gst_memory_ref).
      In this case, in gst_v4l2_allocator_dqbuf(), the memory is unreferenced
      (gst_memory_unref) before having been referenced: the memory refcount
      reaches 0, and the memory is freed.
      So, to avoid this crossing case, in gst_v4l2_allocator_qbuf(), the
      memory shall be referenced before the buffer is queued.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=777399
      7f763f27
  20. 16 Jan, 2017 3 commits
  21. 09 Jan, 2017 1 commit
  22. 14 Dec, 2016 1 commit
    • Víctor Manuel Jáquez Leal's avatar
      v4l2object: Don't check size in a non-list value · 6ec3cc70
      Víctor Manuel Jáquez Leal authored
      After commit 1ea9735a I see these error while using the webcam
      integrated in my laptop:
      
      GStreamer-CRITICAL **: gst_value_list_get_size: assertion 'GST_VALUE_HOLDS_LIST (value)' failed
      
      The issue is gst_v4l2src_value_simplify() was doing its job of
      generating a single value, rather than the original list. That why,
      when getting the list size, a critical warning was raised.
      
      This patch takes advantage of the compiler optimizations to verify
      first if the list was simplified, thus use it directly, otherwise,
      if it is a list, verify its size.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776106
      6ec3cc70
  23. 08 Dec, 2016 1 commit
  24. 24 Nov, 2016 3 commits