Also fixes peak indicators *not* resetting when muting via track header (they only got reset when using mute buttons of the Mixer)
Regression introduced in 25.08.0 compared to 25.04.3 and earlier
On my system (Arch Linux, Qt 6.9.1 KDE Frameworks 6.17.0) the Clip Properties Panel looks like this:
I assume this not always looked like this so maybe this is a Breeze or Qt bug?
I found a workaround by overwriting the style sheet for QTabBar, this is how it looks then:
Another Alternative would be to set DocumentMode to false then these ugly gray overlays will not be shown either. Then it would look like this on my system:
I tested 24.12 AppImage and get the same result so it's probably not a recent change/bug in Breeze/Qt)
The docs about QTabBar DocumentMode mention MacOS so maybe this is specific to Linux? 🤔 Can you check if you can reproduce this issue on Windows/MacOS?
AFAIK it did not have any negative effects except spamming the logs with
```
QMetaObject::invokeMethod: No such method ClipMonitor_QMLTYPE_80::updatePoints(QVariant,QVariant)
```
This became apparent when using built-in effects which adds a disabled transform effect to all clips.
This bug was introduced in b8ffac30 but I don't remember or understand why I wanted to force this update even if the effect is disabled... This commit reverts this change and removes the hasRotation condition.
This bug happened when loading a project that uses subtitles and has subs on lower layers (not 0).
In this case all subs are visually shown at the top (layer 0) even though they should be shown in lower layers.
* Replace neon green filled square with Save icon. The icon should hopefully make it more self-explanatory what this indicator is for. The neon green didn't fit well in with the rest of the themes color palette and was a bit too distracting I think
* Adjust background color, which was same as the Layout Switcher with a similar but slightly different color and only show it when the icon is shown. Previously, when the indicator was not showing it looked a bit off as there was now visually a larger gap on the left side of the switcher compared to its right
SVT-AV1 code uses the ffmpeg option `crf` to set set the rate factor for
VBR and constrained VBR mode, rather than `qscale`.
Preserve custom quality scale when editing presets.
BUG: 492708
* Fixes#2033
* Make position, Size, Rotation text overlays more readable by flipping the text on high rotation angles
* Keep rotation angles between -360 and + 360 degrees so it matches the range that's used for the rotation parameter in the Transform effect in the Effects Panel
* Adjust Resize corner and edge handles cursor shape depending on rotation handle so they point roughly in the correct correction (e.g. if rotated by 90 deg the top edge handle visually becomes the right edge handle)
* When resizing with rotation keep the rectangle in its position by aligning/moving it after resize so it lines up with its rotated position (e.g. 45deg rotation and user pulls bottom-left corner we keep the rectangle fixed to it's top-right corner)
* Enable antialiasing for drawing the red Rectangle so it looks smoother when rotated
* Fix circular updates Monitor -> cpp -> Monitor when resizing, moving, rotation via Monitor. There was - I assume - a partial fix for this in the code `updateEffectRect` called via Monitor/cpp but it didn't work and was spamming `QMetaObject::invokeMethod: No such method QQuickItem_QML_317::updateEffectRect(QRect)`. Implemented a different approach where the QML side ignores updates from cpp while it is in a moving, resizing or rotation operation.
We've been using Link color instead of highlight. For default breeze theme that's practically the same color but for other non-bluish themes this looked out of place as Link color is blue in all tested themes but we're using Highlight color in all other places to highlight text/icons.
* Fix spin box non-neutral value not getting styled when initially set (worked only if changed by user but not on initial project loading) -> Extracted this logic into a custom class so it cannot be forgotten to update the style after updating the value
* Fix not updating neutral value of the spinbox when switching to recording mode (we only updated the slider neutral value position)
BUG: 465766
* the minimum height of the subtitle edit widget was reduced in bug 506899 by JBM.
* tested the 5 default layouts and they now fit a screen with a low resolution of 1280x720
BUG: 503985
Fixes adding results twice producing garbage transcription results. E.g. on the small-en-us model it would produce lots of 'the' subtitles as reported in the linked bug report.
* fix: repaint background on initial palette change (Widget background was drawn using default/light theme not using the selected theme -> replaced our custom event (which is only fired on manual theme change) with Qt default PaletteChange event)
* fix: use correct bottom position when drawing the bars (was off-by-one)
* change: make style consistent with color scopes (background, border and line colors)
* change: draw vertical lines at frequency label position
* change: use white instead of green color for the bars. I think this could avoid confusion as this green color is also used for the first audio channel when drawing the Audio Thumbnails so it could indicate that the Audio Spectrum is showing only the first channel of the Audio. I checked the fft filter in MLT and it uses the average of all channels so probably better to avoid green (channel color) here and go with a more neutral fill color.
* removed custom greenish/reddish background color for audio tracks (doesn't work well with most color themes, especially our default breeze as its using blue accents)
* use same background color for video and audio tracks (I think the difference in track headers is enough so we don't need another visual clue here and reduce a potential distraction)
* replaced timeline focus from highlighted top border to highlighted timecode in Timeline toolbar similar to what we do with highlighting the Monitors. This reduces the visual overload as the previous highlight line is very close to the multiple other highlight lines from the widget tab groups above (at least if the user did not change their tabs from bottom to top positioning)
* changed the track settings / timeline toolbar settings icon to a good'ol hamburger menu icon. This is more consistent with menus in other widgets, also the previously used settings icon looks very similar to the Audio Mixer button
* fix: update Monitor Timecode and ToolMessage of the MainWindow after user changed the color scheme and redraw them using new colors
* fix: use palette text color for I/Q and HUD text (text was not visible on light themes)
* fix use palette dark color for circle border on light themes (border was barely visible on light themes)
* fix: consider circle border pen width when drawing (circle was cut-off by 1px)
* change: enable antialiasing for drawing the HUD circle
* change use palette highlight color for drawing the HUD (more consistent with other color scopes)
* fix: adds small border around the Waveform to guarantee good contrast regardless of the surrounding background color (was a problem on light themes)
* fix: make axis line color less distracting / lower opacity (now uses same color as used in RGB parade)
* fix: prevent clipping bottom y value
* change: instead of drawing current y value in the HUD scale below/above top/bottom scale values to prevent clipping let's hide the scale value instead and only show the current y value
* change: draw current y value and horizontal line in highlight color instead of text color (think this looks better when drawing the parade only in black/white color mode; same color as used in RGB parade)
* change: use same margin between drawing area and scale on the right for both Waveform and RGB Parade
* fix: adds small border around the parade to guarantee good contrast regardless of the surrounding background color (was a problem on light themes)
* fix: fill area between individual color channels with this border color instead of palette background color (on light themes this looks better as there is too much contrast between parade background and palette background)
* fix: consider device pixel scaling when drawing axis (fixed bug on HiDPI displays where the axis did not fully extend to the parade right border)
* fix: make axis line color less distracting
* change: instead of drawing current y value in the HUD scale below/above top/bottom scale values to prevent clipping let's hide the scale value instead and only show the current y value instead
* change: draw current y value and horizontal line in highlight color instead of text color (think this looks better when drawing the parade only in black/white color mode)
* change: use same color for gradient reference line as is used for drawing the axis lines but with higher opacity
---
Most of these issues are regressions caused by my previous change to use the system palette for the surrounding area like the min/max values or the drop-down selection on top of the widget. The HiDPI bug is ancient and also present in latest release.
Before:
<img src="/uploads/57df01a3162714c1e720148375ccddbe/before_breeze_light.png" width=200>
<img src="/uploads/5b66098b110f25ac36db9820bec38d2d/before_breeze_dark.png" width=200>
After:
<img src="/uploads/33243b7c868dcf748e9cc35b043f06d0/after_breeze_light.png" width=200>
<img src="/uploads/70d63fd9d0b054b6c11a526ff7899895/after_breeze_dark.png" width=200>
* restyle audio mixer
* create new styles for audio levels
* share the same component for audio levels in the mixer and monitor toolbar
* refactor mixer and level widgets
* make channels readable on non-stereo projects (especially on HiDPI displays with fractional scaling they have been pretty much unreadable)
implements: #2008
implements: #2010
Unfortunately the script to add the version to the appstream files
relies on cmake and at the moment it grabs the version from imath, which
is included with OpenTimeLineIO, which is fetched by default.
GIT_SILENT
Unfortunately the script to add the version to the appstream files
relies on cmake and at the moment it grabs the version from imath, which
is included with OpenTimeLineIO, which is fetched by default.
GIT_SILENT
Gave OTIO export a try and noticed that the video tracks were reversed when opening the .otio file with the official `otioviewer` app (audio tracks are fine).
Found this [bug report](https://bugs.kde.org/show_bug.cgi?id=503692) which describes the same issue using Davinci Resolve.
The documentation https://opentimelineio.readthedocs.io/en/latest/tutorials/otio-timeline-structure.html mentions this:
> Rendering of the image tracks in a timeline is done in painter order. The layers in a stack are iterated from the bottom (the first entry in the stack) towards the top (the final entry in the stack)
So when we have the timeline V3, V2, V1, A1, A2, A3 in Kdenlive it seems like that the tracks should be added to the stack in this order: V1, V2, V3, A1, A2, A3. I did not find an answer if video or audio should/must come in a specific order though, but this seems to work with `otioviewer` so is probably fine.
I don't have an application to test this with other than `otioviewer` (or know anything else about OTIO 😅 ) so if someone has Davinci Resolve or some other thing that can import .otio files would be nice if you could test the issue and this change.
We call drawComponent with bins in y and max always set to 256.
so std::max_element gets two indices while the first is inclusive and the last exclusive so by &y[max - 1] we always exclude the last/highest bin.
When you pass in a white color clip then there is only data in the highest bin with index=255. If we skip this then maxBinSize will be 0 leading to infinity in the log function leading to funny results when trying to call setPixel at minus infinity.
Note1: Its not a crash but the app will become unresponsive/blocked and you can see infinite log messages complaining about setPixel
Note2: There is probably another issue unrelated to the Histogram. I would have expected this to die on almost all color clips like #ff0000 or #ffff00. For yellow for example I can reproduce but not for red. For some reason all these red pixels are not 255 but 254...
* Fixes rounding error when converting between cpp and qml offsets. In cpp we use top-left integer offset but in QML centered x/y floating point coords. This accumulated in a misalignment by a few pixels. Also affected drawing the overlays / grids being off slightly.
* Fixes zoombar compensation when setting qml offsets. This was hardcoded to 10 pixels but on my system this is 14. This resulted in major misalignment on higher zoom levels as the error is multiplied by the zoom factor.
2nd problem is most noticable when using rotoscope on a high zoom level but affected all tools. Notice yellow rectangle is off as well as red rotoscope mask border
misaligned:
fixed:
1st problem was also noticable when not zoomed. See slight offset of red rectangle at the bottom
misaligned:
fixed:
I was pulling my hair out trying to understand what `10 * m_zoom` is supposed to be until I understood that is supposed to be the size of the opposite zoombar...
This is definitely a fix for
https://bugs.kde.org/show_bug.cgi?id=498337
and I think also for
https://bugs.kde.org/show_bug.cgi?id=461219
but I'm not exactly sure about the 2nd report or if reported meant something different.
We call drawComponent with bins in y and max always set to 256.
so std::max_element gets two indices while the first is inclusive and the last exclusive so by &y[max - 1] we always exclude the last/highest bin.
When you pass in a white color clip then there is only data in the highest bin with index=255. If we skip this then maxBinSize will be 0 leading to infinity in the log function leading to funny results when trying to call setPixel at minus infinity.
Note1: Its not a crash but the app will become unresponsive/blocked and you can see infinite log messages complaining about setPixel
Note2: There is probably another issue unrelated to the Histogram. I would have expected this to die on almost all color clips like #ff0000 or #ffff00. For yellow for example I can reproduce but not for red. For some reason all these red pixels are not 255 but 254...
When zoomed (gain > 1.0) we did not plot additional pixels in the zoomed region so those remain as fill color producing visible artifacts making it hard to see anything on the scope.
Fixed by interpolating these additional in-between pixels so we get a smooth continuous view without artifacts.
Using QImage SmoothTransformation method here for a smooth/blurry look. With FastTransformation we'd be 2x faster but compared to the time it takes to draw the vectorscope overall the scaling time doesn't really matter.
Testing on a 1080p clip:
Before:
**101_000 us**
After:
**102_000 us**
This includes scaling with SmoothTransformation which itself took **700 us**.
Interpolation Method:
I went with SmoothTransformation but other options would be possible.
FastTransformation would be faster at around **300 us**. But given the time it takes to draw the unscaled Vectorscope this gain is pretty much negligible.
This is how it would look using FastTransformation instead of Smooth:
This is what it looks like in Davinci Resolve: https://youtu.be/m1F9TJzfo1s?feature=shared&t=483
Too me this looks blurry so I guess they use Bilinear/Smooth interpolation.
@emohr was in favor (via Chat) of following Davinci here.
* previously thumbs have been loaded sequentially which wasn't the best experience. This change speeds it up by running these requests in parallel
* according to docs QNetworkAccessManager executes up to 6 requests in parallel which fits this purpose and shouldn't overload these APIs
* don't use temporary files to download the thumbnails before converting to pixmaps. Just do it in memory
I added some instructions on how to get a build environment for Arch Linux. I figured if it's specifically named as being supported for building it would make sense to have some information on how to build under it.
* Fixes rounding error when converting between cpp and qml offsets. In cpp we use top-left integer offset but in QML centered x/y floating point coords. This accumulated in a misalignment by a few pixels. Also affected drawing the overlays / grids being off slightly.
* Fixes zoombar compensation when setting qml offsets. This was hardcoded to 10 pixels but on my system this is 14. This resulted in major misalignment on higher zoom levels as the error is multiplied by the zoom factor.
2nd problem is most noticable when using rotoscope on a high zoom level but affected all tools. Notice yellow rectangle is off as well as red rotoscope mask border
misaligned:
fixed:
1st problem was also noticable when not zoomed. See slight offset of red rectangle at the bottom
misaligned:
fixed:
I was pulling my hair out trying to understand what `10 * m_zoom` is supposed to be until I understood that is supposed to be the size of the opposite zoombar...
This is definitely a fix for
https://bugs.kde.org/show_bug.cgi?id=498337
and I think also for
https://bugs.kde.org/show_bug.cgi?id=461219
but I'm not exactly sure about the 2nd report or if reported meant something different.
Fixes: https://invent.kde.org/multimedia/kdenlive/-/issues/1973
Official AsyncVideoFrameLoader loads all frames into memory which prevents it for being used clips longer than a few seconds.
This introduces our own version of AsyncVideoFrameLoader which doesn't cache all images.
Check out the comment https://invent.kde.org/multimedia/kdenlive/-/issues/1973#note_1199934 for more details.
Didn't bother to create a PR for the official Facebook repo. Based on outstanding open PRs and official activity on that repo its not a community project. Need to fix this on our side unfortunately.
Its basically as three line change as mentioned in the comment but needed to create our custom SAM2VideoPredictor which delegates to the official SAM2VideoPredictorOfficial except loading the images in init in order to fix it (Wanted to avoid forking SAM2 repo so we don't have another repo to maintain...).
I intend to work a bit more on the SAM integration and added a few TODOs for myself. Will clean up this code and fix the TODOs in future MRs.
Also, while testing the feature looks like preview mode is somewhat broken (preview seems to work only for the first frame atm).
Fixes: https://invent.kde.org/multimedia/kdenlive/-/issues/1973
Official AsyncVideoFrameLoader loads all frames into memory which prevents it for being used clips longer than a few seconds.
This introduces our own version of AsyncVideoFrameLoader which doesn't cache all images.
Check out the comment https://invent.kde.org/multimedia/kdenlive/-/issues/1973#note_1199934 for more details.
Didn't bother to create a PR for the official Facebook repo. Based on outstanding open PRs and official activity on that repo its not a community project. Need to fix this on our side unfortunately.
Its basically as three line change as mentioned in the comment but needed to create our custom SAM2VideoPredictor which delegates to the official SAM2VideoPredictorOfficial except loading the images in init in order to fix it (Wanted to avoid forking SAM2 repo so we don't have another repo to maintain...).
I intend to work a bit more on the SAM integration and added a few TODOs for myself. Will clean up this code and fix the TODOs in future MRs.
Also, while testing the feature looks like preview mode is somewhat broken (preview seems to work only for the first frame atm).
* extract layout management dialog (accessible via menu View - Manage Layouts...)
* extract layout switcher (shown in top-right corner of menu bar)
* extract functionality around the collection of layouts (like loading, ordering, getting)
While preparing for https://invent.kde.org/multimedia/kdenlive/-/issues/1999 I had a hard time understanding this code as its doing lots of things so I tried to extract the self-contained functionality mentioned above and kept only the plumbing in layoutmanagement.cpp.
This change contains no user-visible changes, just refactoring of existing functionality.
Left a TODO regarding setting up the autosafe label and corner of the bar menu where I didn't know a good place to put it. If you have a suggestion for this I can do in scope of this MR otherwise I hope I'd find something while working on the layout switcher. Cheers!
I'd like to propose some changes to the README:
After brief welcome and introduction what this project is I would like to point regular users to the website. It contains the best and most up-to-date info for everything except dev/coding documentation.
Everything after that would then focus only on developers / potential code contributors.
I imagine the README to be the landing page we forward people to from the website that are interested in contributing code / hacking on the project. (On the new website this would be from the contribute page https://invent.kde.org/websites/kdenlive-org/-/merge_requests/22)
On Ubuntu 25.04, the libraries listed under `Get the build dependencies`
in `build.md` are insufficient to build the project. Add the missing
libraries.
Fixes https://bugs.kde.org/show_bug.cgi?id=471281.
Green paint mode produced brownish and other weird colors instead of green as 0 values were not handled correctly which produced -inf when calculating its log value
Unfortunately the script to add the version to the appstream files
relies on cmake and at the moment it grabs the version from imath, which
is included with OpenTimeLineIO, which is fetched by default.
GIT_SILENT
(cherry picked from commit 89eb8d717b)
Unfortunately the script to add the version to the appstream files
relies on cmake and at the moment it grabs the version from imath, which
is included with OpenTimeLineIO, which is fetched by default.
GIT_SILENT
Currently the slider only changes if the user hits enter after doing changes in the spin box. On other widgets like Volume Effect widget we update the slider immediately when user changes the value via mousewheel or up/down buttons.
We need to calculate the bounding rectangle after we've set the actual
font via setFont(). Otherwise the default font will be used for the
calculation which may or may not be what is used later when draw the
actual text.
Currently the slider only changes if the user hits enter after doing changes in the spin box. On other widgets like Volume Effect widget we update the slider immediately when user changes the value via mousewheel or up/down buttons.
We need to calculate the bounding rectangle after we've set the actual
font via setFont(). Otherwise the default font will be used for the
calculation which may or may not be what is used later when draw the
actual text.
As I was doing more OTIO testing, I found a freeze while opening a file with all missing media filenames. All of the `ClipCreator::createClipFromFile` callbacks seemed to fire OK, but the test hangs when trying to insert the clips into the timeline. Here is a partial stack trace:
```
QReadWriteLock::lockForRead(class QReadWriteLock * const this) (/usr/include/x86_64-linux-gnu/qt6/QtCore/qreadwritelock.h:68)
QReadLocker::relock(class QReadLocker * const this) (/usr/include/x86_64-linux-gnu/qt6/QtCore/qreadwritelock.h:115)
QReadLocker::QReadLocker(class QReadLocker * const this, class QReadWriteLock * areadWriteLock) (/usr/include/x86_64-linux-gnu/qt6/QtCore/qreadwritelock.h:134)
ClipController::getProducerIntProperty(const class ClipController * const this, const class QString & name) (src/mltcontroller/clipcontroller.cpp:596)
TimelineModel::requestClipInsertion(class TimelineModel * const this, const class QString & binClipId, int trackId, int position, int & id, bool logUndo, bool refreshView, bool useTargets, Fun & undo, Fun & redo, const QVector & allowedTracks) (src/timeline2/model/timelinemodel.cpp:2119)
OtioImport::importClip(class OtioImport * const this, const class std::shared_ptr<OtioImportData> & importData, const struct opentimelineio::v1_0::SerializableObject::Retainer<opentimelineio::v1_0::Clip> & otioClip, int trackId) (src/otio/otioimport.cpp:325)
OtioImport::importTrack(class OtioImport * const this, const class std::shared_ptr<OtioImportData> & importData, const struct opentimelineio::v1_0::SerializableObject::Retainer<opentimelineio::v1_0::Track> & otioTrack, int trackId) (src/otio/otioimport.cpp:276)
OtioImport::importTimeline(class OtioImport * const this, const class std::shared_ptr<OtioImportData> & importData) (src/otio/otioimport.cpp:248)
```
Strangely enough, the existing OTIO missing media test that only has some missing media filenames seems to pass OK.
(Note, I also edited the test OTIO files to remove some empty tracks that were not necessary for testing.)
As I was doing more OTIO testing, I found a freeze while opening a file with all missing media filenames. All of the `ClipCreator::createClipFromFile` callbacks seemed to fire OK, but the test hangs when trying to insert the clips into the timeline. Here is a partial stack trace:
```
QReadWriteLock::lockForRead(class QReadWriteLock * const this) (/usr/include/x86_64-linux-gnu/qt6/QtCore/qreadwritelock.h:68)
QReadLocker::relock(class QReadLocker * const this) (/usr/include/x86_64-linux-gnu/qt6/QtCore/qreadwritelock.h:115)
QReadLocker::QReadLocker(class QReadLocker * const this, class QReadWriteLock * areadWriteLock) (/usr/include/x86_64-linux-gnu/qt6/QtCore/qreadwritelock.h:134)
ClipController::getProducerIntProperty(const class ClipController * const this, const class QString & name) (src/mltcontroller/clipcontroller.cpp:596)
TimelineModel::requestClipInsertion(class TimelineModel * const this, const class QString & binClipId, int trackId, int position, int & id, bool logUndo, bool refreshView, bool useTargets, Fun & undo, Fun & redo, const QVector & allowedTracks) (src/timeline2/model/timelinemodel.cpp:2119)
OtioImport::importClip(class OtioImport * const this, const class std::shared_ptr<OtioImportData> & importData, const struct opentimelineio::v1_0::SerializableObject::Retainer<opentimelineio::v1_0::Clip> & otioClip, int trackId) (src/otio/otioimport.cpp:325)
OtioImport::importTrack(class OtioImport * const this, const class std::shared_ptr<OtioImportData> & importData, const struct opentimelineio::v1_0::SerializableObject::Retainer<opentimelineio::v1_0::Track> & otioTrack, int trackId) (src/otio/otioimport.cpp:276)
OtioImport::importTimeline(class OtioImport * const this, const class std::shared_ptr<OtioImportData> & importData) (src/otio/otioimport.cpp:248)
```
Strangely enough, the existing OTIO missing media test that only has some missing media filenames seems to pass OK.
(Note, I also edited the test OTIO files to remove some empty tracks that were not necessary for testing.)
Two fixes for clips with small durations (1 and zero frames):
* Don't create clips with zero duration when importing OTIO files.
* Remove an assert in ClipModel::requestSlip() that was triggered when slipping clips with a duration of 1 frame.
The diff for the first change looks like a lot, but the change is really just adding this conditional:
```
const int duration = otioTrimmedRange.value().duration().rescaled_to(otioTimelineDuration).round().value();
if (duration > 0) {
```
Two fixes for clips with small durations (1 and zero frames):
* Don't create clips with zero duration when importing OTIO files.
* Remove an assert in ClipModel::requestSlip() that was triggered when slipping clips with a duration of 1 frame.
The diff for the first change looks like a lot, but the change is really just adding this conditional:
```
const int duration = otioTrimmedRange.value().duration().rescaled_to(otioTimelineDuration).round().value();
if (duration > 0) {
```
- Added suffix, one decimal point, translated planes from numbers to plain text and changed type to "list"
- Added parameters for alpha channel, added comments with explanation
- Corrected max values, added alpha channel, added comments
- Added suffix, one decimal point, translated planes from numbers to plain text and changed type to "list"
- Added parameters for alpha channel, added comments with explanation
- Corrected max values, added alpha channel, added comments
The external proxy preset strings consist of sets of 6 elements:
path clip->proxy;proxy prefix;proxy suffix;path proxy->clip;clip prefix;clip suffix
appended sequentially for each 'profile' that the preset describes.
When we import those into the proxy profiles edit dialog, we deconstruct
that and regroup them so that all the clip->proxy paths (etc.) are together
in a single QLineEdit widget for each element type.
Which means we need to reverse that process and re-interleave them in
profile groups after validating those fields. If we just concatenate
the contents of the edit widgets all the elements end up in the wrong
order.
BUG: 485356
Large animated titles (like credits) can easily extend past the default
spinbox maximum of 5000. You could still place them outside that range
but you then get no feedback or fine control via the spinbox of their
precise position.
Increasing it to 99999 is still a bit arbitrary, but that value will
fit without making the box physically larger, and INT_MAX seems a bit
overkill. We can always bump it again if a real user needs that.
Cap the width and height minimum at 0 - negative size doesn't make
a lot of sense here.
BUG: 487950
# Rewrite Audio Waveform generation + drawing
Addresses #1888.
This work is done as part of contract work with KDE e.V.
# Summary
## Waveform generation performance improvements
The original MLT method has been improved and a faster libav* -based one is used when possible. The original method used the "audiolevel" MLT filter, which only supported 1 point per frame and was quite slow.
Measured time taken for audio levels generation in release builds on my machine (AMD Ryzen 7 3700U with SSD).
- _original MLT_ is before these changes, with one point per frame;
- _new MLT_ is the improved method, with 5 points per frame;
- _new libav_ is the method using libav directly, with 5 points per frame.
| file | new libav (s) | new MLT (s) | original MLT (s) |
|-----------------------------------------|---------------|-------------|------------------|
| 1h 20min of stereo uncompressed WAV | 2.477 | 5.187 | 8.131 |
| 1h 20min of stereo max-compressed FLAC | 6.818 | 9.03 | 12.513 |
| 26min of OPUS audio in a MKV video file | 4.774 | 6.86 | 8.614 |
## Better waveform resolution
This merge requests brings better waveform temporal resolution (1 -> N points per frame) and better vertical resolution (256 -> 65,535 levels).
**Before changes (KDenlive 24.08.3):**
**After changes:**
## Fix incorrect waveform drawing function
When drawing the waveform, the current implementation samples the audio levels at points corresponding to the pixels to draw. This is incorrect and results in distorted waveforms, missing peaks, and visual artifacts. The new implementations uses a slower but correct max-based resampling method.
**Before changes (KDenlive 24.08.3)**
**After changes:**
**Reference (audacity)**
**Stretching a waveform, before changes:**
**Stretching a waveform, after changes:**
# Detailed changes
- Change audiolevels sample format to uint16_t for increased precision
- Add support for N points per frame, currently set to 5
- projectclip.cpp:
- Use TimelineWaveform to render the audio clip thumbnails
- do not store audiolevels in object
- generate larger thumbnails
- Change audio max property key from "kdenlive:audio_max%1" to "_kdenlive:audio_max%1"
- audiolevelstask.cpp: major refactor
- Replace audiolevels PNG (de)serializer with a dumber one
- add fast libav-based generation
- simplify and improve MLT-based generation
- disable caching
- disable resampling
- remove useless audiochannels filter
- remove redundant stream selection
- replace audiolevel filter with direct levels calculation
- add generic computePeaks() function
- kdenliveclipmonitor.qml: fix incorrect clip duration passed to waveform renderer
- timelineitems.cpp: separated items into their own source/header files (timelineplayhead, timelinerecwaveform, timelinetriangle, timelinewaveform)
- timelinewaveform.cpp: simplify and improve waveform rendering
- add support for N points per frame
- add support for fractional in and outpoints
- replace incorrect sampling drawing function with correct max-based one
- remove unused properties
- add even and odd color properties
- Add tests
- Add tests for computePeaks and both generation methods
- Add audio tests files + script to generate them
Make code better readable and fix several bugs:
- We do not need to check for pip on the system anymore because we always use pip from the venv
- The warning messages talk about system python, while they check the venv python
This implements an interface with SAM2 to detect objects in a video and create masks
Related to #1919
Which then allows to do this:
When automatic proxying is enabled, don't proxy clips with an alpha channel. On manual trigger, warn user, and if proxying is requested, transcode to FFV1
When importing avformat files, the hasAudio and hasVideo assignment appears to be swapped. This didn't appear to effect anything once the import had finished, though the wrong clip type is assigned at this stage.
Consider display scaling factor when setting up low-level image buffers (QPixmap and QImage) in some scope widgets
Without setting displayPixelRatio those surfaces look blurry on hidpi screens when scaling factor is set in the OS. Adjusted it on all affected widgets I could find as well as the Splash screen.
You can notice it in the screenshots below when looking at the Volume scale of the monitor or the min/max values in the RGB parade widget.
PS: I have no idea what I'm doing (first time c++ and QT) but surprisingly, looks like only minor adjustments are necessary so I thought I may be able to fix/finish this issue as it's bugging me for quite some time :fingers_crossed: So I'd appreciate even the most obvious feedback 😀
PS: Could only test it on Linux/Arch, would appreciate if someone could test it on Windows/Mac when it's ready 🙏
PS: Good job on the README / developer documentation 👍 . Probably spent more time, figuring out this KDE Invent gitlab setup than running and compiling kdenlive.
before (blurry)
after (sharp)
Consider display scaling factor when setting up low-level image buffers (QPixmap and QImage) in some scope widgets
Without setting displayPixelRatio those surfaces look blurry on hidpi screens when scaling factor is set in the OS. Adjusted it on all affected widgets I could find as well as the Splash screen.
You can notice it in the screenshots below when looking at the Volume scale of the monitor or the min/max values in the RGB parade widget.
PS: I have no idea what I'm doing (first time c++ and QT) but surprisingly, looks like only minor adjustments are necessary so I thought I may be able to fix/finish this issue as it's bugging me for quite some time :fingers_crossed: So I'd appreciate even the most obvious feedback 😀
PS: Could only test it on Linux/Arch, would appreciate if someone could test it on Windows/Mac when it's ready 🙏
PS: Good job on the README / developer documentation 👍 . Probably spent more time, figuring out this KDE Invent gitlab setup than running and compiling kdenlive.
before (blurry)
after (sharp)
(cherry picked from commit d58bfd51d8)
6f2139d6 Add a control uuid to each bin clip to ensure clips can not get mixed on project opening
1c06946a Ensure the first build-in sequence also has a control uuid
Co-authored-by: Jean-Baptiste Mardelle <jb@kdenlive.org>
This MR documents my current progress on implementing the keyframe curve editor in this SoK session. It now comes with a preliminary UI with features such as data display and keyframe seek.
Known issues include:
1. zooming not yet implemented
2. possible random crashes
Usage of "KDE::DoNotExtract" predates the notr attribute and still results
in uic generating code trying to do a (bogus) lookup for the very string.
With notr attribute instead the generated code will only set the given
string as-is. While the given strings are just sample text to help when
working on the UI file and ideally would not appear at all in the final
product, this here at least fixes the also unneeded translation call.
Add an option in the effect stack to enable effect groups. When enabled, adjusting a parameter for an effect, it will apply to all items in the group that have this effect.
Please note that all bug reports and feature requests should be filed on https://bugs.kde.org and should never be raised here.
For support, it is recommended to post on the KDE forum https://discuss.kde.org/ instead or use our chat groups on [Matrix](https://go.kde.org/matrix/#/#kdenlive:kde.org) and [Telegram](https://t.me/kdenlive).
**:warning: Issues on KDE Invent are solely for tracking ongoing work and intended for use by developers and contributors exclusively.**
We request to consult with a developer or other contributor prior to opening issues here, when in doubt we recommended to open them on https://bugs.kde.org instead.
(Please delete this line and the warning text above and below if you create a valid issue.)
**If you submit a bug report or feature request here despite this notice, there's a chance it will be closed without comment or consideration.**
# SPDX-FileCopyrightText: Julius Künzel <jk.kdedev@smartlab.uber.space>, Jean-Baptiste Mardelle <jb@kdenlive.org>, Alberto Villa <avilla@FreeBSD.org>, Albert Astals Cid <aacid@kde.org>, Vincent Pinon <vpinon@kde.org>, Laurent Montel <montel@kde.org>, Vincent Pinon <vincent.pinon@asygn.com>, Nicolas Carion <french.ebook.lover@gmail.com>
# SPDX-FileCopyrightText: Julius Künzel <julius.kuenzel@kde.org>, Jean-Baptiste Mardelle <jb@kdenlive.org>, Alberto Villa <avilla@FreeBSD.org>, Albert Astals Cid <aacid@kde.org>, Vincent Pinon <vpinon@kde.org>, Laurent Montel <montel@kde.org>, Vincent Pinon <vincent.pinon@asygn.com>, Nicolas Carion <french.ebook.lover@gmail.com>
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.]
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things.
To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others.
Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.
When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.
We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances.
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.
Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.
In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.
If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.
11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).
To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the library's name and an idea of what it does.
Copyright (C) year name of author
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in
the library `Frob' (a library for tweaking knobs) written
[Kdenlive](https://kdenlive.org) is a Free and Open Source video editing application, based on MLT Framework and KDE Frameworks 6. It is distributed under the [GNU General Public License Version 3](https://www.gnu.org/licenses/gpl-3.0.en.html) or any later version that is accepted by the KDE project.
Kdenlive is a powerful, free and open-source video editor that brings professional-grade video editing capabilities to everyone. Whether you're creating a simple family video or working on a complex project, Kdenlive provides the tools you need to bring your vision to life.
# Building from source
For more information about Kdenlive's features, tutorials, and community, please visit our [official website](https://kdenlive.org).
[Instructions to build Kdenlive](dev-docs/build.md) are available in the dev-docs folder.
There you can also find downloads for both stable releases and experimental daily builds for Kdenlive.
- Add the kde flatpak repository (if not already done) by typing `flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo` on a command line. (This step may be optional in your version of Flatpak.)
- Install kdenlive nightly with `flatpak install kdeapps org.kde.kdenlive`.
- Use `flatpak update` to update if the nightly is already installed.
- _Attention! If you use the stable kdenlive flatpak already, the `*.desktop` file (e.g. responsible for start menu entry) is maybe replaced by the nightly (and vice versa). You can still run the stable version with `flatpak run org.kde.kdenlive/x86_64/stable` and the nightly with `flatpak run org.kde.kdenlive/x86_64/master` (replace `x86_64` by `aarch64` or `arm` depending on your system)_
Kdenlive is a community-driven project, and we welcome contributions from everyone! There are many ways to contribute beyond coding:
*Note * - nightly/daily builds are not meant to be used in production.*
- Help translate Kdenlive into your language
- Report and triage bugs
- Write documentation
- Create tutorials
- Help other users on forums and bug trackers
# Contributing to Kdenlive
Visit [kdenlive.org](https://kdenlive.org) to learn more about non-code contributions.
Please note that Kdenlive's Github repo is just a mirror: read [this explanation for more details](https://community.kde.org/Infrastructure/Github_Mirror).
## Developer Information
The prefered way of submitting patches is a merge request on the [KDE GitLab on invent.kde.org](https://invent.kde.org/-/ide/project/multimedia/kdenlive): if you are not familar with the process there is a [step by step instruction on how to submit a merge reqest in KDE context](https://community.kde.org/Infrastructure/GitLab#Submitting_a_Merge_Request).
### Technology Stack
We welcome all feedback and offers for help!
Kdenlive is written in C++ and is using these technologies and frameworks:
* Talk about us!
*[Report bugs](https://kdenlive.org/en/bug-reports/) you encounter (if not already done)
*Help other users [on the forum](http://forum.kde.org/viewforum.php?f=262) and bug tracker
* [Help to fill the manual](https://community.kde.org/Kdenlive/Workgroup/Documentation)
* Complete and check [application and documentation translation](http://l10n.kde.org)
* Prepare video tutorials (intro, special tricks...) in your language
and send us a link to add in homepage or doc
* Detail improvement suggestions
we don't test every (any?) other video editor, so give precise explanations
* Code! Help fixing bugs, improving usability, optimizing, porting...
register on KDE infrastructure, study its guidelines, and pick from roadmap. See [here](dev-docs/contributing.md) for more information
- **Core Framework**: MLT for video editing functionality
1. Check out our [build instructions](dev-docs/build.md) to set up your development environment
2. Familiarize yourself with the [architecture](dev-docs/architecture.md) and [coding guidelines](dev-docs/coding.md)
4. If the MLT library is new to you check out [MLT Introduction](dev-docs/mlt-intro.md)
3. Join our Matrix channel `#kdenlive-dev:kde.org` for developer discussions and support
### Contributing Code
Kdenlive's primary development happens on [KDE Invent](https://invent.kde.org/multimedia/kdenlive). While we maintain a GitHub mirror, all code contributions should be submitted through KDE's GitLab instance. For more information about KDE's development infrastructure, visit the [KDE GitLab documentation](https://community.kde.org/Infrastructure/GitLab).
### Finding Things to Work On
- Browse open issues on [KDE Invent](https://invent.kde.org/multimedia/kdenlive/-/issues)
- Check the [KDE Bug Tracker](https://bugs.kde.org) for reported issues
- Look for issues tagged with "good first issue" or "help wanted"
Need help getting started? Join our Matrix channel `#kdenlive-dev:kde.org` - our community is friendly and always ready to help new contributors!
@@ -129,6 +129,12 @@ For double values these placeholders are available:
* represented by a checkbox
##### `"multiswitch"`
* 2 possible options defined by strings (max / min)
* this special parameter type will affect 2 different parameters when changed. the `name` of this parameter will contain the name of the 2 final parameters, separated by a LF character: ` `. Same thing for the `default`, `min` and `max` which will contain the values for these 2 parameters, separated by an LF character. See for example the fade_to_black effect.
<paramlistdisplay>BT.709,BT.470M,BT.470BG,Constant gamma of 2.2,Constant gamma of 2.8,SMPTE-170M,SMPTE-240M,SRGB,iec61966-2-1,iec61966-2-4,xvycc,BT.2020 for 10-bits content, BT.2020 for 12-bits content</paramlistdisplay>
<name>Output transfer characteristicse</name>
<paramlistdisplay>BT.709,BT.470M,BT.470BG,Constant gamma of 2.2,Constant gamma of 2.8,SMPTE170M,SMPTE240M,SRGB,IEC 61966-2-1,IEC 61966-2-4,xvYCC,BT.2020 for 10-bits content, BT.2020 for 12-bits content</paramlistdisplay>
<paramlistdisplay>BT.709,BT.470M,BT.470BG,Constant gamma of 2.2,Constant gamma of 2.8,SMPTE-170M,SMPTE-240M,SRGB,iec61966-2-1,iec61966-2-4,xvycc,BT.2020 for 10-bits content, BT.2020 for 12-bits content</paramlistdisplay>
<paramlistdisplay>BT.709,BT.470M,BT.470BG,Constant gamma of 2.2,Constant gamma of 2.8,SMPTE170M,SMPTE240M,SRGB,IEC 61966-2-1,IEC 61966-2-4,xvYCC,BT.2020 for 10-bits content, BT.2020 for 12-bits content</paramlistdisplay>
<name>Override input transfer characteristics</name>
<comment>A list of times in seconds for each channel over which the instantaneous level of the input signal is averaged to determine its volume. attacks refers to increase of volume and decays refers to decrease of volume. For most situations, the attack time (response to the audio getting louder) should be shorter than the decay time, because the human ear is more sensitive to sudden loud audio than sudden soft audio. A typical value for attack is 0.3 seconds and a typical value for decay is 0.8 seconds. If specified number of attacks and decays is lower than number of channels, the last set attack/decay will be used for all remaining channels.</comment>
<comment>A list of times in seconds for each channel over which the instantaneous level of the input signal is averaged to determine its volume. Attacks refers to increase of volume and decays refers to decrease of volume. For most situations, the attack time (response to the audio getting louder) should be shorter than the decay time, because the human ear is more sensitive to sudden loud audio than sudden soft audio. A typical value for attack is 0.3 seconds and a typical value for decay is 0.8 seconds. If specified number of attacks and decays is lower than number of channels, the last set attack/decay will be used for all remaining channels.</comment>
<comment>A list of times in seconds for each channel over which the instantaneous level of the input signal is averaged to determine its volume. attacks refers to increase of volume and decays refers to decrease of volume. For most situations, the attack time (response to the audio getting louder) should be shorter than the decay time, because the human ear is more sensitive to sudden loud audio than sudden soft audio. A typical value for attack is 0.3 seconds and a typical value for decay is 0.8 seconds. If specified number of attacks and decays is lower than number of channels, the last set attack/decay will be used for all remaining channels.</comment>
<comment>A list of times in seconds for each channel over which the instantaneous level of the input signal is averaged to determine its volume. Attacks refers to increase of volume and decays refers to decrease of volume. For most situations, the attack time (response to the audio getting louder) should be shorter than the decay time, because the human ear is more sensitive to sudden loud audio than sudden soft audio. A typical value for attack is 0.3 seconds and a typical value for decay is 0.8 seconds. If specified number of attacks and decays is lower than number of channels, the last set attack/decay will be used for all remaining channels.</comment>
<comment>et an initial volume, in dB, to be assumed for each channel when filtering starts. This permits the user to supply a nominal level initially, so that, for example, a very large gain is not applied to initial signal levels before the companding has begun to operate. A typical value for audio which is initially quiet is -90 dB.</comment>
<comment>Set an initial volume, in dB, to be assumed for each channel when filtering starts. This permits the user to supply a nominal level initially, so that, for example, a very large gain is not applied to initial signal levels before the companding has begun to operate. A typical value for audio which is initially quiet is -90 dB.</comment>
@@ -8,7 +8,7 @@ For example, you have recorded guitar with two microphones placed in different l
The best result can be reached when you take one track as base and synchronize other tracks one by one with it. Remember that synchronization/delay tolerance depends on sample rate, too. Higher sample rates will give more tolerance. </description>
<comment><![CDATA[Banding detection range in pixels. Default is 16.<br>
If positive, random number in range 0 to set value will be used. If negative, exact absolute value will be used. The range defines square of four pixels around current pixel.]]></comment>
<comment><![CDATA[Sets direction in degrees from which four pixel will be compared.<br>
If positive, random direction from 0 to set direction will be picked. If negative, exact of absolute value will be picked. For example direction 0°, -180°, or -360° will pick only pixels on same row and -90° will pick only pixels on same column]]></comment>
<comment><![CDATA[If enabled, current pixel is compared with average value of all four surrounding pixels.<br>
The default is enabled. If disabled, current pixel is compared with all four surrounding pixels. The pixel is considered banded if only all four differences with surrounding pixels are less than threshold.]]></comment>
Simulates image dilation, an effect which will enlarge the lightest pixels in the image by replacing the pixel by the local (3x3) maximum.]]></description>
Simulates image erosion, an effect which will enlarge the darkest pixels in the image by replacing the pixel by the local (3x3) minimum.]]></description>
<description>Fill borders of the input video, without changing video stream dimensions. Sometimes video can have garbage at the four edges and you may not want to crop video input to keep size multiple of some number</description>
<name>Fill Borders</name>
<description>Fill borders of the input video without changing video stream dimensions. Sometimes video can have garbage at the four edges and you may not want to crop video input to keep the size multiple of some number</description>
Fix the banding artifacts that are sometimes introduced into nearly flat regions by truncation to 8-bit color depth.<br>
Interpolate the gradients that should go where the bands are, and dither them.<br>
<b>It is designed for playback only. Do not use it prior to lossy compression, because compression tends to lose the dither and bring back the bands</b>.]]></description>
<paramlistdisplay>White on Black,Black on White,White on Gray,Black on Gray,Color on Black,Color on White,Color on Gray,Black on Color,White on Color,Gray on Color</paramlistdisplay>
<description>Scale the input by 2, 3 or 4 using the hq*x magnification algorithm</description>
<description>Apply a high-quality magnification filter designed for pixel art. Scaling is done by 2, 3 or 4 using the hq*x magnification algorithm.</description>
<description>Deinterlace input video by applying Donald Graft’s adaptive kernel deinterling. Work on interlaced parts of a video to produce progressive frames. </description>
<description>Deinterlace input video by applying Donald Graft’s adaptive kernel deinterling. Works on interlaced parts of a video to produce progressive frames. </description>
<description>Apply a Look Up Table (LUT) to the video.
<full><![CDATA[A LUT is an easy way to correct the color of a video. Supported formats: .3dl (AfterEffects), .cube (Iridas), .dat(DaVinci), .m3d (Pandora)]]></full></description>
<description>Apply a Look Up Table (LUT) to the video. A LUT is an easy way to correct the color of a video. Supported formats: .3dl (AfterEffects), .cube (Iridas), .dat (DaVinci), .m3d (Pandora)</description>
<comment><![CDATA[Set the luma threshold used as a coefficient<br>
to determine whether a pixel should be blurred or not. A value of 0 will filter all the image, positive values will filter flat areas, negative values will filter edges.]]></comment>
The value specifies the variance of the gaussian filter used to blur the image (slower if larger). If not specified, it defaults to the value set for <em>Luma radius</em>]]></comment>
The value configures the blurring. A positive value will blur the image, whereas a negative value will sharpen the image. If not specified, it defaults to the value set for <em>Luma strength</em>.]]></comment>
<comment><![CDATA[Set the chroma threshold used as a coefficient<br>
to determine whether a pixel should be blurred or not. A value of 0 will filter all the image, positive values will filter flat areas, negative values will filter edges. If not specified, it defaults to the value set for <em>Luma threshold</em>]]></comment>
The value specifies the variance of the gaussian filter used to blur the image (slower if larger). If not specified, it defaults to the value set for <em>Luma radius</em>]]></comment>
The value configures the blurring. A positive value will blur the image, whereas a negative value will sharpen the image. If not specified, it defaults to the value set for <em>Luma strength</em>.]]></comment>
<comment><![CDATA[Set the alpha threshold used as a coefficient<br>
to determine whether a pixel should be blurred or not. A value of 0 will filter all the image, positive values will filter flat areas, negative values will filter edges. If not specified, it defaults to the value set for <em>Luma threshold</em>]]></comment>
<comment><![CDATA[Set the luma effect strength.<br>
Reasonable values are between -1.5 and 1.5. Negative values will blur the input video, while positive values will sharpen it, a value of 0 will disable the effect. ]]></comment>
<comment><![CDATA[Set the chroma effect strength.<br>
Reasonable values are between -1.5 and 1.5. Negative values will blur the input video, while positive values will sharpen it, a value of zero will disable the effect. ]]></comment>
<comment><![CDATA[Set the alpha effect strength.<br>
Reasonable values are between -1.5 and 1.5. Negative values will blur the input video, while positive values will sharpen it, a value of zero will disable the effect. ]]></comment>
<description>The waveform monitor plots color component intensity. By default luminance only. Each column of the waveform corresponds to a column of pixels in the source video. </description>
<description>Apply the xBR high-quality magnification filter which is designed for pixel art. It follows a set of edge-detection rules, see https://forums.libretro.com/t/xbr-algorithm-tutorial/123</description>
<description>Apply the xBR high-quality magnification filter which is designed for pixel art. It follows a set of edge-detection rules.</description>
<paramlistdisplay>timecode,frame,creation date,file date (GMT),file date (local),source frame rate,source codec,source bit rate,source width,source height,source comment</paramlistdisplay>
<comment>You can also enter strftime parameters to customize the output, like: #createdate %H:%M %D#</comment>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
