https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #21 from Ron <kdenlive-b...@contact.dot-oz.net> ---
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.
