Skip to content
Snippets Groups Projects
  1. Aug 19, 2016
  2. Aug 16, 2016
    • Edward Hervey's avatar
      queue2: Post buffering messages earlier in ringbuffer mode · 0846f130
      Edward Hervey authored and Sebastian Dröge's avatar Sebastian Dröge committed
      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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769802
      0846f130
    • Edward Hervey's avatar
      queue2: Fix average input rate calculation on small input range · 41605695
      Edward Hervey authored and Sebastian Dröge's avatar Sebastian Dröge committed
      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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=768649
      41605695
  3. Aug 13, 2016
  4. Jul 25, 2016
  5. Jul 04, 2016
  6. Jul 01, 2016
    • Edward Hervey's avatar
      multiqueue: Fix behaviour with not-linked and eos pads · 17ab6166
      Edward Hervey authored and Edward Hervey's avatar Edward Hervey committed
      This is an update on c9b68488
      multiqueue: Fix not-linked pad handling at EOS
      
      While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS,
      it would break the same issue when *downstream* returns GST_FLOW_EOS
      (which can happen for example when downstream decoders receive data
      from after the segment stop).
      
      GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it
      and not when a GST_EVENT_EOS has gone through it.
      
      In order to handle both cases, also take into account the last flow
      return.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=763770
      17ab6166
  7. Jun 27, 2016
    • Nicolas Dufresne's avatar
      tee: Properly handle return value when only 1 pad · 04655110
      Nicolas Dufresne authored and Sebastian Dröge's avatar Sebastian Dröge committed
      This patch handle the case when you have 1 pad (so the fast path is
      being used) but this pad is removed. If we are in allow-not-linked, we
      should return GST_FLOW_OK, otherwise, we should return GST_FLOW_UNLINKED
      and ignore the meaningless return value obtained from pushing.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=767413
      04655110
    • Sebastian Dröge's avatar
      basesink: Update start time when losing state only if we were in PLAYING · ba536c23
      Sebastian Dröge authored
      If we were in PAUSED, the current clock time and base time don't have much to
      do with the running time anymore as the clock might have advanced while we
      were PAUSED. The system clock does that for example, audio clocks often don't.
      
      Updating the start time in PAUSED will cause a) the wrong position to be
      reported, b) step events to step not just the requested amount but the amount
      of time we spent in PAUSED. The start time should only ever be updated when
      going from PLAYING to PAUSED to remember the current running time (to be able
      to compensate later when going to PLAYING for the clock time advancing while
      PAUSED), not when we are already in PAUSED.
      
      Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com>
      
      The updating of the start time when the state is lost was added in commit
      ba943a82 to fix the position reporting when
      the state is lost. This still works correctly after this change.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=739289
      ba536c23
  8. Jun 17, 2016
  9. Jun 09, 2016
  10. May 20, 2016
  11. May 19, 2016
  12. May 16, 2016
    • Jan Schmidt's avatar
      bin: Fix EOS forwarding on PLAYING->PLAYING · 7c65287c
      Jan Schmidt authored
      When doing a transition from PLAYING to PLAYING, we will fail
      to forward an EOS message on the bus, and noone else will ever
      send it because there'll be no actual state changed message.
      
      Allow EOS through directly in that case.
      7c65287c
  13. May 12, 2016
  14. May 11, 2016
    • Sebastian Dröge's avatar
      pad: Fix pad state when deactivating from one mode and then trying to activate another and failing · 7eb49425
      Sebastian Dröge authored
      When activating a pad in PULL mode, it might already be in PUSH mode. We now
      first try to deactivate it from PUSH mode and then try to activate it in PULL
      mode. If the activation fails, we would set the pad to flushing and set it
      back to its old mode. However the old mode is wrong, the pad is not in PUSH
      mode anymore but in NONE mode.
      
      This fixes e.g. typefind in decodebin reactivating PUSH/PULL mode if upstream
      actually fails to go into PULL mode after first PUSHING data to typefind.
      7eb49425
  15. May 06, 2016
  16. Apr 28, 2016
  17. Apr 26, 2016
  18. Apr 20, 2016
  19. Apr 15, 2016
  20. Mar 29, 2016
  21. Mar 25, 2016
Loading