Skip to content
GitLab
  1. 21 Sep, 2018 10 commits
  3. 19 Sep, 2018 5 commits
  5. 18 Sep, 2018 1 commit
  7. 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
  9. 11 Sep, 2018 12 commits
  11. 10 Sep, 2018 2 commits
  13. 05 Sep, 2018 2 commits
  15. 03 Sep, 2018 2 commits
  17. 01 Sep, 2018 1 commit
  19. 31 Aug, 2018 1 commit