1. 04 May, 2017 1 commit
  2. 02 May, 2017 1 commit
  3. 27 Apr, 2017 4 commits
  4. 25 Apr, 2017 1 commit
  5. 24 Apr, 2017 3 commits
  6. 21 Apr, 2017 2 commits
  7. 20 Apr, 2017 3 commits
  8. 19 Apr, 2017 1 commit
  9. 17 Apr, 2017 2 commits
  10. 16 Apr, 2017 1 commit
  11. 14 Apr, 2017 1 commit
    • Sebastian Dröge's avatar
      qtmux: Fix timescale of timecode tracks · e51c08b0
      Sebastian Dröge authored
      They should have ideally the same timescale of the video track, which we
      can't guarantee here as in theory timecode configuration and video
      framerate could be different. However we should set a correct timescale
      based on the framerate given in the timecode configuration, and not just
      use the framerate numerator.
      e51c08b0
  12. 13 Apr, 2017 2 commits
  13. 12 Apr, 2017 8 commits
  14. 11 Apr, 2017 4 commits
  15. 10 Apr, 2017 3 commits
  16. 09 Apr, 2017 2 commits
  17. 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