Skip to content
Snippets Groups Projects
  1. Dec 03, 2019
  2. Dec 02, 2019
    • Jeremy Lempereur's avatar
      avfvideosrc: Explicitly request device video permissions for macOS 10.14+ · 6d68e1e6
      Jeremy Lempereur authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      Since macOS Mojave (10.14), video permissions have to be explicitly
      granted by a user in order to open a video device such as a camera.
      This commit adds a check for the current permission status, and tries
      to request for permission if applicable.
      6d68e1e6
    • Nirbheek Chauhan's avatar
      openexr: Fix check for when to pass -std=c++98 · d3d42289
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      commit 6adfb120 added this flag to fix
      builds with `-Werror`, and afterwards it was changed to use a version
      check when newer versions of openexr moved over to C++11.
      
      However, some distros have backported patches to older openexr
      versions which make it require C++11, which makes the version check
      incorrect and causes an error because we passed `-Werror -std=c++98`.
      
      Instead, directly check when usage of the header requires `-std=c++98`
      with `-Werror` and override the `cpp_std` setting on the target.
      
      Fixes #1117
      d3d42289
  3. Nov 28, 2019
    • Nirbheek Chauhan's avatar
      wasapisrc: Correctly handle BUFFERFLAGS_SILENT · d9e6f190
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      We need to ignore the data we get from WASAPI in this case and write
      out silence (zeroes).
      
      Initially reported at gstreamer/gst-plugins-bad#808
      d9e6f190
    • Nirbheek Chauhan's avatar
      wasapisrc: Try harder to avoid debug output in the hot loop · 5f92188a
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      The whole `src_read()` function is a hot loop since the ringbuffer
      thread is waiting on us, and printing to the console from inside it
      can easily cause us to miss our deadline.
      
      F.ex., if you had GST_DEBUG=3 and we accidentally missed a device
      period, we'd trigger the "reported glitch" warning, which would cause
      us to miss another device period, and so on. Let's reduce the log
      level so that GST_DEBUG=3 is more usable, and only print buffer flag
      info when it's actually relevant.
      5f92188a
    • Nirbheek Chauhan's avatar
      wasapisrc: Fix capturing from some buggy audio drivers · 6a2dcdb7
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      Some audio drivers return varying amounts of data per ::GetBuffer
      call, instead of following the device period that they've told us
      about in `src_prepare()`.
      
      Previously, we would just drop those extra buffers hoping that the
      extra buffers were temporary (f.ex., a startup 'burst' of audio data).
      However, it seems that some audio drivers, particularly on older
      Windows versions (such as Windows 10 1703 and older) consistently
      return varying amounts of data.
      
      Use GstAdapter to smooth that out, and hope that the audio driver is
      locally varying but globally periodic.
      
      Initially reported in gstreamer/gst-plugins-bad#808
      6a2dcdb7
    • Nirbheek Chauhan's avatar
      wasapisrc: Clarify that nBlockAlign is actually bpf · 0ac8ebdc
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      bpf = bytes per frame.
      0ac8ebdc
    • Nirbheek Chauhan's avatar
      wasapisrc: Fix glitching and clock skew issues · 96956cf4
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      We were miscalculating the device period, i.e. the number of frames
      we'll get from WASAPI in each IAudioClient::GetBuffer call, due to
      a calculation mistake (truncate instead of round).
      
      For example, on my machine when the aux input is set to 44.1KHz, the
      reported device period is 101587, which comes out to 447.998 frames
      per ::GetBuffer call. In reality we will, of course, get 448 frames
      per call, but we were truncating, so we expected 447 and were
      discarding one frame every time. This led to glitching, and skew over
      time.
      
      Interestingly, I can only see this with 44.1Khz. 48Khz/96Khz are fine,
      because the device period is a more 'even' number.
      
      Fixes gstreamer/gst-plugins-bad#806
      96956cf4
  4. Nov 26, 2019
  5. Nov 20, 2019
  6. Nov 18, 2019
  7. Nov 14, 2019
  8. Nov 11, 2019
  9. Nov 04, 2019
  10. Oct 29, 2019
  11. Oct 24, 2019
  12. Oct 17, 2019
  13. Oct 06, 2019
  14. Oct 01, 2019
  15. Sep 23, 2019
  16. Sep 09, 2019
  17. Sep 06, 2019
    • Askar Safin's avatar
      gst-player: fix bug with changing playback direction · 21ad51f4
      Askar Safin authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      Fix gst_event_new_seek call in gst-libs/gst/player/gstplayer.c
      
      If rate >= 0.0, then previous code doesn't set end of segment. So, the end of segment
      will be in place where previous seek put it. This is not neccesary end of media file
      (in case of reverse playback). So if we play video backward for some time and then
      switched to forward playing, we will get EOS somewhere in the middle of media file.
      This commit always sets end of segment, thus fixing this bug
      21ad51f4
  18. Sep 02, 2019
  19. Aug 31, 2019
  20. Aug 23, 2019
  21. Aug 21, 2019
Loading