1. 05 Jun, 2020 1 commit
    • 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>
  2. 04 Jun, 2020 1 commit
    • Edward Hervey's avatar
      queue2: Avoid races when posting buffering messages · 08d2d3cf
      Edward Hervey authored
      When posting a buffering message succesfully:
      * Remember the *actual* percentage value that was posted
      * Make sure we only reset the percent_changed variable if the value we just
        posted is indeed different from the current value
      Part-of: <!511>
  3. 27 May, 2020 2 commits
    • 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>
  4. 06 May, 2020 1 commit
  5. 06 Apr, 2020 1 commit
  6. 31 Oct, 2019 1 commit
    • Niels De Graef's avatar
      queue2: Use g_object_notify_by_pspec · 0ca0a9d9
      Niels De Graef authored
      `g_object_notify()` actually takes a global lock to look up the
      `GParamSpec` that corresponds to the given property name. It's not a
      huge performance hit, but it's easily avoidable by using the
      `_by_pspec()` variant.
  7. 17 Dec, 2018 1 commit
  8. 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
    • 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.
  9. 22 Oct, 2018 1 commit
    • Edward Hervey's avatar
      queue2: Reset result flow when retrying · 98fabd2f
      Edward Hervey authored
      If we ever get a GST_FLOW_EOS from downstream, we might retry
      pushing new data. But if pushing that data doesn't return a
      GstFlowReturn (such as pushing events), we would end up returning
      the previous GstFlowReturn (i.e. EOS).
      Not properly resetting it would cause cases where queue2 would
      stop pushing on the first GstEvent stored (even if there is more
      data contained within).
  10. 04 Jun, 2018 1 commit
  11. 02 Mar, 2018 1 commit
  12. 17 Sep, 2017 1 commit
  13. 09 Aug, 2017 2 commits
  14. 07 Aug, 2017 1 commit
    • Edward Hervey's avatar
      queue2: Handle buffering levels on NOT_LINKED · 4312119d
      Edward Hervey authored
      When downstream returns NOT_LINKED, we return the buffering level
      as being 100%.
      Since the queue is no longer being consumed/used downstream, we
      want applications to essentially "ignore" this queue for buffering
      If other streams are still being used, those stream buffering levels
      will be used. If none are used, upstream will post an error message
      on the bus indicating no streams are used.
  15. 11 Mar, 2017 1 commit
  16. 27 Jan, 2017 1 commit
  17. 13 Dec, 2016 2 commits
  18. 15 Nov, 2016 1 commit
    • Jan Schmidt's avatar
      queues: Don't return negative position queries. · a6ca8dfb
      Jan Schmidt authored
      When subtracting queued data sizes from upstream queries
      in queue, queue2, downloadbuffer and typefind, clamp the
      result to not go negative, in case upstream returned
      a nonsense value that's too small (as could happen if
      upstream is estimating, or just broken)
  19. 08 Oct, 2016 1 commit
  20. 17 Sep, 2016 1 commit
  21. 27 Aug, 2016 1 commit
  22. 25 Aug, 2016 2 commits
  23. 12 Aug, 2016 1 commit
    • Edward Hervey's avatar
      queue2: Post buffering messages earlier in ringbuffer mode · 5154dcfb
      Edward Hervey authored
      In ringbuffer mode we need to make sure we post buffering messages *before*
      blocking to wait for data to be drained.
      Without this, we would end up in situations like this:
      * pipeline is pre-rolling
      * Downstream demuxer/decoder has pushed data to all sinks, and demuxer thread
        is blocking downstream (i.e. not pulling from upstream/queue2).
      * Therefore pipeline has pre-rolled ...
      * ... but queue2 hasn't filled up yet, therefore the application waits for
        the buffering 100% messages before setting the pipeline to PLAYING
      * But queue2 can't post that message, since the 100% message will be posted
        *after* there is room available for that last buffer.
  24. 11 Jul, 2016 1 commit
    • Edward Hervey's avatar
      queue2: Fix average input rate calculation on small input range · 1ff80fbf
      Edward Hervey authored
      When dealing with small-ish input data coming into queue2, such as
      adaptivedemux fragments, we would never take into account the last
      <200ms of data coming in.
      The problem is that usually on TCP connection the download rate
      gradually increases (i.e. the rate is lower at the beginning of a
      download than it is later on). Combined with small download time (less
      than a second) we would end up with a computed average input rate
      which was sometimes up to 30-50% off from the *actual* average input
      rate for that fragment.
      In order to fix this, force the average input rate calculation when
      we receive an EOS so that we take into account that final window
      of data.
  25. 21 Jun, 2016 1 commit
  26. 15 May, 2016 1 commit
  27. 28 Feb, 2016 1 commit
  28. 23 Feb, 2016 1 commit
  29. 16 Feb, 2016 1 commit
  30. 19 Jan, 2016 1 commit
    • Jan Schmidt's avatar
      queue2: Add use-tags-bitrate property · c1f49208
      Jan Schmidt authored
      The use-tags-bitrate property makes queue2 look at
      tag events in the stream and extract a bitrate for the
      stream to use when calculating a duration for buffers
      that don't have one explicitly set.
      This lets queue2 sensibly buffer to a time threshold
      for any bytestream for which the general bitrate is known.
  31. 06 Jan, 2016 2 commits
  32. 12 Dec, 2015 2 commits
  33. 02 Dec, 2015 1 commit
    • Jan Schmidt's avatar
      queue2: Don't report 0% unless empty · 725a71ea
      Jan Schmidt authored
      When preparing a buffering message, don't report 0% if there
      is any bytes left in the queue at all. We still have something
      to push, so don't tell the app to start buffering - maybe
      we'll get more data before actually running dry.