summaryrefslogtreecommitdiff
path: root/sys/decklink
Commit message (Collapse)AuthorAgeFilesLines
* decklink: Initialize capture_time to NONE so it can be used if no video ↵Sebastian Dröge2016-04-081-1/+1
| | | | | | frame is provided but audio is CID 1358390
* decklinkaudiosrc: Don't accept packets without timestamps after a discontSebastian Dröge2016-04-051-1/+10
| | | | | | | | | We have no idea which timestamps they are supposed to have so the only thing we can do at this point is to drop them. Packets without timestamps happen if audio was captured but no corresponding video, which shouldn't happen under normal circumstances. https://bugzilla.gnome.org/show_bug.cgi?id=747633
* decklinkaudiosrc: Don't crash when receiving video frames but no audioSebastian Dröge2016-04-053-7/+16
| | | | | | And mark these events as disconts to reset time tracking in the audio source. https://bugzilla.gnome.org/show_bug.cgi?id=747633
* decklinkvideosrc: don't crash if we get NULL video frames in the callbackTim-Philipp Müller2016-04-051-1/+6
| | | | | | | For some reason we seem to sometimes get NULL video_frames in the ::VideoInputFrameArrived() callback, observed on Intensity Pro cards. https://bugzilla.gnome.org/show_bug.cgi?id=747633
* bad: use new gst_element_class_add_static_pad_template()Vineeth TM2016-03-242-4/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=763081
* decklinkaudiosrc: Fix discont trackingJan Schmidt2016-02-041-1/+2
| | | | | Don't reset the marker that's tracking disconts until either the discont disappears or we resync.
* decklinkvideosrc: implement RGB capture supportJulien Moutte2016-01-225-23/+63
| | | | | | Combine mode and format to generate caps and support the flags from VideoChanged callback to support RGB capture. https://bugzilla.gnome.org/show_bug.cgi?id=760594
* decklinkvideosink: Made "auto" mode work according to capsVivia Nikolaidou2015-12-184-5/+36
| | | | | | | | | | | | | | 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
* decklink: Add a clock epoch that is used as offset whenever restarting the clockSebastian Dröge2015-09-244-2/+10
| | | | | | | 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
* decklink: Disable inputs/outputs in PAUSED->READY to allow going to PAUSED ↵Sebastian Dröge2015-09-243-21/+72
| | | | | | again from there https://bugzilla.gnome.org/show_bug.cgi?id=755426
* decklinkvideosink: less-than-zero comparison of an unsigned value is never trueSebastian Dröge2015-09-101-2/+3
| | | | | | Use the correct type, GstClockTimeDiff, instead. CID 1323742
* decklinkvideosink: Handle pipelines where the running time does not start ↵Sebastian Dröge2015-09-091-4/+26
| | | | | | | | | | | | | 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
* decklinkvideosink: Consider pipeline latency, render delay and ts offset ↵Sebastian Dröge2015-09-091-0/+23
| | | | | | | | when scheduling frames Without this, we will schedule all frames too late in live pipelines. https://bugzilla.gnome.org/show_bug.cgi?id=754666
* decklinkvideosink: Remove late frame-dropping workaround for basesink bugSebastian Dröge2015-06-132-44/+0
| | | | | This was fixed by https://bugzilla.gnome.org/show_bug.cgi?id=749258 in basesink, and is not necessary to duplicate here anymore.
* decklinkvideosink: Don't require the same framerate in the input as the ↵Sebastian Dröge2015-06-121-0/+17
| | | | | | mode's framerate We only really care about the timestamps for the sink.
* decklink: Rename mode 2048p to 1556pHeinrich Fink2015-05-112-9/+9
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=749218
* decklink: Use correct frame rate for mode 2160p50Heinrich Fink2015-05-111-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=749218
* decklink: Rename mode 3184p to 2160pHeinrich Fink2015-05-112-25/+25
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=749218
* decklinkvideosrc: fix mode autodetectionJosep Torra2015-04-221-5/+6
| | | | | | 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.
* decklink: do not repeat first video format in caps templateJosep Torra2015-04-221-1/+1
| | | | | 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.
* decklinkaudiosrc: Calculate the duration more accurately from the capture ↵Sebastian Dröge2015-03-041-4/+7
| | | | | | time and numbers of samples This should prevent any accumulating rounding errors with the duration.
* decklinkaudiosrc: Fix the timestamp and offset calculations even moreSebastian Dröge2015-03-041-6/+3
|
* decklinkaudiosrc: Don't subtract the duration from the capture timeSebastian Dröge2015-03-041-6/+3
| | | | | We already have the real capture time, not the time when we received the end of the packet.
* decklink: Reset the clock calibration when unsetting the master clockSebastian Dröge2015-03-022-0/+4
| | | | | Otherwise the old calibration will stick around for the next time we use it, potentially giving us completely wrong times.
* decklink{audio,video}src: Add some more debug outputSebastian Dröge2015-03-022-0/+14
|
* decklink: Incorrect frame rate for interlaced modesDanielD102015-03-021-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=744386
* decklinkvideosrc: Fix scaling with rate of internal/external clockSebastian Dröge2015-02-271-2/+2
|
* decklinkvideosrc: Apply the diff between element and pipeline "base" time in ↵Sebastian Dröge2015-02-101-12/+13
| | | | | | | 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.
* decklinkvideosrc: Add the diff between the pipeline base time and when we ↵Sebastian Dröge2015-02-101-0/+12
| | | | | | | | | 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.
* decklinkvideosink: Actually include the change mentioned in the last commitSebastian Dröge2015-02-101-0/+12
|
* decklinkvideo{src,sink}: Sample the internal clock immediately after ↵Sebastian Dröge2015-02-101-9/+10
| | | | | | | 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.
* decklink: Fix compiler warning with gccSebastian Dröge2015-02-091-2/+2
| | | | | | | | | | 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) ^
* decklink{audio,video}src: Implement clock slaving if the pipeline clock is ↵Sebastian Dröge2015-02-095-55/+161
| | | | not the decklink clock
* decklinkaudio{src,sink}: Only start streams / scheduled playback if there is ↵Sebastian Dröge2015-02-092-4/+4
| | | | a videosrc at this point
* decklinkaudiosrc: Don't provide a clockSebastian Dröge2015-02-091-20/+0
| | | | | The audio source only works together with the video source, and the video source is already providing a clock.
* decklinkaudiosink: Throttle reading from the ringbufferSebastian Dröge2015-02-091-0/+60
| | | | | | | | | | | | | 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.
* decklinkaudiosink: Start scheduled playback when going to PLAYINGSebastian Dröge2015-02-091-6/+35
| | | | | | 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.
* decklink{audio,video}src: Take the capture times from the pipeline clockSebastian Dröge2015-02-084-43/+61
| | | | | | | 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.
* decklinkvideosink: Always lock the mutex before starting the streamsSebastian Dröge2015-01-281-0/+2
|
* decklinkvideosink: Fix deadlockSebastian Dröge2015-01-281-2/+8
|
* decklink{audio,video}sink: Only start scheduled playback once both sources ↵Sebastian Dröge2015-01-284-62/+89
| | | | | | | | | | 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.
* decklink{audio,video}src: Only start the streams once both sources are ready ↵Sebastian Dröge2015-01-283-14/+38
| | | | | | | | | | 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.
* decklink: Make sure our clock never returns NONE, always advances and does ↵Sebastian Dröge2015-01-286-23/+162
| | | | | | not jump when going from PAUSED to PLAYING It basically behaves the same as the audio clocks.
* decklinkvideosink: Handle the clock returning GST_CLOCK_TIME_NONE properlySebastian Dröge2015-01-281-4/+6
|
* decklinkvideo{sink,src}: Make elements more similar to the audio elements by ↵Sebastian Dröge2015-01-282-163/+210
| | | | | | | 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.
* decklinkvideosrc: Properly report caps if mode!=auto and handle caps changes ↵Sebastian Dröge2015-01-281-5/+24
| | | | properly for mode=auto
* decklinkaudiosrc: Don't release input device twice on errors in set_caps()Sebastian Dröge2015-01-281-2/+0
|
* decklinkaudiosrc: Release the audio input on errors, not the video inputSebastian Dröge2015-01-261-1/+1
|
* decklinkvideosink: Also consider max-lateness property value before dropping ↵Sebastian Dröge2015-01-151-2/+4
| | | | late frames
* decklinkvideosink: Stop scheduled playback shortly in PAUSED->PLAYING if it ↵Sebastian Dröge2015-01-141-1/+15
| | | | | | | | 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.
View Lorry Controller Status