1. 06 Jul, 2016 3 commits
  2. 05 Jul, 2016 1 commit
  3. 04 Jul, 2016 1 commit
  4. 01 Jul, 2016 2 commits
  5. 30 Jun, 2016 4 commits
    • Tim-Philipp Müller's avatar
      3623f168
    • Tim-Philipp Müller's avatar
      715939cc
    • Edward Hervey's avatar
      multiqueue: Add a pad property to "group" streams · f4ba43b1
      Edward Hervey authored
      When syncing by running time, multiqueue will throttle unlinked streams
      based on a global "high-time" and the pending "next_time" of a stream.
      
      The idea is that we don't want unlinked streams to be "behind" the global
      running time of linked streams, so that if/when they get linked (like when
      switching tracks) decoding/playback can resume from the same position as
      the other streams.
      
      The problem is that it assumes elements downstream will have a more or less
      equal buffering/latency ... which isn't the case for streams of different
      type. Video decoders tend to have higher latency (and therefore consume more
      from upstream to output a given decoded frame) compared to audio ones, resulting
      in the computed "high_time" being at the position of the video stream,
      much further than the audio streams.
      
      This means the unlinked audio streams end up being quite a bit after the linked
      audio streams, resulting in gaps when switching streams.
      
      In order to mitigate this issue, this patch adds a new "group-id" pad property
      which allows users to "group" streams together. Calculating the high-time will
      now be done not only globally, but also per group. This ensures that within
      a given group unlinked streams will be throttled by that group's high-time
      instead.
      
      This fixes gaps when switching downstream elements (like switching audio tracks).
      f4ba43b1
    • Edward Hervey's avatar
      gst: New Stream listing/selection system · 63f6f05d
      Edward Hervey authored
      * GstStream
      * GstStreamCollection
      * GST_EVENT_SELECT_STREAMS
      * GST_MESSAGE_STREAM_COLLECTION
      63f6f05d
  6. 29 Jun, 2016 8 commits
  7. 28 Jun, 2016 1 commit
  8. 24 Jun, 2016 1 commit
  9. 23 Jun, 2016 1 commit
    • Nirbheek Chauhan's avatar
      win32: Don't use dllexport/import when only building statically · 48088867
      Nirbheek Chauhan authored
      If the prototypes in the public API have dllimport in them when building
      statically on Windows, the compiler will look for symbols with symbol
      mangling and indirection corresponding to a DLL. This will cause a build
      failure when trying to link tests/examples/etc.
      
      External users of GStreamer also need to define -DGST_STATIC_COMPILATION
      if they want to link to static gstreamer libraries on Windows.
      
      A similar version of this patch has been committed to all gstreamer
      repositories.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=767463
      48088867
  10. 21 Jun, 2016 3 commits
  11. 20 Jun, 2016 1 commit
  12. 17 Jun, 2016 2 commits
  13. 16 Jun, 2016 1 commit
  14. 15 Jun, 2016 1 commit
  15. 14 Jun, 2016 1 commit
  16. 13 Jun, 2016 1 commit
    • Sebastian Dröge's avatar
      basesink: Update start time when losing state only if we were in PLAYING · b9a4a2a9
      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
      b9a4a2a9
  17. 11 Jun, 2016 3 commits
  18. 10 Jun, 2016 2 commits
    • Sebastian Dröge's avatar
      adapter: Rename functions and implement new functions, update test · 8c7da1d4
      Sebastian Dröge authored
      We don't do calculations with different units (buffer offsets and bytes)
      anymore but have functions for:
      1) getting the number of bytes since the last discont
      2) getting the offset (and pts/dts) at the last discont
      
      and the previously added function to get the last offset and its distance from
      the current adapter position.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=766647
      8c7da1d4
    • Edward Hervey's avatar
      adapter: Add methods to query current offset · 67ae0ad2
      Edward Hervey authored
      API: gst_buffer_prev_offset
      API: gst_buffer_get_offset_from_discont
      
      The gst_buffer_get_offset_from_discont() method allows retrieving the current
      offset based on the GST_BUFFER_OFFSET of the buffers that were pushed in.
      
      The offset will be set initially by the GST_BUFFER_OFFSET of
      DISCONT buffers, and then incremented by the sizes of the following
      buffers.
      
      The gst_buffer_prev_offset() method allows retrievent the previous
      GST_BUFFER_OFFSET regardless of flags. It works in the same way as
      the other gst_buffer_prev_*() methods.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=766647
      67ae0ad2
  19. 09 Jun, 2016 1 commit
  20. 08 Jun, 2016 1 commit
  21. 07 Jun, 2016 1 commit