1. 08 Aug, 2019 1 commit
    • Edward Hervey's avatar
      gstpad: Probes that return HANDLED can reset the data info field · 53e879c7
      Edward Hervey authored
      Before GST_PAD_PROBE_HANDLED was introduced, we had to handle the case
      where some probes would reset the probe info data field to NULL. This would
      be considered an invalid use-case.
      But with GST_PAD_PROBE_HANDLED it is totally fine to reset that, since
      the probe has "handled" it.
  2. 13 Feb, 2019 1 commit
  3. 29 Jan, 2019 1 commit
  4. 26 Jan, 2019 1 commit
    • Nicolas Dufresne's avatar
      pad: Remove unneeded 64bit upcast in debug trace · c816ec4f
      Nicolas Dufresne authored
      The hook->hook_id is a gulong for which there are no portability issues
      when tracing in printf format with %lu. So use %lu and remove the upcast
      to 64 bit. This makes the code more consistent with everything else
      tracing that hook_id and other gulong id.
  5. 15 Jan, 2019 1 commit
  6. 14 Dec, 2018 1 commit
  7. 07 Nov, 2018 1 commit
    • 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
  8. 06 Nov, 2018 1 commit
    • Håvard Graff's avatar
      gstpad: use hook_id instead of hook in called_probes list · 4b3872f7
      Håvard Graff authored
      A pointer to a hook in this list can easily not be unique, given both
      the slice-allocator reusing memory, and the OS re-using freed blocks
      in malloc.
      By doing many repeated add and remove of probes, this becomes very easily
      Instead use hook_id, which *is* unique for a added GHook.
  9. 31 Aug, 2018 3 commits
  10. 01 Aug, 2018 2 commits
  11. 23 Jul, 2018 1 commit
    • Sebastian Dröge's avatar
      Revert "pad: Handle changing sticky events in pad probes" · 2aa9ad9c
      Sebastian Dröge authored
      This reverts commit 11e0f451.
      When pushing a sticky event out of a pad with a pad probe or pad offset,
      those should not be applied to the event that is actually stored in the
      event but only in the event sent downstream. The pad probe and pad
      offsets are conceptually *after* the pad, added by external code and
      should not affect any internal state of pads/elements.
      Also storing the modified event has the side-effect that a re-sent event
      would arrive with any previous modifications done by the same pad probe
      again inside that pad probe, and it would have to check if its
      modifications are already applied or not.
      For sink pads and generally for events arriving in a pad, some further
      changes are still needed and those are tracked in
      In addition, the commit also had a refcounting problem with events,
      causing already destroyed events to be stored inside pads.
  12. 24 Jun, 2018 1 commit
  13. 11 May, 2018 1 commit
  14. 01 May, 2018 1 commit
  15. 17 Apr, 2018 1 commit
  16. 01 Mar, 2018 1 commit
  17. 28 Feb, 2018 1 commit
  18. 27 Jan, 2018 1 commit
  19. 16 Jan, 2018 1 commit
    • Edward Hervey's avatar
      gstpad: Avoid stream-dead-lock on deactivation · 31383e44
      Edward Hervey authored
      The following case can happen when two thread try to activate and
      deactivate a pad at the same time:
      T1: starts to deactivate, calls pre_activate(), sets in_activation
          to TRUE and carries on
      T2: starts to activate, calls pre_activate(), in_activation is TRUE
          so it waits on the GCond
      T1: calls post_activate(), tries to acquire the streaming lock ..
          but can't because T2 is currently holding it
      With this patch, the deadlock will no longer happen but does not
      solve the problem that:
      T2: will resume activation of the pad, set the pad mode to the target
         one (PUSH or PULL) and eventually the streaming lock gets released.
      T1: is able to finish calling post_activate() ... but ... the pad
         wasn't deactivated (T2 was the last one to "activate" the pad.
  20. 15 Jan, 2018 1 commit
  21. 06 Dec, 2017 1 commit
  22. 24 Nov, 2017 1 commit
    • Stian Selnes's avatar
      pad: gst_pad_activate_mode() always succeed if same mode · 512cec3d
      Stian Selnes authored
      Checking that the pad is in the correct mode before the parent is
      checked makes the call always succeed if the mode is ok.
      This fixes a race with ghostpad where gst_pad_activate_mode() could
      trigger a g_critical() if the ghostpad is unparented while the
      proxypad is deactivating, for instance if the ghostpad is released.
      More specifically, gst_ghost_pad_internal_activate_push_default()'s
      call to gst_pad_activate_mode() would fail if ghostpad doesn't have a
      parent. With this patch it will return true of mode is already
  23. 16 Nov, 2017 2 commits
  24. 04 Sep, 2017 1 commit
  25. 02 Aug, 2017 1 commit
  26. 24 Feb, 2017 2 commits
  27. 27 Jan, 2017 1 commit
  28. 14 Dec, 2016 1 commit
  29. 08 Dec, 2016 1 commit
  30. 01 Nov, 2016 1 commit
    • Thiago Santos's avatar
      pad: add no-reconfigure link check · 83cac0f7
      Thiago Santos authored
      Enable it to prevent sending reconfigure when linking elements.
      Useful for autoplugging when we know caps or bufferpools shouldn't change
      to save doing caps renegotiation to end up with the same final scenario.
      The no-reconfigure is not a proper check, it is a flag. It is implemented
      as a GstPadLinkCheck to avoid creating another gst_pad_link variant.
  31. 25 Jul, 2016 1 commit
  32. 15 Jul, 2016 1 commit
  33. 07 Jul, 2016 1 commit
  34. 11 Jun, 2016 1 commit
  35. 13 May, 2016 1 commit
    • Edward Hervey's avatar
      pad: Don't drop LATENCY queries with default implementation · 794944f7
      Edward Hervey authored
      If there is only one pad in the internal pads, when folding for
      LATENCY queries it will just drop the response if it's not live.
      This is maybe not the proper fix, but it will just accept the first
      peer responses, and if there are any other pads, it will only take
      them into account if the response is live.
      This *should* properly handle the aggregation/folding behaviour of
      multiple live peer responses, while at the same time handling the
      simple one-pad-only-and-forward use-case