- NDI HX Camera Android in the past used 1ns instead of 100ns as unit
for timecodes/timestamps.
- NDI HX Camera iOS uses 0 for all timecodes and the same non-zero
value for all audio timestamps
Detect such situations and try to compensate for them. Also add a new
"auto" timestamping mode that prefers to use timecodes and otherwise
falls back to timestamps or receive times.
Fixes https://github.com/teltek/gst-plugin-ndi/issues/79
Audio/video are in practice not always from the same clock and can have
different behaviours with regards to clock rate and jitter. Handling
them separately generally gives better results for the timestamps output
by the source element.
This is a follow-up to commit 7ee4afac.
This commit cleans up the `Pad{Sink,Src}Handler` by
- Keeping arguments which are strictly necessary.
- Passing arguments by value for the trait functions which return
a `Future`. The arguments which were previously passed by reference
were `clone`d internally and then `clone`d again in most
implementations.
There are unfortunate differences in trait function signatures
between those which return a `Future` and the sync functions. This
is due to the requirement for the arguments to be moved to the
resulting `Future`, whereas sync functions can rely on references.
One particular notable difference is the use of the `imp` in sync
functions instead of the `elem` in functions returning a `Future`.
Because the `imp` is not guaranteed to implement `Clone`, we can't
move it to the resulting `Future`, so the `elem` is used.
This is no longer available as this could lead to building a defined
value in Rust which could be interpreted as undefined in C due to
the sentinel `u64::MAX` for `None`.
Use the constants (e.g. `ONE`, `K`, `M`, ...) and operations to build
a value and deref (`*`) to get the quantity as an integer.
Refactor connect_input_stream in order to avoid an ABBA deadlock
altogether: where in other spots we lock settings then state, here we
were emitting encoder-setup with state held, then locking settings in
the default handler.
We could have changed the locking order in the other spots, but instead
we can also just release the state lock when emitting the signal, which
is good practice.
Fixes#108
Higher value might be too big (in particular with many VPNs `webrtcsink`
won't work with the default 1400 MTU).
1200 is the default value in libwebrtc and it is references in several
places there.
