summaryrefslogtreecommitdiff
path: root/gst/timecode
Commit message (Collapse)AuthorAgeFilesLines
* avwait: Don't reset time tracking when receiving the same segment againSebastian Dröge2021-03-301-13/+29
| | | | | | | | 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>
* avwait: Don't post messages with the mutex lockedSebastian Dröge2021-03-091-41/+91
| | | | Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2063>
* plugins: uddate gst_type_mark_as_plugin_api() callsMathieu Duponchelle2020-06-062-3/+3
|
* plugins: Use gst_type_mark_as_plugin_api() for all non-element plugin typesSebastian Dröge2020-06-042-0/+5
|
* timecodestamper: Unref latency query after usageSebastian Dröge2020-05-061-0/+2
| | | | Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1249>
* timecodestamper: Plug a leakThibault Saunier2020-03-111-0/+3
|
* timecodestamper: Add seeking supportThibault Saunier2020-03-042-5/+81
| | | | | | | | | 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.
* timecodestamper: Add property to set the extra latency to introduce for ↵Sebastian Dröge2020-01-132-10/+25
| | | | | | | waiting for LTC timecodes Default to 150ms instead of 8 frames, which seems to work in the majority of cases.
* timecodestamper: Add some more debug outputSebastian Dröge2020-01-131-2/+16
|
* timecodestamper: Skip over invalid LTC timecodes immediatelySebastian Dröge2020-01-101-12/+15
|
* timecodestamper: Clean up old LTC timecodes on LTC discontinuitySebastian Dröge2020-01-101-5/+26
| | | | | | 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.
* timecodestamper: Fix waiting for the first video frame in case of live video ↵Sebastian Dröge2020-01-101-5/+11
| | | | input
* timecodestamper: Fix up handling/queueing of LTC timecodesSebastian Dröge2020-01-102-157/+181
| | | | | | | | 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.
* timecodestamper: Only allow requesting LTC audio pad in NULL/READY statesSebastian Dröge2020-01-101-2/+10
| | | | | And don't introduce any latency at all if not LTC audio pad was requested.
* timecodestamper: In live mode wait correctly for the latency to passSebastian Dröge2020-01-101-5/+12
| | | | | | 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.
* timecodestamper: Use the internal LTC timecode tracker instead of the last ↵Sebastian Dröge2020-01-101-2/+2
| | | | | | | 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.
* timecodestamper: Refactor LTC audio waiting and properly handle live inputsSebastian Dröge2019-12-302-16/+230
| | | | | | | | | | | | | 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.
* timecodestamper: Create LTC sink pad with the correct name according to the ↵Sebastian Dröge2019-11-191-1/+1
| | | | | | template Should be "ltc_sink" and not just "ltc"
* timecodestamper: Add properties to time out cached upstream/LTC timecodes ↵Sebastian Dröge2019-10-232-10/+82
| | | | | | | after a while By default we never time them out and simply continue couting up with each frame forever.
* timecodestamper: Add new auto-resync boolean propertySebastian Dröge2019-10-232-5/+21
| | | | | | 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.
* timecodestamper: Add last-known-or-zero modeSebastian Dröge2019-10-232-0/+11
| | | | | | | | 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.
* timecodestamper: Don't initialize upstream timecode with zero if none was seenSebastian Dröge2019-10-231-9/+9
| | | | | Instead keep it unset and use the internal timecode wherever needed as fallback.
* timecodestamper: Update set-tc property documentation with latest version of ↵Sebastian Dröge2019-10-231-2/+2
| | | | reality
* Remove autotools build systemTim-Philipp Müller2019-10-141-9/+0
|
* timecodestamper: Require a non-0/1 framerate on the pad templatesSebastian Dröge2019-08-061-2/+2
| | | | | | 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.
* avwait: Improve debug output a bitSebastian Dröge2019-08-061-0/+6
|
* timecodestamper: Validate LTC timestamps before trying to use themSebastian Dröge2019-07-251-4/+11
| | | | | | 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.
* avwait: In running-time mode, select start/end running time based on the ↵Sebastian Dröge2019-07-121-65/+65
| | | | | | | 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.
* avwait: Add some more debug outputSebastian Dröge2019-07-121-5/+13
|
* avwait: Fix clipping of audio buffers at the start of recordingSebastian Dröge2019-07-121-2/+16
|
* timecodestamper: Add support for linear timecode (LTC) from an audio streamSebastian Dröge2019-07-083-1/+785
| | | | | | | | Based on a patch by Georg Lippitsch <glippitsch@toolsonair.com> Vivia Nikolaidou <vivia@toolsonair.com> Using libltc from https://github.com/x42/libltc
* timecodestamper: Rewrite element API and code flowSebastian Dröge2019-07-083-182/+608
| | | | | | | | | | | | | 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.
* avwait: Make sure to never unref an input buffer we already unreffed beforeSebastian Dröge2019-06-241-6/+14
|
* avwait: Add support for setting an end running timeSebastian Dröge2019-06-242-4/+52
| | | | | It was possible to set a start running time and start/end timecode before, but not an end running time.
* avwait: Correctly stop recording and signal recording stop on EOSSebastian Dröge2019-06-241-5/+50
| | | | | | | | | 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.
* avwait: Allow start and end timecode to be set back to NULLSebastian Dröge2019-06-051-3/+5
| | | | And check everywhere if they're NULL before accessing them.
* avwait: Don't print warnings for every buffer passedVivia Nikolaidou2019-05-311-2/+2
|
* avwait: Protect properties and some other code with the mutexSebastian Dröge2019-05-241-2/+30
| | | | | | These variables are all accessed from multiple threads. Also fix some minor leaks in error code paths.
* avwait: Insert some empty lines to give the code some space to breathSebastian Dröge2019-05-241-1/+17
|
* avwait: Allow setting start timecode after end timecode and the other way aroundSebastian Dröge2019-05-241-57/+30
| | | | | | 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.
* docs: Build documentation with hotdocThibault Saunier2019-05-131-0/+1
|
* timecodestamper: Don't use deprecated APISebastian Dröge2018-12-201-2/+9
|
* avwait: Fix sending of dropping=true messagesVivia Nikolaidou2018-10-041-0/+6
| | | | | | | | | 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
* avwait: Send dropping=true message after all streams stoppedVivia Nikolaidou2018-09-212-11/+77
| | | | | | | | | | | 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
* timecodestamper: Fix typo in set_drop_frameVivia Nikolaidou2018-09-031-1/+1
| | | | | Was checking if fps_d == 60000 (instead of fps_n), causing 60000/1001 to be always falsely interpreted as non-drop-frame
* avwait: Start video and audio together if audio starts lateVivia Nikolaidou2018-08-172-14/+72
| | | | | | Also add test to meson https://bugzilla.gnome.org/show_bug.cgi?id=796977
* avwait: Don't wait if audio_running_time_to_wait_for is NONEVivia Nikolaidou2018-08-011-12/+2
| | | | | | | | 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
* avwait: Add recording propertyVivia Nikolaidou2018-07-242-40/+164
| | | | | | | | 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
* Meson: Generate pc file for all plugins in badXavier Claessens2018-04-251-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794568
* Revert "WIP: Revert "Revert "timecodestamper: LTC from audio"""Vivia Nikolaidou2018-01-042-624/+44
| | | | This reverts commit e0be05dc7059cc97dceb70a48ca9cad4ee2edce6.
View Lorry Controller Status