decklink: start scheduled playback in paused
authorMatthew Waters <matthew@centricular.com>
Sun, 8 Jul 2018 14:54:04 +0000 (09:54 -0500)
committerMatthew Waters <matthew@centricular.com>
Wed, 12 Sep 2018 11:16:27 +0000 (21:16 +1000)
commitbf849e9a69442f7a6f9d4f0a1ef30d5a8009f689
treed69b9010fa34e6ab89af513342dbaa4d84cc0f3c
parent87077d20de36f3f920f50dbf80b57649f03b4502
decklink: start scheduled playback in paused

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