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
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.
The decklink driver eventually crashes after repeated creation/deletion
of device, input, output, and configuration objects. Change to create
these at the outset and keep them around forever.
Builds with MSVC, not tested in MinGW or anything else. Added
COM handling code, borrowed from dshowvideosink. Moved Linux
specific files to ./linux and added Windows specific files to
./win (generated from IDL files in VS9). Added macros to handle
BSTR and defined bool as BOOL. Fixes#655362.
Signed-off-by: David Schleef <ds@schleef.org>
