1. 03 May, 2019 1 commit
  2. 04 Mar, 2019 2 commits
  3. 19 Feb, 2019 1 commit
  4. 12 Feb, 2019 2 commits
  5. 05 Feb, 2019 1 commit
    • Nirbheek Chauhan's avatar
      misc: Fix warnings on Cerbero MinGW · fffb2aa1
      Nirbheek Chauhan authored
      gstladspa.c:360:5: error: zero-length ms_printf format string [-Werror=format-zero-length]
      
      vad_private.c:108:3: error: this decimal constant is unsigned only in ISO C90 [-Werror]
      
      gstdecklinkvideosink.cpp:478:32: error: comparison between 'BMDTimecodeFormat {aka enum _BMDTimecodeFormat}' and 'enum GstDecklinkTimecodeFormat' [-Werror=enum-compare]
      
      win/DeckLinkAPI_i.c:72:8: error: extra tokens at end of #endif directive [-Werror]
      
      win/DeckLinkAPIDispatch.cpp:35:10: error: unused variable 'res' [-Werror=unused-variable]
      
      gstwasapiutil.c:733:3: error: format '%x' expects argument of type 'unsigned int', but argument 8 has type 'DWORD' [-Werror=format]
      gstwasapiutil.c:733:3: error: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'guint64' [-Werror=format]
      
      kshelpers.c:446:3: error: missing braces around initializer [-Werror=missing-braces]
      kshelpers.c:446:3: error: (near initialization for 'known_property_sets[0].guid.Data4') [-Werror=missing-braces]
      fffb2aa1
  6. 02 Jan, 2019 1 commit
  7. 18 Dec, 2018 1 commit
  8. 15 Dec, 2018 1 commit
  9. 12 Dec, 2018 1 commit
    • Matthew Waters's avatar
      decklink: calculate the decklink output time from the internal clock · 59c5ae28
      Matthew Waters authored
      Fixes the time calculations when dealing with a slaved clock (as
      will occur with more than one decklink video sink), when performing
      flushing seeks causing stalls in the output timeline, pausing.
      
      Tighten up the calculations by relying solely on the internal time
      (from the internal clock) for determining when to schedule display
      frames instead attempting to track pause lengths from the external
      clock and converting to internal time.  This results in a much easier
      offset calculation for choosing the output time and ensures that the
      clock is always advancing when we need it to.
      
      This is fixup to the 'monotonically increasing output timestamps' goal
      in: bf849e9a
      59c5ae28
  10. 26 Nov, 2018 1 commit
  11. 13 Nov, 2018 1 commit
  12. 12 Nov, 2018 1 commit
  13. 06 Nov, 2018 1 commit
  14. 12 Sep, 2018 3 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
  15. 10 Jul, 2018 1 commit
    • Matthew Waters's avatar
      decklink: keep the internal time we send to decklink always increasing · a9b40eeb
      Matthew Waters authored
      Otherwise 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).
      a9b40eeb
  16. 14 Dec, 2017 2 commits
  17. 06 Dec, 2017 1 commit
  18. 22 Nov, 2017 1 commit
  19. 18 Oct, 2017 1 commit
  20. 15 Aug, 2017 1 commit
  21. 02 Aug, 2017 1 commit
  22. 18 Jul, 2017 2 commits
    • Nirbheek Chauhan's avatar
      decklink: Fix format specifier warnings in logging v2 · ca8c6308
      Nirbheek Chauhan authored
      HRESULT is unsigned long on Windows, but the Decklink headers define
      it to 'int' on Linux. Confusingly, the defines that talk about the
      possible return values for it use long constants. The easy fix would
      be to change the linux/LinuxCOM.h header, but that's copied from the
      decklink SDK.
      
      Change the logging to always upcast to unsigned long while printing
      HRESULT for consistency across platforms.
      ca8c6308
    • Nirbheek Chauhan's avatar
      decklink: Fix build on mingw32 by adding missing WINAPI · 0084bfcc
      Nirbheek Chauhan authored
      gstdecklinkaudiosink.cpp:155:19: error: conflicting type attributes specified for 'virtual HRESULT GStreamerAudioOutputCallback::QueryInterface(const IID&, void**)'
      In file included from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/objbase.h:153:0,
                       from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/ole2.h:16,
                       from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/windows.h:94,
                       from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/rpc.h:16,
                       from win/DeckLinkAPI.h:27,
                       from gstdecklink.h:35,
                       from gstdecklinkaudiosink.h:27,
                       from gstdecklinkaudiosink.cpp:25:
      /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/unknwn.h:67:25: error:   overriding 'virtual HRESULT IUnknown::QueryInterface(const IID&, void**)'
      
      (and many more)
      
      https://ci.gstreamer.net/job/cerbero-cross-mingw32/6407/console
      0084bfcc
  23. 15 May, 2017 1 commit
  24. 05 May, 2017 2 commits
  25. 01 Mar, 2017 1 commit
  26. 01 Feb, 2017 2 commits
  27. 28 Nov, 2016 2 commits
    • Sebastian Dröge's avatar
      decklink: Correctly set top-field-first/bottom-field-first · fdf1a579
      Sebastian Dröge authored
      First of all, all the HD and UHD modes should be top-field-first, as
      also returned by the Decklink mode iterator API.
      
      Then we should include the caps field "field-order" in the caps of the
      source (not the sink due to negotiation problems with optional fields).
      
      And finally we should set the TFF flag on interlaced buffers that are
      top-field-first.
      fdf1a579
    • Sebastian Dröge's avatar
      decklinksrc: Stop using the "hardware" timestamps and directly use the pipeline clock · 881a0867
      Sebastian Dröge authored
      The hardware timestamps have no relation to when frames were produced,
      only when frames arrived somewhere in the hardware. Especially there is
      no guarantee that audio and video will have the same hardware timestamps
      although they belong together, and even more important: the rate with
      which the hardware timestamps increase is completely unrelated to the
      rate with which the frames are captured!
      
      As such we can as well use the pipeline clock directly and stop doing
      complicated calculations. Also as a side effect this allows now running
      without any pipeline clock, by directly making use of the stream times
      as reported by the driver.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=774850
      881a0867
  28. 02 Nov, 2016 2 commits
  29. 21 Sep, 2016 1 commit
  30. 12 Sep, 2016 1 commit