1. 05 Jun, 2020 2 commits
    • Jan Schmidt's avatar
      queue2: Defer downstream bitrate query to the streaming thread. · 8e670a23
      Jan Schmidt authored
      When we want to perform a downstream bitrate query, just
      set the reconfigure flag on the srcpad and get the streaming
      thread to do it. That avoids emitting a downstream query
      when receiving the upstream RECONFIGURE event - which can
      lead to deadlocks if downstream is sending the event from
      within a lock - e.g. input-selector.
      If querying the downstream bitrate changes the cached
      value, then make sure to update our buffering state
      and potentially post a BUFFERING message to the application.
      Fixes: #566
      Part-of: <!501>
    • Edward Hervey's avatar
      inputselector: Avoid deadlock when requesting pads · f2478618
      Edward Hervey authored
      The deadlock was the following:
      * One thread requests a new pad, the internal lock is kept while adding the pad
      * Another thread (or the same one) requests the internal links of a pad (could
      be that pad)... which also requires that lock.
      That internal lock is not required when adding the pad to the element (which is
      the last action when requesting a new pad). The fact it will be actually used
      will be *after* the request pad function is released.
      Part-of: <!512>
  2. 04 Jun, 2020 12 commits
  3. 28 May, 2020 3 commits
  4. 27 May, 2020 7 commits
    • Tim-Philipp Müller's avatar
      tests: leak tracer: disable stack traces for faster test execution · e0bcf24d
      Tim-Philipp Müller authored
      This test takes 39 seconds on my machine even though it just runs
      a couple of fakesrc num-buffers=2 ! fakesink pipelines. Most of
      the cpu seems to be spent in libz, related to stack trace management.
      Use stack-traces-flags=none instead of stack-traces-flags=full
      until a better solution can be found. Might warrant more
      investigation in any case..
      Part-of: <!503>
    • Mathieu Duponchelle's avatar
      queue2: don't post unnecessary buffering message, refine locking · 07fcd4d1
      Mathieu Duponchelle authored
      This is a follow up to review comments in !297
      + The posting of the buffering message in READY_TO_PAUSED isn't
        needed, removing it made the test fail, but the correct fix
        was simply to link elements together
      + Move code to relock the queue and set last_posted_buffering_percent
        and percent_changed inside the buffering_post_lock in create_write().
        This makes locking consistent with post_buffering()
      Part-of: <!297>
    • Carlos Rafael Giani's avatar
      queue2: Fix missing/dropped buffering messages at startup · 6d4ad80b
      Carlos Rafael Giani authored
      This fixes a bug that occurs when an attempt is made to post a buffering
      message before the queue2 was assigned a bus. One common situation where
      this happens is when the use-buffering property is set to TRUE before the
      queue2 was added to a bin.
      If the result of gst_element_post_message() is not checked, and the
      aforementioned situation occurs, then last_posted_buffering_percent and
      percent_changed will still be updated, as if posting the message succeeded.
      Later attempts to post again will not do anything because the code then
      assumes that a message with the same percentage was previously posted
      successfully and posting again is redundant.
      Updating these variables only if posting succeed and explicitely
      posting a buffering message in the READY->PAUSED state change ensure that
      a buffering message is posted as early as possible.
      Part-of: <!297>
    • Sebastian Dröge's avatar
      systemclock: Only try initializing entries if they were not initialized before · bf0672f0
      Sebastian Dröge authored
      And add assertions accordingly.
      Part-of: <!500>
    • Sebastian Dröge's avatar
      systemclock: Clarify comment that described a previous version of the code · d9bf0f1e
      Sebastian Dröge authored
      Nowadays we are only waking up the head entry waiting if either the head
      entry is unscheduled (which is handled some lines above already), or
      when the head entry specifically is woken up because a new entry became
      the new head entry.
      We're not waking up *all* entries anymore whenever any entry in the last
      was unscheduled.
      Part-of: <!500>
    • Sebastian Dröge's avatar
      systemclock: Get rid of atomic access to clock entry status and use the mutex instead · c4a2d927
      Sebastian Dröge authored
      We already have a mutex in each clock entry anyway and need to make use
      of that mutex in most cases when the status changes. Removal of the
      atomic operations and usage of the mutex instead simplifies the code
      The only downside is that unscheduling a clock entry might block for the
      time it needs for the waiting thread to go from checking the status of
      the entry to actually waiting, which is not a lot of code.
      Part-of: <!500>
    • Sebastian Dröge's avatar
      systemclock: Don't start waiting for a clock id if it was signalled before · 3e924f5d
      Sebastian Dröge authored
      Otherwise it can happen that unscheduling a clock id never takes place
      and instead it is waiting until the normal timeout. This can happen if
      the wait thread checks the status and sets it to busy, then the
      unschedule thread sets it to unscheduled and signals the condition
      variable, and then the waiting thread starts waiting. As condition
      variables don't have a state (unlike Windows event objects), we have to
      remember ourselves in a new boolean flag protected by the entry mutex
      whether it is currently signalled, and reset this after waiting.
      Previously this was not a problem because a file descriptor was written
      to for waking up, and the token was left on the file descriptor until
      the read from it for waiting.
      Part-of: <!500>
  5. 25 May, 2020 2 commits
  6. 20 May, 2020 5 commits
  7. 19 May, 2020 3 commits
  8. 18 May, 2020 1 commit
    • Edward Hervey's avatar
      gstbin: Remove mentions of duration caching · 7f068512
      Edward Hervey authored
      This was effectively disabled in 1.0 with the intent of maybe re-enabling it.
      The problem is that caching duration at a bin level doesn't make much sense
      since there might be queueing/buffering taking place internally and therefore
      the duration reported might have no correlation to what is actually being
      Remove commented code and fixmes, and update documentation
      Fixes #4
      Part-of: <!489>
  9. 15 May, 2020 5 commits