Skip to content
Snippets Groups Projects
  1. Sep 19, 2014
  2. Sep 18, 2014
  3. Sep 17, 2014
  4. Sep 16, 2014
  5. Sep 15, 2014
  6. Sep 13, 2014
    • Garg's avatar
      audiobasesink: Fix deadlock caused by holding object lock while calling clock functions · 1c9b57ed
      Garg authored and Sebastian Dröge's avatar Sebastian Dröge committed
      Issue:
      During a PAUSED->PLAYING transition when we are rendering an audio buffer in AudioBaseSink
      we make adjustments to the sink's provided clock i.e. fix clock calibration using the external
      pipeline clock, within "gst_audio_base_sink_sync_latency function inside gstaudiobasesink.c".
      For the calibration adjustment we need to get the sink clock time using "gst_audio_clock_get_time".
      But before calling "gst_audio_clock_get_time" we acquire the Object Lock on the Sink. If sink is
      a pulsesink, "gst_audio_clock_get_time" internally calls "gst_pulsesink_get_time" which needs to
      acquire Pulse Audio Main Loop Lock before querying Pulse Audio for its stream time using
      "pa_stream_get_time". Please see "gst_pulsesink_get_time in pulsesink.c".
      
      So the situation here is we have acquired the Object lock on Sink and need PA Main Loop Lock.
      Now Pulse Audio Main Thread itself might be in the process of posting a stream status
      message after Paused to Playing transition which in turn acquires the PA Main loop lock and
      needs the Object Lock on Pulse Sink. This causes a deadlock with the earlier render thread.
      
      Fix:
      Do not acquire the object Lock on Sink before querying the time on PulseSink clock. This is
      similar to the way we have used get_time at other places in the code. Acquire it after the
      get_time call. This way PA Main loop will be able to post its stream status message by
      acquiring the Sink Object lock and will eventually release its Main Loop lock needed for
      gst_pulsesink_get_time to continue.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=736071
      1c9b57ed
    • Sebastian Dröge's avatar
      videofilter: Unref buffers before calling the transform_frame functions · 74d4f2ee
      Sebastian Dröge authored
      GstVideoFrame has another reference, so the buffer looks unwriteable,
      meaning that we can't attach any metas or anything to it
      
      https://bugzilla.gnome.org/show_bug.cgi?id=736118
      74d4f2ee
  7. Sep 11, 2014
    • Thiago Santos's avatar
      decodebin: protect buffering message handling · f3ae1be0
      Thiago Santos authored
      Use the object lock to avoid concurrent processing which leads
      to small disasters (assertions or crashes)
      f3ae1be0
    • George Kiagiadakis's avatar
      playbin: filter out buffering messages when switching uri · a38d2567
      George Kiagiadakis authored and Sebastian Dröge's avatar Sebastian Dröge committed
      When switching URI from about-to-finish, playbin starts decoding the new
      URI and the queue2 inside uridecodebin starts emitting buffering messages
      immediately. However, the queue(s) inside playsink still have buffers to
      play and the pipeline doesn't need to pause for buffering, so we should
      not send those buffering messages up to the application, otherwise there
      is an audible glitch caused by pausing the pipeline for a very short time.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=727255
      a38d2567
    • Kipp Cannon's avatar
      audioresample: don't skip input samples · 0bf81236
      Kipp Cannon authored and Sebastian Dröge's avatar Sebastian Dröge committed
      when downsampling, the output buffer can be filled before all the input
      samples are consumed.  this is correct:  when downsampling, several input
      samples are needed for each output sample, so when only a small number of
      input samples are available the number of output samples produced can be 0.
      
      the resampler, however, was discarding those extra input samples instead of
      clocking them into its filter history for the next iteration.  this patch
      fixes this by removing the check that the output buffer is full.  the code
      now always loops until all input samples are consumed, and relies on the
      calling code to have provided a suitably sized location for the output.
      note that there are already other checks in place in the calling code to
      ensure that this is the case.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=732908
      0bf81236
  8. Sep 04, 2014
  9. Sep 01, 2014
  10. Aug 27, 2014
  11. Aug 26, 2014
  12. Aug 18, 2014
  13. Aug 13, 2014
  14. Aug 11, 2014
  15. Jul 31, 2014
Loading