Commit graph

11 commits

Author SHA1 Message Date
Matthew Waters
bf849e9a69 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
2018-09-12 21:16:27 +10:00
Matthew Waters
a9b40eebc0 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).
2018-07-10 21:22:04 +10:00
Sebastian Dröge
86888d9918 decklinkaudiosink: Re-implement around GstBaseSink instead of GstAudioBaseSink
The Decklink and GstAudioBaseSink APIs don't fit very well together,
which causes various problems due to inaccuracies in the clock
calculations and the actual ringbuffer and GStreamer's copy getting of
sync.

Problems are audio drop-outs and A/V sync getting wrong after
pausing/seeking.

https://bugzilla.gnome.org/show_bug.cgi?id=790114
2017-12-14 10:37:20 +02:00
Dave Johnstone
0cd1bf13e8 decklinkvideosink: Add support for Decklink hardware keying
Add two properties (keyer-mode and keyer-level) to control the built-in hardware keyer of Decklink cards.

https://bugzilla.gnome.org/show_bug.cgi?id=773660
2017-08-15 11:09:37 +03:00
Vivia Nikolaidou
de1f42a284 decklinkvideosink: Add support for GstVideoTimeCode
The timecode will be fetched from the video buffer and outputted on the
decklink video sink.

https://bugzilla.gnome.org/show_bug.cgi?id=766419
2016-08-04 19:08:27 +03:00
Vivia Nikolaidou
832764d2fd decklink: Add initial 10bit support for YUV modes
https://bugzilla.gnome.org/show_bug.cgi?id=742878
2016-05-03 15:57:23 +03:00
Sebastian Dröge
e3aaff400a decklinkvideosink: Remove late frame-dropping workaround for basesink bug
This was fixed by https://bugzilla.gnome.org/show_bug.cgi?id=749258
in basesink, and is not necessary to duplicate here anymore.
2015-06-13 11:41:33 +02:00
Sebastian Dröge
92fa187d11 decklinkvideosink: Don't schedule too late frames in prepare()
Otherwise we will overflow the internal buffer of the hardware
with useless frames and run into an error. This is necessary until
this bug in basesink is fixed:
https://bugzilla.gnome.org/show_bug.cgi?id=742916
2015-01-14 16:02:57 +01:00
Sebastian Dröge
7b979703f8 decklinkvideosink: Keep track of the time when we went to PLAYING for the external clock too
Otherwise we're adding an offset of the time the pipeline was in PLAYING
already to the running time when converting it to our internal clock.
2015-01-14 16:00:54 +01:00
Sebastian Dröge
9c2e09cf39 decklinkvideosink: Implement clock slaving 2014-12-19 14:40:40 +01:00
Sebastian Dröge
57d46fe9e1 decklink: Initial version of the audio/video sink rewrite 2014-12-19 14:40:39 +01:00