decklink: keep the internal time we send to decklink always increasing
authorMatthew Waters <matthew@centricular.com>
Sun, 8 Jul 2018 14:54:04 +0000 (09:54 -0500)
committerMatthew Waters <matthew@centricular.com>
Tue, 10 Jul 2018 11:22:04 +0000 (21:22 +1000)
commita9b40eebc018de6133b1af7d92582166df3bafc7
treef5ed99135bfbe865a89b0eafbca29581dd0e0dbd
parentbd2920ca2df72bb8c4cb3f353dd1cf5bf37f5c4b
decklink: keep the internal time we send to decklink always increasing

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).
sys/decklink/gstdecklinkvideosink.cpp
sys/decklink/gstdecklinkvideosink.h