1. 27 Apr, 2017 4 commits
  2. 25 Apr, 2017 1 commit
  3. 24 Apr, 2017 3 commits
  4. 21 Apr, 2017 2 commits
  5. 20 Apr, 2017 3 commits
  6. 19 Apr, 2017 1 commit
  7. 17 Apr, 2017 2 commits
  8. 16 Apr, 2017 1 commit
  9. 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
  10. 13 Apr, 2017 2 commits
  11. 12 Apr, 2017 8 commits
  12. 11 Apr, 2017 4 commits
  13. 10 Apr, 2017 3 commits
  14. 09 Apr, 2017 2 commits
  15. 07 Apr, 2017 3 commits
    • 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
    • Sebastian Dröge's avatar
      Release 1.11.90 · e4da670a
      Sebastian Dröge authored
      e4da670a
    • Sebastian Dröge's avatar
      Update .po files · b6c0d403
      Sebastian Dröge authored
      b6c0d403