1. 26 Oct, 2018 1 commit
  2. 23 Oct, 2018 2 commits
  3. 22 Oct, 2018 2 commits
    • Edward Hervey's avatar
      multiqueue: Don't clamp running times for position calculation · 127e2110
      Edward Hervey authored
      Since we use full signed running times, we no longer need to clamp
      the buffer time.
      
      This avoids having the position of single queues not advancing for
      buffers that are out of segment and never waking up non-linked
      streams (resulting in an apparent "deadlock").
      127e2110
    • 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).
      98fabd2f
  4. 17 Oct, 2018 1 commit
  5. 16 Oct, 2018 1 commit
  6. 15 Oct, 2018 2 commits
  7. 12 Oct, 2018 2 commits
  8. 11 Oct, 2018 5 commits
  9. 07 Oct, 2018 1 commit
  10. 03 Oct, 2018 3 commits
  11. 27 Sep, 2018 4 commits
  12. 24 Sep, 2018 3 commits
    • Tim-Philipp Müller's avatar
      meson: use library() for libgstcheck instead of always building a shared lib · 50c32da9
      Tim-Philipp Müller authored
      Otherwise we try to build a shared lib when we build the rest
      of GStreamer statically, which won't work because we pass
      -DGST_STATIC_COMPILATION when building statically, which means
      we won't dllimport public symbols from our libs which means
      that on Windows the unit tests will fail to link to libgstcheck.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797185
      50c32da9
    • Tim-Philipp Müller's avatar
      tests: netclock-replay: fix build with new api export/import · af5717b3
      Tim-Philipp Müller authored
      Can't mix/match imports and exports from the same library
      here, so just include all .c files needed instead and don't
      link to gstnet at all then.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797185
      af5717b3
    • Tim-Philipp Müller's avatar
      libs: figure out right export define in configure · 57c8e014
      Tim-Philipp Müller authored
      Add new GST_API_EXPORT in config.h and use that for GST_*_API
      decorators instead of GST_EXPORT.
      
      The right export define depends on the toolchain and whether
      we're using -fvisibility=hidden or not, so it's better to set it
      to the right thing directly than hard-coding a compiler whitelist
      in the public header.
      
      We put the export define into config.h instead of passing it via the
      command line to the compiler because it might contain spaces and brackets
      and in the autotools scenario we'd have to pass that through multiple
      layers of plumbing and Makefile/shell escaping and we're just not going
      to be *that* lucky.
      
      The export define is only used if we're compiling our lib, not by external
      users of the lib headers, so it's not a problem to put it into config.h
      
      Also, this means all .c files of libs need to include config.h
      to get the export marker defined, so fix up a few that didn't
      include config.h.
      
      This commit depends on a common submodule commit that makes gst-glib-gen.mak
      add an #include "config.h" to generated enum/marshal .c files for the
      autotools build.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797185
      57c8e014
  13. 23 Sep, 2018 2 commits
    • Tim-Philipp Müller's avatar
      libs: fix 'inconsistent DLL linkage' warnings on Windows · 46ed0f04
      Tim-Philipp Müller authored
      For each lib we build export its own API in headers when we're
      building it, otherwise import the API from the headers.
      
      This fixes linker warnings on Windows when building with MSVC.
      
      The problem was that we had defined all GST_*_API decorators
      unconditionally to GST_EXPORT. This was intentional and only
      supposed to be temporary, but caused linker warnings because
      we tell the linker that we want to export all symbols even
      those from externall DLLs, and when the linker notices that
      they were in external DLLS and not present locally it warns.
      
      What we need to do when building each library is: export
      the library's own symbols and import all other symbols. To
      this end we define e.g. BUILDING_GST_FOO and then we define
      the GST_FOO_API decorator either to export or to import
      symbols depending on whether BUILDING_GST_FOO is set or not.
      That way external users of each library API automatically
      get the import.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797185
      46ed0f04
    • Tim-Philipp Müller's avatar
      gstconfig.h: add GST_API_IMPORT define · 50038bed
      Tim-Philipp Müller authored
      This is for use by the various GST_*_API decorators and
      will be what they get defined to when a library API is being
      used by external users of that library (not the library itself
      whilst it's being compiled).
      
      In most cases it will simply map to a plain 'extern' but on
      Windows with MSVC it will need to map to __declspec(dllimport).
      For functions this is not strictly needed, but for exported
      variables it is.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797185
      50038bed
  14. 21 Sep, 2018 1 commit
  15. 20 Sep, 2018 1 commit
  16. 19 Sep, 2018 5 commits
  17. 17 Sep, 2018 1 commit
  18. 12 Sep, 2018 1 commit
  19. 08 Sep, 2018 1 commit
  20. 05 Sep, 2018 1 commit