Calculate the optimal latency value for NDI source elements.

[rubenrua]

Currently a constant value is used.

See latency branch to use latency as a parameter and test the source elements with it.

[pitfisher]

Hello! I tried the latency branch and I've got the following behavior: playback is very slow because most of frames are dropped, and every time new frame is shown the console output is the following:

WARNING: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2902): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage:
There may be a timestamping problem, or this computer is too slow.

I tried do-timestamp property and different values for latency but gained no effect.
It is unlikely that this behavior is related only to my testbed hardware since elements built from master branch work just fine by default. But just in case:
Transmitter:
Windows 10, vMix with NDI Output set up.
Receiver:
Ubuntu 18.04 LTS, GStreamer 1.14.4.
Both rigs have CPU Intel Core i7-3770, network is Ethernet Gigabit.
So I have two questions: 1) Can this issue be resolved with changing default element properties? 2) Will latency property be included into master branch version of the element? As for now, I have about 200ms delay on my testbed, and I wonder if this could be advanced (which is why I tried to use latency branch version of the plugin).
Any help would be appreciated!

[sdroege]

This should be fixed with #34

If timestamp-mode timestamp or timecode is used instead of the default receive-time, then it's the application's job to ensure correct latency configuration as there's simply no information available to use to get this right.

[sdroege]

@rubenrua this can be closed