[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 --- Comment #8 from Jens --- That's perfect, thank you! :-) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 emohr changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from emohr --- Time-remap is implemented since version 21.08.0 with smooth transitions between keyframes. Details see here: https://docs.kdenlive.org/en/effects_and_compositions/effects.html#time-remapping-speed-ramps -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 deresi...@protonmail.ch changed: What|Removed |Added CC||deresi...@protonmail.ch --- Comment #6 from deresi...@protonmail.ch --- Is thus just for keyframinf speed or will it be smooth transitioning between speeds when keyframing -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 --- Comment #5 from Jens --- That's great to hear. If I may add one more wish into the same topic: Please also add a quantize option. Imagine somebody playing an instrument or singing, but sometimes too fast, sometimes too slow. I can see the beats in the audio timeline and mark them and I want Kdenlive to equalize the time between these markers (eg. as "500ms" or "80 bpm"). This would be doable with a keyframable speed setting, but very cumbersome. A quantizer effect for audio would be awesome. Even more awesome if you could automatically snap events (like clip transitions or slideshow images) to these markers. Does this sound feasible in the Kdenlive infrastructure? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 emohr changed: What|Removed |Added Flags||Backport+ Status|REOPENED|CONFIRMED CC||fritzib...@gmx.net --- Comment #4 from emohr --- We will implement keyframeable speed with MLT-7. This is on the to do list. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 Jens changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- CC||jens-bugs.kde.org@spamfreem ||ail.de Status|RESOLVED|REOPENED --- Comment #3 from Jens --- I was just about to report quite the same wishlist item. Use case: I have 5 videos of people singing the same song. I want to mix these to create a chorus. But these people are just *so* slightly a) out of time (sometimes faster, sometimes slower, one makes dramatic pauses where they don't belong), b) out of pitch, actually singing in different keys, and c) generally not singing at the same speed. Right now, I have to cut the tracks into multiple pieces and play these at different pitch-compensated speeds. This is a lot of manual work, especially because Kdenlive (current, 21.07.20, nightly Flatbak build) does not like changing speeds in the same track, and sometimes loses video. Different bug.) Also the sound sometimes stutters at the cut positions. I would LOVE to create a keyframeable "speed curve" over each track, which is optionally pitch compensated, so that I can slow down the track in some parts, and speed it up in some others - and even stop it completely (still frame) when one singer misses a pause and continues singing. This should happen independantly of what original FPS the tracks were recorded at. "100% speed" is always set to the FPS which the track originally had. Do you think this is feasible? I'm willing to discuss and help brainstorm this, since I think it's a major feature. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 Paul Konecny changed: What|Removed |Added Resolution|FIXED |WAITINGFORINFO --- Comment #2 from Paul Konecny --- Sorry I got back to you so late. As I said I was burried in my thesis. I think that the speed effect as it is now is a great improvement and I consider the most part of my initial bug report fixed. The only thing that still bugs me it the keyframeability of the effect. I have an idea how to deal with it but I don't know whether I should open a new whishlist or post it here. (The idea would be to keep the clip at a constant length and stretch or compress the part with different speed) See the gui on this page. http://www.cultofmac.com/408250/how-to-speed-up-slo-mo-videos-on-your-iphone/ Cheers! -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 Wegwerf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 353066] WISHLIST - Add keyframeable speed effect with intact audio (like iPhone slow-motion)
https://bugs.kde.org/show_bug.cgi?id=353066 Wegwerf changed: What|Removed |Added CC||wegwerf-1-...@gmx.de --- Comment #1 from Wegwerf --- Paul, audio support has finally landed in stable 16.04.2 if I remember correctly, or at least in current beta. Keyframing the speed effect is not really possible at this time, the reason is how the clip length is to be calculated? This would need integration over the whole clip from the beginning in order to find out where a particular frame for a given position in the timeline is. Do you have any idea as to how to solve this? Paul, would you consider the fixed audio support to be sufficient, and in that case close this bug as resolved fixed? Unfortunatately, I don't see a any clear way in how the keyframing actually could work. -- You are receiving this mail because: You are watching all bug changes.
