gstdecklinkvideosrc.cpp:425:7: warning: format '%x' expects argument of type 'unsigned int', but argument 8 has type 'HRESULT {aka long int}' [-Wformat]
[and so on]
This is basically a frame counter provided by the driver and it's
advancing at the speed of the HDMI/SDI input. Having this available on
each buffer allows to know what constant-framerate-based timestamp each
frame is corresponding to and can be used e.g. to write out files
accordingly without having the local pipeline clock timestamps used.
https://bugzilla.gnome.org/show_bug.cgi?id=779213
This reverts commit 845832263b.
The commit broke cross-mingw CI:
https://ci.gstreamer.net/job/GStreamer-master/8659/console
It seems that cross-mingw on Autotools and native-mingw on Meson
disagree about the size of HRESULT. Revert for now till I can
investigate the Meson side of things some more.
This is basically a frame counter provided by the driver and it's
advancing at the speed of the HDMI/SDI input. Having this available on
each buffer allows to know what constant-framerate-based timestamp each
frame is corresponding to and can be used e.g. to write out files
accordingly without having the local pipeline clock timestamps used.
https://bugzilla.gnome.org/show_bug.cgi?id=779213
First of all, all the HD and UHD modes should be top-field-first, as
also returned by the Decklink mode iterator API.
Then we should include the caps field "field-order" in the caps of the
source (not the sink due to negotiation problems with optional fields).
And finally we should set the TFF flag on interlaced buffers that are
top-field-first.
On some hardware the first few frames are bogus and not very useful.
Their timestamps are off, they have no timecodes, or there are spurious
black frames / no-signal frames. After a few frames this stabilizes
though.
https://bugzilla.gnome.org/show_bug.cgi?id=774850
Based on this we calculate the actual capture time, which should get us
rid of any capturing jitter by averaging it out.
Also add a output-stream-time property which forces the elements to
output the stream time directly instead of doing any conversion to the
pipeline clock. Use with care.
https://bugzilla.gnome.org/show_bug.cgi?id=774850
The hardware timestamps have no relation to when frames were produced,
only when frames arrived somewhere in the hardware. Especially there is
no guarantee that audio and video will have the same hardware timestamps
although they belong together, and even more important: the rate with
which the hardware timestamps increase is completely unrelated to the
rate with which the frames are captured!
As such we can as well use the pipeline clock directly and stop doing
complicated calculations. Also as a side effect this allows now running
without any pipeline clock, by directly making use of the stream times
as reported by the driver.
https://bugzilla.gnome.org/show_bug.cgi?id=774850
When a frame is found to not have an associated input source (cable
unplugged, wrong mode selected), an element warning will be issued. When
the next frame in the stream is found to have an input source selected
(e.g. cable replugged), an element info will be issued.
https://bugzilla.gnome.org/show_bug.cgi?id=774629
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
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.
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.
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.
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.
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.
