1. 01 Oct, 2018 2 commits
  2. 27 Sep, 2018 1 commit
  3. 26 Sep, 2018 1 commit
  4. 24 Sep, 2018 4 commits
    • Sebastian Dröge's avatar
      glmixerbin: "latency" property on aggregator is uint64, not int64 · 47b69bca
      Sebastian Dröge authored
      Also update the property description and range with aggregator's values.
      47b69bca
    • Tim-Philipp Müller's avatar
      96ac822b
    • Tim-Philipp Müller's avatar
      libs: fix API export/import and 'inconsistent linkage' on MSVC · b6411ae7
      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.
      
      While we're at it, 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
      b6411ae7
    • Tim-Philipp Müller's avatar
      docs: plugins: update for git master · be3edc6a
      Tim-Philipp Müller authored
      be3edc6a
  5. 22 Sep, 2018 2 commits
  6. 21 Sep, 2018 14 commits
  7. 19 Sep, 2018 5 commits
  8. 18 Sep, 2018 1 commit
  9. 12 Sep, 2018 4 commits
    • Matthew Waters's avatar
      decklinkvideosink: fix build · 17f0271a
      Matthew Waters authored
      ../sys/decklink/gstdecklinkvideosink.cpp:1006:11: error: ‘GstDecklinkVideoSink {aka struct _GstDecklinkVideoSink}’ has no member named ‘scheduled_stop_time’
           self->scheduled_stop_time = start_time;
                 ^
      17f0271a
    • Matthew Waters's avatar
      decklink: wait for stop with a timeout · 946cbbcc
      Matthew Waters authored
      Decklink sometimes does not notify us through the callback that it has
      stopped scheduled playback either because it was uncleanly shutdown
      without an explicit stop or for unknown other reasons.
      
      Wait on the cond for a short amount of time before checking if scheduled
      playback has stopped without notification.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797130
      946cbbcc
    • Matthew Waters's avatar
      decklink: start scheduled playback in paused · bf849e9a
      Matthew Waters authored
      This is part of a much larger goal to always keep the frames we schedule to
      decklink be always increasing.  This also allows us to avoid using both the
      sync and async frame display functions which aren't recomended to be used
      together.
      
      If the output timestatmsp is not always increasing decklink seems to hold
      onto the latest frame and may cause a flash in the output if the played
      sequence has a framerate less than the video output.
      
      Scenario is play for N seconds, pause, flushing seek to some other position,
      play again.  Each of the play sequences would normally start at 0 with
      the decklink time.  As a result, the latest frame from the previous sequence
      is kept alive waiting for it's timestamp to pass before either dropping
      (if a subsequent frame in the new sequence overrides it) or displayed
      causing the out of place frame to be displayed.
      
      This is also supported by the debug logs from the decklink video sink
      element where a ScheduledFrameCompleted() callback would not occur for
      the frame until the above had happened.
      
      It was timing related as to whether the frame was displayed based
      on the decklink refresh cycle (which seems to be 16ms here),
      when the frame was scheduled by the sink and the difference between
      the 'time since vblank' of the two play requests (and thus start times
      of scheduled playback).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797130
      bf849e9a
    • Matthew Waters's avatar
      decklinkaudiosink: fix debug string copy-paste error · 87077d20
      Matthew Waters authored
      Stopping != Starting
      87077d20
  10. 11 Sep, 2018 6 commits