summaryrefslogtreecommitdiff
path: root/gst/timecode
AgeCommit message (Collapse)AuthorFilesLines
2018-12-20timecodestamper: Don't use deprecated APISebastian Dröge1-2/+9
2018-10-04avwait: Fix sending of dropping=true messagesVivia Nikolaidou1-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
2018-09-21avwait: Send dropping=true message after all streams stoppedVivia Nikolaidou2-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
2018-09-03timecodestamper: Fix typo in set_drop_frameVivia Nikolaidou1-1/+1
Was checking if fps_d == 60000 (instead of fps_n), causing 60000/1001 to be always falsely interpreted as non-drop-frame
2018-08-17avwait: Start video and audio together if audio starts lateVivia Nikolaidou2-14/+72
Also add test to meson https://bugzilla.gnome.org/show_bug.cgi?id=796977
2018-08-01avwait: Don't wait if audio_running_time_to_wait_for is NONEVivia Nikolaidou1-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
2018-07-24avwait: Add recording propertyVivia Nikolaidou2-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
2018-04-25Meson: Generate pc file for all plugins in badXavier Claessens1-0/+1
https://bugzilla.gnome.org/show_bug.cgi?id=794568
2018-01-04Revert "WIP: Revert "Revert "timecodestamper: LTC from audio"""Vivia Nikolaidou2-624/+44
This reverts commit e0be05dc7059cc97dceb70a48ca9cad4ee2edce6.
2018-01-04Revert "WIP: Revert "Revert "timecodestamper: Modify ltc-add to tc-add"""Vivia Nikolaidou2-12/+14
This reverts commit 2f9da0ab59ef4231e9c850afb089d920e9d25609.
2018-01-04WIP: Revert "Revert "timecodestamper: Modify ltc-add to tc-add""Vivia Nikolaidou2-14/+12
This reverts commit 05426d9298431c149807fb435cd1d632e9fd061f.
2018-01-04WIP: Revert "Revert "timecodestamper: LTC from audio""Vivia Nikolaidou2-44/+624
This reverts commit 1998ccf1fbd586ef1dc4b1e7256bad7af8136f13.
2017-12-08avwait: Added "avwait-status" element messageVivia Nikolaidou2-15/+98
"avwait-status" is posted when avwait starts or stops passing through data (e.g. because target-timecode and end-timecode respectively have been reached). The attached structure includes a "dropping" boolean (set to TRUE if we are currently dropping data, FALSE otherwise), and a "running-time" GST_CLOCK_TIME which contains the running time of the change. https://bugzilla.gnome.org/show_bug.cgi?id=790170
2017-11-14avwait: Deserialised timecodes set after caps event now get correct framerateVivia Nikolaidou1-6/+23
A deserialised timecode has a framerate of 0/1 by default. That breaks it when comparing the frames field with another timecode (incoming from the frame). We were setting the framerate when receiving the caps event, but not when setting the timecode in set_property, so it was broken for timecodes set after the caps event. Also checking if the fps_n we got from the caps event is != 0 before setting it - also at the caps event. https://bugzilla.gnome.org/show_bug.cgi?id=790334
2017-11-10timecode: Fix incorrect wording in error messageVivia Nikolaidou1-3/+3
2017-11-10avwait: Better handling of deserialised timecode frameratesVivia Nikolaidou2-6/+5
Now that timecodes support proper serialisation / deserialisation, a timecode might have an invalid fps_n / fps_d even without using the target-time-code-string property. Detect those cases and set fps_n/fps_d properly.
2017-11-07Revert "timecodestamper: LTC from audio"Vivia Nikolaidou2-624/+44
This reverts commit c01afab9f7fa7e822dea38e358e92163e8d36282. Was not ready to be pushed yet
2017-11-07Revert "timecodestamper: Modify ltc-add to tc-add"Vivia Nikolaidou2-12/+14
This reverts commit 6552981b795a024d26bf509893d55970c2294c04. Was not ready to be pushed yet
2017-11-07avwait: Fix crash when explicitly setting end_tc to NULLVivia Nikolaidou1-1/+1
If end_tc is NULL, it means that we don't want avwait to stop at any timecode. When explicitly setting end_tc to NULL, there is no point in comparing end_tc with start_tc (to see if we'll reject end_tc for being before start_tc), so the check in question is completely disabled instead of letting it crash.
2017-11-07timecodestamper: Modify ltc-add to tc-addGeorg Lippitsch2-14/+12
It is more general now and also adds TC to internal counter
2017-11-07timecodestamper: LTC from audioGeorg Lippitsch2-44/+624
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
2017-10-25avwait: Added end-timecode propertyVivia Nikolaidou2-5/+126
avwait can now be configured to stop when a given timecode has been reached. It will start at the timecode indicated with start-timecode and end at the timecode indicated with end-timecode. If end-timecode is NULL (default), the previous functionality is preserved: keep going and not end. https://bugzilla.gnome.org/show_bug.cgi?id=789403
2017-05-16Remove plugin specific static build optionNicolas Dufresne1-1/+0
Static and dynamic plugins now have the same interface. The standard --enable-static/--enable-shared toggle are sufficient.
2017-04-12docs: Port all docstring to gtk-doc markdownThibault Saunier2-6/+6
2017-03-08timecodestamper: Only unref daily jam if not NULLSebastian Dröge1-1/+2
2017-03-08timecodestamper: Unref daily jam after usageSebastian Dröge1-0/+1
2017-02-24meson: Added meson.build for audiomixmatrix and timecodeVivia Nikolaidou1-0/+14
https://bugzilla.gnome.org/show_bug.cgi?id=779154
2017-02-23timecodestamper: Remove clock-source propertyGeorg Lippitsch2-83/+0
Remove clock-source property, because the GST clock usually starts at some random value and is thus uselsess for creating a timecode from it. https://bugzilla.gnome.org/show_bug.cgi?id=778703
2017-02-23timecodestamper: First timecode from current system timeGeorg Lippitsch2-0/+36
Add a new flag which automatically sets this first timecode to the current system time in local time zone. https://bugzilla.gnome.org/show_bug.cgi?id=778703
2017-02-23timecodestamper: First timecode propertyGeorg Lippitsch2-2/+36
Add an new property to start from a given timecode instead of zero. https://bugzilla.gnome.org/show_bug.cgi?id=778703
2017-02-02avwait: Fix potential deadlock when flushing / shutting down audioVivia Nikolaidou1-0/+1
The mutex must be unlocked in the error case https://bugzilla.gnome.org/show_bug.cgi?id=778076
2017-01-26avwait: Rename timecodewait to avwait, add modesVivia Nikolaidou4-121/+234
Renamed timecodewait to avwait. Added running-time and video-first modes. Default mode is timecode (the previous behaviour). https://bugzilla.gnome.org/show_bug.cgi?id=777741
2017-01-09timecodestamper: Post element message with current timecodeVivia Nikolaidou2-5/+47
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
2016-11-24timecodestamper: Remove all existing timecode metas if requested to override ↵Sebastian Dröge1-1/+14
existing
2016-08-07hls, timecode: fix linkingxlazom001-1/+1
https://bugzilla.gnome.org//show_bug.cgi?id=769587
2016-08-04timecodewait: New element to wait for a specific timecodeVivia Nikolaidou4-5/+722
timecodewait receives a timecode as an argument (either as string or as GstVideoTimeCode - one is gst-launch-friendly and the other is code-friendly), and it will drop all audio and video buffers until that timecode has been reached. https://bugzilla.gnome.org/show_bug.cgi?id=766419
2016-08-04timecodestamper: New element to attach SMPTE timecode to buffersVivia Nikolaidou4-0/+533
The timecodestamper element attaches a SMPTE timecode to each video buffer. This timecode corresponds to the current stream time. https://bugzilla.gnome.org/show_bug.cgi?id=766419
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-18 16:48:57 +0000