Commit graph

78 commits

Author SHA1 Message Date
Sebastian Dröge
5bcfb2dda0 avwait: Don't reset time tracking when receiving the same segment again
This causes avwait to go back into "dropping" mode until audio and video
are synced again, which is unnecessary when the segment didn't actually
change.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2121>
2021-03-30 08:38:03 +00:00
Sebastian Dröge
80c1722cba avwait: Don't post messages with the mutex locked
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2063>
2021-03-09 13:01:45 +02:00
Mathieu Duponchelle
a048ce81d4 plugins: uddate gst_type_mark_as_plugin_api() calls 2020-06-06 00:40:42 +02:00
Sebastian Dröge
74f2f733be plugins: Use gst_type_mark_as_plugin_api() for all non-element plugin types 2020-06-04 13:33:16 -04:00
Sebastian Dröge
0dfd05e574 timecodestamper: Unref latency query after usage
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1249>
2020-05-06 20:05:06 +03:00
Thibault Saunier
fb888dada1 timecodestamper: Plug a leak 2020-03-11 21:38:13 -03:00
Thibault Saunier
a0423ee20f timecodestamper: Add seeking support
The approach is quite simple and doesn't take all use cases into account,
it only implements support when we are using the internal timecode we
create ourself.

Also the way we compute the sought frame count is naive, but it works
for simple cases.
2020-03-04 12:36:45 +00:00
Sebastian Dröge
f72aaed9c7 timecodestamper: Add property to set the extra latency to introduce for waiting for LTC timecodes
Default to 150ms instead of 8 frames, which seems to work in the
majority of cases.
2020-01-13 18:17:23 +00:00
Sebastian Dröge
fdca7ebb4c timecodestamper: Add some more debug output 2020-01-13 18:17:23 +00:00
Sebastian Dröge
a4c925f694 timecodestamper: Skip over invalid LTC timecodes immediately 2020-01-10 15:59:27 +02:00
Sebastian Dröge
a1443518e0 timecodestamper: Clean up old LTC timecodes on LTC discontinuity
We might have some old timecodes that are in the future now and have to
drop those to make sure that our queue is correctly ordered and we don't
have multiple timecodes for the same running time.
2020-01-10 15:59:26 +02:00
Sebastian Dröge
bbdb392abe timecodestamper: Fix waiting for the first video frame in case of live video input 2020-01-10 15:59:25 +02:00
Sebastian Dröge
d7bb5b8a16 timecodestamper: Fix up handling/queueing of LTC timecodes
Directly read them out of the decoder as soon as we passed audio and
then store them in a queue that we handle internally together with their
timestamps. This cleans up memory management and gives us proper control
over the queue instead of guessing how the queue inside the LTC decoder
actually works and when it overflows.
2020-01-10 15:59:24 +02:00
Sebastian Dröge
0a53f6560a timecodestamper: Only allow requesting LTC audio pad in NULL/READY states
And don't introduce any latency at all if not LTC audio pad was
requested.
2020-01-10 15:59:21 +02:00
Sebastian Dröge
0a499242e9 timecodestamper: In live mode wait correctly for the latency to pass
And also introduce 6 instead of 2 frames of latency compared to the LTC
audio input as that seems to be an upper bound for how much the LTC
library is lagging behind.
2020-01-10 15:58:29 +02:00
Sebastian Dröge
31d7862051 timecodestamper: Use the internal LTC timecode tracker instead of the last one we retrieved
Otherwise we don't interpolate between LTC timecodes but only ever put
an LTC timecode on buffers once we actually received one.
2020-01-10 15:58:06 +02:00
Sebastian Dröge
0dc783d719 timecodestamper: Refactor LTC audio waiting and properly handle live inputs
If one of the inputs is live, add a latency of 2 frames to the video
stream and wait on the clock for that much time to pass to allow for the
LTC audio to be ahead.

In case of live LTC, don't do any waiting but only ensure that we don't
overflow the LTC queue.

Also in non-live LTC audio mode, flush too old items from the LTC queue
if the video is actually ahead instead of potentially waiting forever.
This could've happened if there was a bigger gap in the video stream.
2019-12-30 09:36:23 +00:00
Sebastian Dröge
c7393af0bf timecodestamper: Create LTC sink pad with the correct name according to the template
Should be "ltc_sink" and not just "ltc"
2019-11-19 12:21:30 +02:00
Sebastian Dröge
5a9541caff timecodestamper: Add properties to time out cached upstream/LTC timecodes after a while
By default we never time them out and simply continue couting up with
each frame forever.
2019-10-23 16:48:26 +03:00
Sebastian Dröge
fc463b9ebc timecodestamper: Add new auto-resync boolean property
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.
2019-10-23 16:48:26 +03:00
Sebastian Dröge
96aa9b5633 timecodestamper: Add last-known-or-zero mode
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.
2019-10-23 16:48:26 +03:00
Sebastian Dröge
b57687a772 timecodestamper: Don't initialize upstream timecode with zero if none was seen
Instead keep it unset and use the internal timecode wherever needed as
fallback.
2019-10-23 16:48:26 +03:00
Sebastian Dröge
faffeaf839 timecodestamper: Update set-tc property documentation with latest version of reality 2019-10-23 16:48:26 +03:00
Tim-Philipp Müller
f218ec2794 Remove autotools build system 2019-10-14 13:54:27 +01:00
Sebastian Dröge
5002efbf8d timecodestamper: Require a non-0/1 framerate on the pad templates
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.
2019-08-06 16:22:27 +00:00
Sebastian Dröge
2386385822 avwait: Improve debug output a bit 2019-08-06 16:22:27 +00:00
Sebastian Dröge
aafda1c76f timecodestamper: Validate LTC timestamps before trying to use them
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.
2019-07-25 18:27:30 +03:00
Sebastian Dröge
5c324cebb9 avwait: In running-time mode, select start/end running time based on the actual video timestamps
Otherwise we would start/end at exactly the given times, which might be
up to 1 frame earlier/later than the video.
2019-07-12 12:54:02 +03:00
Sebastian Dröge
3863a356cb avwait: Add some more debug output 2019-07-12 12:54:02 +03:00
Sebastian Dröge
407f311f2c avwait: Fix clipping of audio buffers at the start of recording 2019-07-12 12:54:02 +03:00
Sebastian Dröge
6ea4557271 timecodestamper: Add support for linear timecode (LTC) from an audio stream
Based on a patch by
  Georg Lippitsch <glippitsch@toolsonair.com>
  Vivia Nikolaidou <vivia@toolsonair.com>

Using libltc from https://github.com/x42/libltc
2019-07-08 16:45:12 +00:00
Sebastian Dröge
678064d603 timecodestamper: Rewrite element API and code flow
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.
2019-07-08 16:45:12 +00:00
Sebastian Dröge
934d0fcdd3 avwait: Make sure to never unref an input buffer we already unreffed before 2019-06-24 14:20:54 +03:00
Sebastian Dröge
cf35802c52 avwait: Add support for setting an end running time
It was possible to set a start running time and start/end timecode
before, but not an end running time.
2019-06-24 14:20:54 +03:00
Sebastian Dröge
074df2f4bc avwait: Correctly stop recording and signal recording stop on EOS
If recording is set to FALSE after the last audio or video buffer and
before the EOS event then recording stop is never signalled.

Similarly, we should signal recording stop once both audio and video are
EOS, regardless of the recording property, as there's nothing to be
recorded anymore.
2019-06-24 07:56:04 +00:00
Sebastian Dröge
7117ba0a53 avwait: Allow start and end timecode to be set back to NULL
And check everywhere if they're NULL before accessing them.
2019-06-05 11:47:36 +03:00
Vivia Nikolaidou
50075616f2 avwait: Don't print warnings for every buffer passed 2019-05-31 18:47:03 +03:00
Sebastian Dröge
1c712ca555 avwait: Protect properties and some other code with the mutex
These variables are all accessed from multiple threads.

Also fix some minor leaks in error code paths.
2019-05-24 10:41:35 +00:00
Sebastian Dröge
d55dda6252 avwait: Insert some empty lines to give the code some space to breath 2019-05-24 10:41:35 +00:00
Sebastian Dröge
c8876a37ba avwait: Allow setting start timecode after end timecode and the other way around
This might be necessary temporarily for changing the previous settings.
Make it an actual error if the settings are like this while processing a
buffer.
2019-05-24 10:41:35 +00:00
Thibault Saunier
47a49f3381 docs: Build documentation with hotdoc 2019-05-13 17:00:00 -04:00
Sebastian Dröge
3891bf2695 timecodestamper: Don't use deprecated API 2018-12-20 10:13:45 +02:00
Vivia Nikolaidou
d89104c57f avwait: Fix sending of dropping=true messages
If the first audio buffer to be dropped started right between two video
buffers (after the end of the first but before the start of the second,
as is often the case with N/1001 video frame rates), we would miss
sending the dropping=true message.

https://bugzilla.gnome.org/show_bug.cgi?id=797248
2018-10-04 12:40:45 +03:00
Vivia Nikolaidou
b1b4a04338 avwait: Send dropping=true message after all streams stopped
Previously it was dispatched before the last video buffer, and audio
buffers would follow afterwards. It's misleading to send the
dropping=true message before both streams have really stopped, it can
lead to races when someone is e.g. waiting for that message to send EOS.

Also added some debug output.

https://bugzilla.gnome.org/show_bug.cgi?id=797145
2018-09-21 17:31:25 +03:00
Vivia Nikolaidou
ae7ecfceed timecodestamper: Fix typo in set_drop_frame
Was checking if fps_d == 60000 (instead of fps_n), causing 60000/1001 to
be always falsely interpreted as non-drop-frame
2018-09-03 15:15:45 +03:00
Vivia Nikolaidou
ff952374b5 avwait: Start video and audio together if audio starts late
Also add test to meson

https://bugzilla.gnome.org/show_bug.cgi?id=796977
2018-08-17 14:57:36 +03:00
Vivia Nikolaidou
8ede252a8a avwait: Don't wait if audio_running_time_to_wait_for is NONE
The case is properly handled a few lines below by dropping the buffer.
We shouldn't perpetually block the audio chain function until the
target-timecode is reached.

https://bugzilla.gnome.org/show_bug.cgi?id=796906
2018-08-01 20:18:19 +03:00
Vivia Nikolaidou
854baf4fdb avwait: Add recording property
It works like a valve in front of the actual avwait. When recording ==
TRUE, other rules are then examined. When recording == FALSE, nothing is
passing through.

https://bugzilla.gnome.org/show_bug.cgi?id=796836
2018-07-24 13:20:59 +03:00
Xavier Claessens
83d0623293 Meson: Generate pc file for all plugins in bad
https://bugzilla.gnome.org/show_bug.cgi?id=794568
2018-04-25 11:08:09 +01:00
Vivia Nikolaidou
f042e57d4e Revert "WIP: Revert "Revert "timecodestamper: LTC from audio"""
This reverts commit e0be05dc70.
2018-01-04 15:41:49 +02:00