This allows selecting whether we continue updating our last known
upstream timecode whenever a new one arrives or instead only keep the
last known one and from there on count up.
This uses the last known upstream timecode (counted up per frame), or
otherwise zero if none was known.
The normal last-known timestamp uses the internal timecode as fallback
if no upstream timecode was ever known.
We reject caps with other framerates as it's impossible to generate
timecodes unless we actually know a constant framerate. Reflect this
also in the pad template caps.
There's no point in working with invalid LTC timestamps as all future
calculations will be wrong based on this, and invalid LTC timestamps can
sometimes be read via the audio input.
Based on a patch by
Georg Lippitsch <glippitsch@toolsonair.com>
Vivia Nikolaidou <vivia@toolsonair.com>
Using libltc from https://github.com/x42/libltc
We now have a single property to select the timecode source that should
be applied, and for each timecode source the timecode is updated at
every frame. Then based on a set mode, the timecode is added to the
frame if none exists already or all existing timecodes are removed and
the timecode is added.
In addition the real-time clock is considered a proper timecode source
now instead of only allowing to initialize once in the beginning with
it, and also instead of just taking the current time we now take the
current time at the clock time of the video frame.
Add support for parsing linear time code from
an audio source using libltc
https://github.com/x42/libltc
The user can now choose between 3 different and independently
running timecode sources. The old override-existing property
has been replaced by timecode-source.
https://bugzilla.gnome.org/show_bug.cgi?id=784295
timecodestamper will post an element message which contains the current
timecode it just stamped. If a timecode was already found and not
replaced, it will still post it in a message.
https://bugzilla.gnome.org/show_bug.cgi?id=777048
