[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #35 from earmuff.victor...@icloud.com --- (In reply to Jean-Baptiste Mardelle from comment #14) > Could you test our latest nightly builds that contain my MLT fixed to > confirm if the issue is better ? Sorry for the latent reply, I have tested with a few nightly builds, most recently 9643, and the results look smth! Thanks for all the hard work you and Ron have put into this! Really appreciate it! -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #34 from Ron --- Thanks! Nothing leaps off the page at me in the diff to the previous patch - though that (consumerScale > 0.) test block caught my eye and had me scratching my head again until my idiot brain twigged that it was reading > 0 but *thinking* > 1 so that bit makes more sense now :) It is why I like to give 'magic' numbers and return values explicit names, so they don't get confused with 'normal' values. I've just updated my dev vm to pull these last changes in, and confirmed Roxane's test case still looks good. Right now I'm mostly testing changes to subtitle stuff, so this code path probably won't get a lot of exercise there just yet - but I'm deliberately poking at lots of corner cases, so ... -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #33 from Jean-Baptiste Mardelle --- Also note that the patch I am proposing is already applied to our daily built AppImages if someone wants to test -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #32 from Jean-Baptiste Mardelle --- I created an MR against MLT with some of the changes you suggested as well as a few other fixes. I will keep it open for a few day if you or others want to have a look and if nothing too problematic comes up, I will merge. https://github.com/mltframework/mlt/pull/1064 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #31 from Ron --- hmm, not directly related to this issue as such - but I woke from a nap wondering if there might not be a measurable rendering speed up from inlining the mlt_profile_scale_*() functions ... qtblend alone calls them 4 times each time it's entered for a frame, and it's really just a simple (if args initialised do divide) which seems ripe for the compiler to be able to do Good Things with if it wasn't hidden behind a function call into a different shared library ... -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #30 from Ron ---
(In reply to Jean-Baptiste Mardelle from comment #29)
> ... My work is here:
> https://github.com/j-b-m/mlt/tree/work/qtblend-fixes
Looking at the diff between that tree and the one my 'final' patch came from,
I have a couple of initial comments (most easily expressed as a patch ;)
diff --git a/src/modules/qt/filter_qtblend.cpp
b/src/modules/qt/filter_qtblend.cpp
index f77ab94f..0db7b9bb 100644
--- a/src/modules/qt/filter_qtblend.cpp
+++ b/src/modules/qt/filter_qtblend.cpp
@@ -81,7 +81,7 @@ static int filter_get_image(mlt_frame frame,
double opacity = 1.0;
// If the _qtblend_scaled property is true, a filter was already applied,
and we cannot get the consumer scaling using *width / *height
-bool qtblendRescaled = mlt_properties_get_int(frame_properties,
"_qtblend_scaled") == 1;
+ int qtblendRescaled = mlt_properties_get_int(frame_properties,
"_qtblend_scaled");
if (mlt_properties_get(properties, "rect")) {
rect = mlt_properties_anim_get_rect(properties, "rect", position,
length);
if (::strchr(mlt_properties_get(properties, "rect"), '%')) {
@@ -204,7 +204,7 @@ static int filter_get_image(mlt_frame frame,
if (distort) {
transform.scale(rect.w / b_width, rect.h / b_height);
} else {
-double scale = 1;
+double scale;
double resize_dar = rect.w * consumer_ar / rect.h;
if (b_dar >= resize_dar) {
scale = rect.w / b_width;
The "int qtblendRescaled" change is a micro optimisation - it will either be 1
if we set it, or default to 0 if we didn't,
so we don't need to test it and massage it into a bool type before using it as
a true/false conditional later.
The compiler would *probably* just do that anyway, but this is a hot path, so
...
And scale doesn't need initialisation there, it's always set one way or the
other just below that.
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 4bc59050..cdebbfec 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -91,15 +91,15 @@ static int get_image(mlt_frame a_frame,
}
int request_width = profile->width;
-int request_height = profile->height;
+// int request_height = profile->height;
double scalex = mlt_profile_scale_width(profile, *width);
double scaley = mlt_profile_scale_height(profile, *height);
if (scalex != 1.) {
-request_width *= scalex;
+request_width = *width;
b_height *= scalex;
b_width *= scalex;
}
-request_height *= scaley;
+int request_height = *height;
// Check transform
if (mlt_properties_get(transition_properties, "rect")) {
@@ -203,6 +203,7 @@ static int get_image(mlt_frame a_frame,
"progressive,distort,colorspace,full_range,force_full_luma,"
"top_field_first,color_trc");
// Prepare output image
+ // XXX Delete this conditional now
if (false && b_frame->convert_image && (b_width != request_width
|| b_height != request_height)) {
mlt_properties_set_int(b_properties, "convert_image_width",
request_width);
mlt_properties_set_int(b_properties, "convert_image_height",
request_height);
The change to request_*, unless I'm missing something there, is just what that
really does?
mlt_profile_scale_width sets scalex = width / profile->width
So at best request_width (aka profile->width) * scalex, will always equal width
or at worst it will be slightly different due to fp rounding precision.
The compiler would *probably* optimise out the second multiply - but if I'm
not missing something, we can just beat it to it.
The XXX comment is just about the if (false ...) change there. If that change
is no longer
WIP, that block can be deleted in the final patch.
I'm also not really clear on what this following code is really doing - I get
what you are aiming
for in principle here, and I think that's the right thing - and this probably
just shows off how
grainy my understanding of mlt's internal machinations still is, but ...
when we get here, b_width is either set to profile->width or meta.media.width,
and I don't see
where either of those might get changed by qtblend previously rescaling, so
it's not clear to
me why it would need to be multiplied by consumerScale, or why that would only
be done
if we are scaling up ...
I have no reason to doubt you had a good reason for doing this - it's just the
one bit I can't
execute in my head and go "yep, that looks like the right thing to me" :)
In filter_qtblend.cpp:
+if (qtblendRescaled) {
+// Another qtblend filter was already applied
+// We requested a image with full media resolution, adjust rect to
profile
+// Check if we have consumer scaling enabled
+double consumer
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #29 from Jean-Baptiste Mardelle --- So I am preparing a patch that contains the fixes discussed here as well as some other aspect ratio issues causing incorrect position / scale when using multiple qtblend filters on the same clip. My work is here: https://github.com/j-b-m/mlt/tree/work/qtblend-fixes I plan to release a testing AppImage for feedback and will then push the changes in MLT if all works as expected -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Ron changed: What|Removed |Added CC||roxane.pet...@gmail.com --- Comment #28 from Ron --- *** Bug 476625 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #27 from Ron --- Created attachment 177237 --> https://bugs.kde.org/attachment.cgi?id=177237&action=edit 'final' patch tested with mlt HEAD -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #26 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #23) > We need to keep the nearest rescale ... in some cases users want such > scaling (when upscaling pixel art for example). Ok, that makes sense. I'm fine with "sacrificing" nearest for that use case. I'd pondered whether a 'none' option might be worth adding if there was a case for not using the QPainter smoothing - but in this light I don't think so - anyone who really cares about smooth is going to use one of the stronger interpolation methods. And with this patch, nearest isn't jittery, it's just stairsteppy, as you'd expect (and for that use case want). > I have also spent quite some time to figure out the issue there. My changes > that introduced the bug, changing b_width and b_height in filter_qtblend, > were part of an optimization. With this change, instead of always requesting > a full frame image from the source producer, we ask for an already scaled > from from the producer. But despite all my attempts, with this technique, it > doesn't seem possible to get smooth zoom, as the producer return images with > integer sizes. Yeah, I think that's the crux of it (and the classic gotya with floating point), there may be a class of transforms you could optimise that way, but in the general case and for continuous small subpixel motion, the loss of precision in the intermediate calculation can add up to much larger errors in the final result. If we're going from integer pixels to pixels, the whole transform has to be done in a single step. > The attached path seems to make it work correctly for me. Could you please > test ? I think we're looking good! Or at least I've run out of ways for now to make something look broken with this one. I'll attach my diff as applied to current mlt head (32abe16667). There's no substantive change to what you did, but has a couple of little extra things I saw along the way: - fixes the file name in the filter_qtblend.cpp header. - merges the tests for setting hasAlpha into a single statement. - drops an apparently vestigial "if (error) return error;" - because nothing changes the initialised value of error before that point. - merges setting hqPainting into a single statement, and adds a comment about why nearest is excluded, so people don't wonder if it can be 'optimised' like I did :) The janitoral stuff can be split into separate commits for pushing to mlt, but it's obvious enough that I've left it all one diff instead of making it a patch series. > And thanks for your patch, my solution is based on your results ! Thanks for the sanity checks and the clues along the way! I'd felt a little guilty about initially handwaving this away as "expected and normal" in the forum before I saw the tests that Roxane had posted and realised it was quite real - and there's only really one way to atone for that :) It's good to get to know this code better, I've been a happy user for quite a while now, and this lowers the bar for looking into some of the other glitches I've been noting on the forum which I keep promising Bernd I'll get around to filing real bug reports for :D -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #25 from Jean-Baptiste Mardelle --- And thanks for your patch, my solution is based on your results ! -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #24 from Jean-Baptiste Mardelle --- Created attachment 177228 --> https://bugs.kde.org/attachment.cgi?id=177228&action=edit fix qtblend zooming -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #23 from Jean-Baptiste Mardelle --- We need to keep the nearest rescale (without the QPainter::SmoothPixmapTransform) because in some cases users want such scaling (when upscaling pixel art for example). But you are correct that "hyper" was not handled correctly. I have also spent quite some time to figure out the issue there. My changes that introduced the bug, changing b_width and b_height in filter_qtblend, were part of an optimization. With this change, instead of always requesting a full frame image from the source producer, we ask for an already scaled from from the producer. But despite all my attempts, with this technique, it doesn't seem possible to get smooth zoom, as the producer return images with integer sizes. So for now, the best option seems to leave out that part, and keep requesting a normal frame to the producers. The attached path seems to make it work correctly for me. Could you please test ? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #22 from Ron ---
And working my way up the tree, here's a patch that makes mlt
0c22797bbcb209f9667d72d4038866f28a624115
scroll smoothly with both hyper and bilinear interpolation (should work with
all, but only testing those two right
now as the representative cases).
diff --git a/src/modules/qt/filter_qtblend.cpp
b/src/modules/qt/filter_qtblend.cpp
index e1d0a8fb..2c2e2759 100644
--- a/src/modules/qt/filter_qtblend.cpp
+++ b/src/modules/qt/filter_qtblend.cpp
@@ -95,9 +95,13 @@ static int filter_get_image( mlt_frame frame, uint8_t
**image, mlt_image_format
transform.translate(rect.x, rect.y);
opacity = rect.o;
hasAlpha = rect.o < 1 || rect.x != 0 || rect.y != 0 || rect.w
!= *width || rect.h != *height;
- b_width = qMin( (int)rect.w, b_width );
- b_height = qMin( (int)rect.h, b_height );
- if ( b_width < *width || b_height < *height )
+ if ( qMin( qRound(rect.w), b_width ) < *width || qMin(
qRound(rect.h), b_height ) < *height )
{
hasAlpha = true;
}
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 07d40619..7da7a5d9 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -88,8 +88,8 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
}
transform.translate(rect.x, rect.y);
opacity = rect.o;
- b_width = qMin((int)rect.w, b_width);
- b_height = qMin((int)rect.h, b_height);
+ b_width = qMin(qRound(rect.w), b_width);
+ b_height = qMin(qRound(rect.h), b_height);
}
else
{
@@ -248,7 +248,8 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
bool hqPainting = false;
if ( interps )
{
- if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
+// if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
{
hqPainting = true;
}
The main things I'm uncertain of in this one is whether *anything* else in
filter_qtblend needs the adjusted value of b_width/b_height (and I've
reintroduced the original bug this was fixing) - but it seems adjusting it
there just causes the inaccuracy and jitter we're seeing.
And I tested nearest interpolation with the hqPainting change and it too is
much smoother - so I think I'd recommend just always enabling hgPainting unless
someone has benchmarks that show it really is expensive to want "worse than
nearest neighbor results" for (maybe?) gaining a little speed.
I'll come back to this again in a bit and look at the next commits up the chain
- but figured I'd share what I know now to see if there's any useful review on
this by the time I'm back to it again (and so we're not duplicating effort
analysing it :)
--
You are receiving this mail because:
You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #21 from Ron ---
Ok, I need to get some sleep, and my source tree is a mess of debug tracing
patches right now - but I believe (after quite some number of wild goose chases
:) that I've pinned down the problem with rescale=hyper in mlt-c2339fc1, and
this little kludge appears to fix it:
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 7817f6e6..8d5900e7 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -222,7 +222,7 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
bool hqPainting = false;
if ( interps )
{
- if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
+ //if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
{
hqPainting = true;
}
It wasn't using hqPainting when interps=hyper ...
With that patch the 22.08.1 version of mlt now seems to "always" do the right
thing with rendering
scripts from all kdenlive versions.
I'll tidy all this up, and look more into the behavior of mlt head soon, but it
does seem to have this same bug.
Is there any interpolation that it really is worth not using hqPainting for?
Should disabling this only be
conditional on the interps == nearest case (so this bug doesn't come back if
newer better interpolation
schemes are added later) or should it just always use 'hq' in every case now?
--
You are receiving this mail because:
You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #20 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #19) > The "rescale=hyper" option comes from the Kdenlive Render widget. Ah, thanks - I see now that's not directly an ffmpeg option, it's handled directly by mlt, though in my build it appears to be using the swscale filter not the gdk one. I'm still tracing through the code to make sense of why rescale="hyper" has an adverse effect even when not rescaling, but interestingly if I run mlt-c2339fc1 (the 'good' one) with each of the rescaler types (but rescaling disabled in the render dialog) then what I see is: - bilinear and bicubic give the same smooth result that not setting rescale= gives. - nearest has a fairly regular stairstep jitter, and hyper has a slightly more irregular jitter. But I haven't yet figured out what code path is different between those if no actual rescaling is being done. (though I'm seeing hints of the rescaler code being entered as part of qtblend ... which maybe explains why the rescale option is always set, not just when "rescaling"?) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Jean-Baptiste Mardelle changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #19 from Jean-Baptiste Mardelle --- Thanks a lot for the progress on this issue. The problem is quite visible with your test project and I can confirm that reverting the filter_qtblend.cpp and transition_qtblend.cpp to the versions before my 2 commit give a smooth result compared to the current version. I will try to understand what happens. The "rescale=hyper" option comes from the Kdenlive Render widget. In this dialog, on the top right corner, you can decide which scaler will be used on render in the "Interpolation" combobox. "hyper" is set when "Lanczos" is selected. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #18 from Ron --- Ok, I had a chance to poke around with this some more - I figured bisecting mlt to find the exact change that introduced this problem shouldn't be too hard - but as usual I learned more than I bargained for :) The initial results didn't make a lot of sense at first, so I've attached another test project which is the same as the first one, implementing the test Roxane described, but as a 1080p native project instead of rescaling from 4k to eliminate any effect ffmpeg rescaling might have ... And interestingly, it appears there are two problems with the newest versions. Re-running the set of tests from scratch with this new project, the first curious thing I saw was that if I created rendering scripts with 22.08.1, 22.08.2, 24.12.0 and the 25.03.70 snapshot posted here for testing, then rendered them with melt from the 22.08.1 appimage, the result was, somewhat confusingly: - Both 22.08 scripts rendered 'perfectly', with the absolute minimum of jitter seen in any test. - The 24.12 and 25.03 scripts both rendered a jittering result, even with 22.08.1 melt. The difference in the later scripts which is causing the appearance of jitter appears to be 'rescale="hyper"' in the options, even when there is no 'scale' option (and rescaling was disabled in the render dialog). If I remove that option, then the render script generated by both later versions renders perfectly with the 22.08.1 version of melt. So from that baseline, I could go back to more sanely bisecting mlt, and the result there confirmed what I originally suspected: The last commit to run this test with "no jitter" is this one: https://github.com/mltframework/mlt/commit/c2339fc146898197b11e13c44692d901ae436245 The next commit after that introduces some jitter: https://github.com/mltframework/mlt/commit/0c22797bbcb209f9667d72d4038866f28a624115 And the one after that makes it a bit worse: https://github.com/mltframework/mlt/commit/d047879e00f03b42587e68652dfe069c45c157aa The mlt version included with 25.03.70 still has a significant jitter compared to the 22.08.1 / mlt-c2339fc1 baseline. I'm still not exactly sure what problem those commits above were fixing, so I'm not terribly confident to propose another patch for mlt offhand that wouldn't re-introduce it - but I'm set up to test this now, so I can pull changes from mlt git or apply patches manually to test against this set of rendering scripts. I'm not quite sure what to suggest for the rescale="hyper" problem ... one obvious workaround at the kdenlive level would be to not include that option if there is no rescaling being done, but if that rescaler is introducing jitter, that might be a bug the ffmpeg folks would want to know about too ... or there may be a better option for render time rescaling that kdenlive/mlt could use? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #17 from Ron --- Created attachment 177145 --> https://bugs.kde.org/attachment.cgi?id=177145&action=edit 1080p native test project -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #16 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #14) > Could you test our latest nightly builds that contain my MLT fixed to confirm > if the issue is better ? Sorry, sadly this doesn't seem to make a notable improvement :( I've attached a project file that implements the test from the earlier bug report which shows this more clearly. The project file is for 22.08.1, but will upgrade cleanly (with an automated fixup) to also work with 24.12.0 and the nightly build you linked to (the reverse isn't true, 22.08 will not open the upgraded project files). I've tested it with all three of those appimages, and it is much noticeably smoother with 22.08.1, and about the same with 24.12 and the nightly. It's a 4k project, but as I noted before the effect is much easier to see when it is rendered scaled to 1080p. I rendered both 4k and 1080p copies for all those versions to compare. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #15 from Ron --- Created attachment 176910 --> https://bugs.kde.org/attachment.cgi?id=176910&action=edit project implementing the test described in bug 476625 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #14 from Jean-Baptiste Mardelle --- Could you test our latest nightly builds that contain my MLT fixed to confirm if the issue is better ? Linux / Windows build are available from here: https://cdn.kde.org/ci-builds/multimedia/kdenlive/master/ Thanks a lot for your feedback -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #13 from Jean-Baptiste Mardelle --- Git commit 37abefbe8401972fc2a1c55c71f67fc5ee25d33c by Jean-Baptiste Mardelle. Committed on 27/12/2024 at 09:57. Pushed by mardelle into branch 'master'. Update mlt with latest fixes Related: bug 476625 M +3-4libs/mlt/mlt.py https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/37abefbe8401972fc2a1c55c71f67fc5ee25d33c -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #12 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #4) > This bug is not so obvious. Trying with your instructions and a random > photo, it was not so noticeable. If you have a project file with an image > that makes it easy to spot the bug it would help looking for the bug. The examples that were provided in this earlier report of the problem show it much more clearly: https://bugs.kde.org/show_bug.cgi?id=476625 (see the files in the drive linked at the bottom) zooming in on a pair of plain coloured rectangles giving a thin border where they overlap makes it much more obvious than zooming in on a detailed image. I also found it was much more obvious when rendered at a lower resolution - eg. for the same test project it was quite clear when rendered at 1080p, but fairly subtle (though still noticeable compared to the earlier mlt) at 4k. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #11 from earmuff.victor...@icloud.com --- (In reply to Jean-Baptiste Mardelle from comment #10) > It seems to me that the result is better, but could you confirm ? Yes, modified is definitely better than the original MLT (presumably current). > Is the second render better ? Yes. > Do you think it was even better with 22.08.1 ? So my clip was 5s and yours is 3s and we had slightly different crops, so I re-cropped and changed duration to 3s (uploaded to the shared drive). I then opened the modified and the 22.08.1 version with VLC and watched them alternate in loop mode. Watching the left edge of the video where the beige door frame slides out of frame, my perception is the 22.08.1 version is a tiny bit bit smoother, but the difference seems imperceptible when not looking for the difference. But take a look at the re-cropped 3s render I uploaded and see what you think. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Jean-Baptiste Mardelle changed: What|Removed |Added Status|CONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #10 from Jean-Baptiste Mardelle --- Thanks a lot for uploading your project and files. I tried a modification to MLT's qtblend rounding code. I attached the project file rendered with the original MLT (what is currently in the AppImage, and another one with my change. It seems to me that the result is better, but could you confirm ? Is the second render better ? Do you think it was even better with 22.08.1 ? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #9 from Jean-Baptiste Mardelle --- Created attachment 176886 --> https://bugs.kde.org/attachment.cgi?id=176886&action=edit Rendered with a rounding change -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #8 from Jean-Baptiste Mardelle --- Created attachment 176885 --> https://bugs.kde.org/attachment.cgi?id=176885&action=edit Rendered with the original MLT -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 emohr changed: What|Removed |Added CC||fritzib...@gmx.net Keywords||triaged Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #7 from emohr --- Please try with the Kdenlive AppImage version 24.12.0 as well. This to exclude any packaging issues https://kdenlive.org/en/download/ -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #6 from earmuff.victor...@icloud.com --- kdenlive 22.08.1 and 22.08.2 are AppImage and 24.12.0 is flathub. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #5 from earmuff.victor...@icloud.com --- I have modified the original 4:3 image to exclude people, but the effect is the same. For the cropped image I used a start zoom of 148% and an end zoom of 151%. I've provided kdenlive files for 22.08.1, 22.08.2, and 24.12.0. https://drive.proton.me/urls/8RFZYFBFZM#zRWYR5b1IFI5 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #4 from Jean-Baptiste Mardelle --- This bug is not so obvious. Trying with your instructions and a random photo, it was not so noticeable. If you have a project file with an image that makes it easy to spot the bug it would help looking for the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #3 from earmuff.victor...@icloud.com --- More details in this thread: https://discuss.kde.org/t/transform-on-zoomed-portait-4-3-image-results-in-jumpy-jittery-unsmooth-motion/26299 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Bernd changed: What|Removed |Added CC||bern...@yahoo.com Summary|Skakiness in Transform |Shakiness in Transform -- You are receiving this mail because: You are watching all bug changes.
