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