Commit graph

177 commits

Author SHA1 Message Date
Vivia Nikolaidou
fafc8e564c decklinkvideosink: Made "auto" mode work according to caps
When the mode of decklinkvideosink is set to "auto", the sink claims to
support the full set of caps that it can support for all modes. Then, every
time new caps are set, the sink will automatically find the correct mode for
these caps and set it.

Caveat: We have no way to know whether a specific mode will actually work for
your hardware. Therefore, if you try sending 4K video to a 1080 screen, it
will silently fail, we have no way to know that in advance. Manually setting
that mode at least gave the user a way to double-check what they are doing.

https://bugzilla.gnome.org/show_bug.cgi?id=759600
2015-12-18 16:08:02 +01:00
Sebastian Dröge
9764e22a5c decklink: Add a clock epoch that is used as offset whenever restarting the clock
Otherwise we're going to return times starting at 0 again after shutting down
an element for a specific input/output and then using it again later.

https://bugzilla.gnome.org/show_bug.cgi?id=755426
2015-09-24 09:32:36 +02:00
Sebastian Dröge
e0fd5317df decklink: Disable inputs/outputs in PAUSED->READY to allow going to PAUSED again from there
https://bugzilla.gnome.org/show_bug.cgi?id=755426
2015-09-24 09:32:27 +02:00
Sebastian Dröge
b2149e7bb4 decklinkvideosink: less-than-zero comparison of an unsigned value is never true
Use the correct type, GstClockTimeDiff, instead.

CID 1323742
2015-09-10 14:11:58 +03:00
Sebastian Dröge
b6498c32f3 decklinkvideosink: Handle pipelines where the running time does not start around 0 properly
We were converting all times to our internal running times, that is the time
the sink itself spent in PLAYING already. But forgot to do that for the
running time calculated from the buffer timestamps. As such, all buffers were
scheduled much later if the pipeline's running time did not start at 0.

This happens for example if a base time is explicitly set on the pipeline.

https://bugzilla.gnome.org/show_bug.cgi?id=754528
2015-09-09 16:59:02 +03:00
Sebastian Dröge
a6744a915b decklinkvideosink: Consider pipeline latency, render delay and ts offset when scheduling frames
Without this, we will schedule all frames too late in live pipelines.

https://bugzilla.gnome.org/show_bug.cgi?id=754666
2015-09-09 16:58:45 +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
62f25894a5 decklinkvideosink: Don't require the same framerate in the input as the mode's framerate
We only really care about the timestamps for the sink.
2015-06-12 22:35:03 +02:00
Heinrich Fink
6007829e77 decklink: Rename mode 2048p to 1556p
https://bugzilla.gnome.org/show_bug.cgi?id=749218
2015-05-11 13:20:11 +03:00
Heinrich Fink
1dabd7c5b8 decklink: Use correct frame rate for mode 2160p50
https://bugzilla.gnome.org/show_bug.cgi?id=749218
2015-05-11 13:14:39 +03:00
Heinrich Fink
e6d82dec32 decklink: Rename mode 3184p to 2160p
https://bugzilla.gnome.org/show_bug.cgi?id=749218
2015-05-11 13:14:15 +03:00
Josep Torra
cf66541850 decklinkvideosrc: fix mode autodetection
The autodetection mode was broken because a race condition in the input mode
setting. The mode could be reverted back when it was replaced in
the streaming thread by the old mode in the middle of mode changed callback.
2015-04-22 17:20:22 +02:00
Josep Torra
6b70b848ee decklink: do not repeat first video format in caps template
The first entry in the modes array is used as default mode for autodetection.
There's no need to copy it into the caps template.
2015-04-22 17:20:21 +02:00
Sebastian Dröge
254337365a decklinkaudiosrc: Calculate the duration more accurately from the capture time and numbers of samples
This should prevent any accumulating rounding errors with the duration.
2015-03-04 16:13:30 +01:00
Sebastian Dröge
912e58c64c decklinkaudiosrc: Fix the timestamp and offset calculations even more 2015-03-04 16:07:10 +01:00
Sebastian Dröge
1f9d37c924 decklinkaudiosrc: Don't subtract the duration from the capture time
We already have the real capture time, not the time when we received
the end of the packet.
2015-03-04 16:04:18 +01:00
Sebastian Dröge
4521524de3 decklink: Reset the clock calibration when unsetting the master clock
Otherwise the old calibration will stick around for the next time we use it,
potentially giving us completely wrong times.
2015-03-02 16:45:45 +01:00
Sebastian Dröge
8e362aab14 decklink{audio,video}src: Add some more debug output 2015-03-02 13:57:24 +01:00
DanielD10
034ed48023 decklink: Incorrect frame rate for interlaced modes
https://bugzilla.gnome.org/show_bug.cgi?id=744386
2015-03-02 11:59:31 +01:00
Sebastian Dröge
72b440cc89 decklinkvideosrc: Fix scaling with rate of internal/external clock 2015-02-27 11:08:14 +02:00
Sebastian Dröge
9ed4054a94 decklinkvideosrc: Apply the diff between element and pipeline "base" time in all cases
Even if both clocks have the same rate, we need to apply this diff. Only when
it's the same clock we don't, as it's our clock then.
2015-02-10 16:01:19 +01:00
Sebastian Dröge
f83ac624e3 decklinkvideosrc: Add the diff between the pipeline base time and when we start to play
Add the diff between the external time when we went to playing and
the external time when the pipeline went to playing. Otherwise we
will always start outputting from 0 instead of the current running
time.
2015-02-10 15:30:44 +01:00
Sebastian Dröge
d4575e759b decklinkvideosink: Actually include the change mentioned in the last commit 2015-02-10 14:53:55 +01:00
Sebastian Dröge
e8167dd118 decklinkvideo{src,sink}: Sample the internal clock immediately after starting the device
Otherwise we might stay at 0.0s for too long because we will take the first
timestamp we ever see as 0.0... which will be after we started the device.
2015-02-10 14:48:09 +01:00
Sebastian Dröge
b739cf8b7f decklink: Fix compiler warning with gcc
gstdecklink.cpp: In member function 'virtual HRESULT GStreamerDecklinkInputCallback::VideoInputFrameArrived(IDeckLinkVideoInputFrame*, IDeckLinkAudioInputPacket*)':
gstdecklink.cpp:498:22: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
     if (capture_time > m_input->clock_start_time)
                      ^
gstdecklink.cpp:503:22: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
     if (capture_time > m_input->clock_offset)
                      ^
2015-02-09 21:04:17 +01:00
Sebastian Dröge
f0e85023c2 decklink{audio,video}src: Implement clock slaving if the pipeline clock is not the decklink clock 2015-02-09 17:17:37 +01:00
Sebastian Dröge
408f0870a6 decklinkaudio{src,sink}: Only start streams / scheduled playback if there is a videosrc at this point 2015-02-09 17:15:21 +01:00
Sebastian Dröge
349113d15a decklinkaudiosrc: Don't provide a clock
The audio source only works together with the video source, and the video
source is already providing a clock.
2015-02-09 17:04:27 +01:00
Sebastian Dröge
4de7fdfa3a decklinkaudiosink: Throttle reading from the ringbuffer
The driver has an internal buffer of unspecified and unconfigurable size, and
it will pull data from our ring buffer as fast as it can until that is full.
Unfortunately that means that we pull silence from the ringbuffer unless its
size is by conincidence larger than the driver's internal ringbuffer.

The good news is that it's not required to completely fill the buffer for
proper playback. So we now throttle reading from the ringbuffer whenever
the driver has buffered more than half of our ringbuffer size by waiting
on the clock for the amount of time until it has buffered less than that
again.
2015-02-09 16:22:39 +01:00
Sebastian Dröge
a6bcd09b6c decklinkaudiosink: Start scheduled playback when going to PLAYING
The ringbuffer's acquire() is too early, and ringbuffer's start() will only be
called after the clock has advanced a bit... which it won't unless we start
scheduled playback.
2015-02-09 16:22:39 +01:00
Sebastian Dröge
22b0a4dad5 decklink{audio,video}src: Take the capture times from the pipeline clock
Not from the decklink clock. Both will return exactly the same time once the
decklink clock got slaved to the pipeline clock and received the first
observation, but until then it will return bogus values. But as both return
exactly the same values, we can as well use the pipeline clock directly.
2015-02-08 21:56:04 +01:00
Sebastian Dröge
e9b49018ed decklinkvideosink: Always lock the mutex before starting the streams 2015-01-28 17:02:59 +01:00
Sebastian Dröge
837eee7085 decklinkvideosink: Fix deadlock 2015-01-28 16:59:30 +01:00
Sebastian Dröge
4eb5cd9156 decklink{audio,video}sink: Only start scheduled playback once both sources are ready and we are in PLAYING
Otherwise we might start the scheduled playback before the audio or video streams are
actually enabled, and then error out later because they are enabled to late.

We enable the streams when getting the caps, which might be *after* we were
set to PLAYING state.
2015-01-28 16:13:16 +01:00
Sebastian Dröge
e2ff5587fe decklink{audio,video}src: Only start the streams once both sources are ready and we are in PLAYING
Otherwise we might start the streams before the audio or video streams are
actually enabled, and then error out later because they are enabled to late.

We enable the streams when getting the caps, which might be *after* we were
set to PLAYING state.
2015-01-28 16:13:16 +01:00
Sebastian Dröge
00176a1ddf decklink: Make sure our clock never returns NONE, always advances and does not jump when going from PAUSED to PLAYING
It basically behaves the same as the audio clocks.
2015-01-28 16:13:16 +01:00
Sebastian Dröge
b3a4772834 decklinkvideosink: Handle the clock returning GST_CLOCK_TIME_NONE properly 2015-01-28 16:13:16 +01:00
Sebastian Dröge
8a5d2c561c decklinkvideo{sink,src}: Make elements more similar to the audio elements by enabling the video input/output only when getting the actual caps
This will also make it easier later to support caps changes and support
selecting the mode based on the caps if that should ever be implemented.
2015-01-28 16:13:16 +01:00
Sebastian Dröge
f3ae93e504 decklinkvideosrc: Properly report caps if mode!=auto and handle caps changes properly for mode=auto 2015-01-28 16:13:16 +01:00
Sebastian Dröge
7fb57938c1 decklinkaudiosrc: Don't release input device twice on errors in set_caps() 2015-01-28 16:13:16 +01:00
Sebastian Dröge
c6d5c4c2e1 decklinkaudiosrc: Release the audio input on errors, not the video input 2015-01-26 15:33:45 +01:00
Sebastian Dröge
e734c3cf13 decklinkvideosink: Also consider max-lateness property value before dropping late frames 2015-01-15 12:49:46 +01:00
Sebastian Dröge
5a12b2670e decklinkvideosink: Stop scheduled playback shortly in PAUSED->PLAYING if it was running already
This fixes handling of flushing seeks, where we will get a PAUSED->PLAYING
state transition after the previous one without actually going to PAUSED
first.
2015-01-14 16:33:53 +01: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
aed66838f3 decklinkvideosink: Enable QoS and set max-lateness to 20ms 2015-01-14 13:33:15 +01:00
Sebastian Dröge
ab9ee34aba decklink: Use BT2020 colorspace for UltraHD resolutions 2015-01-13 19:56:45 +01:00
Sebastian Dröge
65119ae8b4 decklink: Fix indention once again 2015-01-13 19:56:45 +01:00
Sebastian Dröge
d2e309d341 decklinkvideosink: Get our own "start time" instead of the one of the pipeline
decklinkvideosink might be added later to the pipeline, or its state might
be handled separately from the pipeline. In which case the running time when
we (last) went into PLAYING state will be different from the pipeline's.

However we need our own start time to tell the Decklink API, which running
time should be displayed at the moment we go to PLAYING and start scheduled
rendering.
2015-01-13 17:44:17 +01:00
Sebastian Dröge
b79ece392c decklink: Initialize refcount of our C++ classes in the constructor
CID 1262288
CID 1262287
CID 1262289
2015-01-12 15:58:38 +01:00