Commit graph

16 commits

Author SHA1 Message Date
Peter Körner
58dadd1ad0 decklink: implement duplex-mode property 2019-03-04 09:34:44 +00:00
Sebastian Dröge
c47fac42cd decklinkvideosink: Fix support for raw CEA608 input and add support for raw CEA708 input
The former was only considering the first byte pair, for the latter we
have to convert raw CEA708 cc_data into CDP.
2018-12-19 00:20:26 +02:00
Matthew Waters
59c5ae2817 decklink: calculate the decklink output time from the internal clock
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: bf849e9a69
2018-12-12 13:29:32 +11:00
Matthew Waters
d67d866eb9 decklink: fixup internal time tracking over buffering pauses
Instead of relying on buffers after a state change to PLAYING to always start
from 0, track the amount of time we have spent outside playing but not changed
state to PAUSED.
2018-11-26 17:57:45 +11:00
Sebastian Dröge
96490b83a4 decklinkvideosink: Add support for outputting closed captions 2018-11-12 14:10:03 +00:00
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