1. 20 Jun, 2019 3 commits
  2. 13 Jun, 2019 1 commit
  3. 05 Jun, 2019 2 commits
  4. 31 May, 2019 1 commit
  5. 29 May, 2019 1 commit
  6. 21 May, 2019 2 commits
  7. 18 May, 2019 1 commit
  8. 16 May, 2019 1 commit
    • Sebastian Dröge's avatar
      filesink: Implement workaround for some (network) filesystems that spuriously... · eec9bd8d
      Sebastian Dröge authored
      filesink: Implement workaround for some (network) filesystems that spuriously return EACCES on write
      
      This seems to happen when another client is accessing the file at the
      same time, and retrying after a short amount of time solves it.
      
      Sometimes partial data is written at that point already but we have no
      idea how much it is, or if what was written is correct (it sometimes
      isn't) so we always first seek back to the current position and repeat
      the whole failed write.
      
      It happens at least on Linux and macOS on SMB/CIFS and NFS file systems.
      
      Between write attempts that failed with EACCES we wait 10ms, and after
      enough consecutive tries that failed with EACCES we simply time out.
      
      In theory a valid EACCES for files to which we simply have no access
      should've happened already during the call to open(), except for NFS
      (see open(2)).
      
      This can be enabled with the new max-transient-error-timeout property, and
      a new o-sync boolean property was added to open the file in O_SYNC mode
      as without that it's not guaranteed that we get EACCES for the actual
      writev() call that failed but might only get it at a later time.
      
      Fixes #305
      eec9bd8d
  9. 13 May, 2019 2 commits
  10. 15 Apr, 2019 4 commits
  11. 10 Apr, 2019 2 commits
  12. 09 Apr, 2019 1 commit
  13. 08 Apr, 2019 6 commits
  14. 18 Dec, 2018 1 commit
    • Jonny Lamb's avatar
      identity: fixes to the eos-after and error-after properties · 63170d52
      Jonny Lamb authored
      I copied `error-after` to make the `eos-after` property, but it turned
      out there were some problems with that one, so this patch: adds
      separate counters (so setting to NULL and reusing the element will
      still work); clarifies the properties' min values; and reports an
      error when both are set.
      63170d52
  15. 17 Dec, 2018 1 commit
  16. 11 Dec, 2018 1 commit
    • Jonny Lamb's avatar
      identity: add eos-after property · 460c0edb
      Jonny Lamb authored
      Using `num-buffers` can be unpredictable as buffer sizes are often
      arbitrary (filesrc, multifilesrc, etc.). The `error-after` property on
      `identity` is better but obviously reports an error afterwards. This
      adds `eos-after` which does exactly the same thing but reports EOS
      instead.
      460c0edb
  17. 28 Nov, 2018 2 commits
  18. 09 Nov, 2018 1 commit
  19. 07 Nov, 2018 2 commits
    • Matthew Waters's avatar
      query: add a new bitrate query · 4fc4ad87
      Matthew Waters authored
      Allows determining from downstream what the expected bitrate of a stream
      may be which is useful in queue2 for setting time based limits when
      upstream does not provide timing information.
      
      Implement bitrate query handling in queue2
      
      gst-plugins-base#60
      4fc4ad87
    • Matthew Waters's avatar
      queue2: avoid ping-pong between 0% and 100% buffering messages · c4ccff78
      Matthew Waters authored
      If upstream is pushing buffers larger than our limits, only 1 buffer
      is ever in the queue at a time.  Once that single buffer has left the
      queue, a 0% buffering message would be posted followed immediately by a
      100% buffering message when the next buffer was inserted into the queue
      a very short time later.  As per the recommendations, This would result
      in the application pausing for a short while causing the appearance of
      a short stutter.
      
      The first step of a solution involves not posting a buffering message if
      there is still data waiting on the sink pad for insertion into the queue.
      This successfully drops the 0% messages from being posted however a
      message is still posted on each transition to 100% when the new buffer
      arrives resulting in a string of 100% buffering messages.  We silence
      these by storing the last posted buffering percentage and only posting a
      new message when it is different from or last posted message.
      c4ccff78
  20. 06 Nov, 2018 1 commit
    • Nicolas Dufresne's avatar
      tracers: log: Fix post query trace · e1be0652
      Nicolas Dufresne authored
      The post tracer hooks have a GstQuery argument which was truncated from
      the trace. As the post hook is the one that contains the useful data,
      this bug was hiding the important information from that trace.
      e1be0652
  21. 05 Nov, 2018 1 commit
  22. 04 Nov, 2018 1 commit
  23. 26 Oct, 2018 1 commit
  24. 22 Oct, 2018 1 commit
    • Edward Hervey's avatar
      multiqueue: Don't clamp running times for position calculation · 127e2110
      Edward Hervey authored
      Since we use full signed running times, we no longer need to clamp
      the buffer time.
      
      This avoids having the position of single queues not advancing for
      buffers that are out of segment and never waking up non-linked
      streams (resulting in an apparent "deadlock").
      127e2110