Ken Burns effect is choppy

[Scott Bronson]

This example video has two Ken Burns effects, one zooming to 200,200,-50,50 and the other to 120,120,-10,-30.

Any idea why the picture is jumping around so bad? Video was exported to DVD-NTSC.

[Jonathan Thomas (jonoomph)]

This is a problem with MLT that the MLT developer is aware of. It's on the official TODO list, and will hopefully be solved soon. Thanks!

[Lionel Cordesses (lionel-cordesses)]

Here is the mlt+image sequence+Octave script to reproduce and analyze the "jerk bug" with one simple white picture sliding on a black background, as requested on the forum.

[Lionel Cordesses (lionel-cordesses)]

This tar.bz2 has:
- white720x576.png (the white picture create in The GIMP)
- sequence.mlt
- tst.osp
- jerk.m (the GNU Octave script to analyze the resulting sequence)
- derivative.png (to "see" the jerk)
- tst_001.png
-...
- tst_166.png
Lionel

[Jonathan Thomas (jonoomph)]

Thanks so much for the example. I'm convinced. =) I have forwarded the example to Dan, the developer of MLT. I will post his response here, once I get a response.
-Jonathan

[Jonathan Thomas (jonoomph)]

Dan has located the bug in MLT, and here is his response:
------------------
I located the source of this problem - line 564 of
src/modules/core/transition_composite.c:
               width_src -= 2;

This is within a code block with the comment:
       // Align chroma of source and destination

Basically, the compositor is doing non-interpolated compositing in
packed YUYV 4:2:2 image format. This is a legacy choice based on the
requirements of the original contract under which mlt was developed
(realtime non-animated compositing for a 4:2:2 SDI output device in
2004).

Essentially, this means chroma has half the resolution of the luma
channel and when blending I must keep the chroma channels aligned -
can not blend U with V. So, there are constraints put into place to
adhere to these rules. If I remove the width_src line above, I resolve
the issue for this example, but other tests show an artifact. In the
attached image, there is an additional column on the right-hand side
that goes away when I retain this line.

The only real resolution is to overhaul the composite transition as I
recently did for the affine transition. I plan to do that by the end
of the year. In the meantime, you might be able to use affine
filter/transition for some of your effects - it too takes a
keyframable geometry property, but its behavior is somewhat different.

[Jonathan Thomas (jonoomph)]

I am going to investigate the "affine" filter, and see if I can use it instead of the composite transition. Not sure how good that will work, but I will keep you updated.

Thanks!
-Jonathan

[Andy Finch (fincha)]

Hi Jonathan,

Is there any documentation on the built-in MLT filters? Or even a list of
what's available?

Cheers,
Andy.

On 9 June 2010 06:30, Jonathan Thomas <email address hidden> wrote:

> Dan has located the bug in MLT, and here is his response:
> ------------------
> I located the source of this problem - line 564 of
> src/modules/core/transition_composite.c:
> width_src -= 2;
>
> This is within a code block with the comment:
> // Align chroma of source and destination
>
> Basically, the compositor is doing non-interpolated compositing in
> packed YUYV 4:2:2 image format. This is a legacy choice based on the
> requirements of the original contract under which mlt was developed
> (realtime non-animated compositing for a 4:2:2 SDI output device in
> 2004).
>
> Essentially, this means chroma has half the resolution of the luma
> channel and when blending I must keep the chroma channels aligned -
> can not blend U with V. So, there are constraints put into place to
> adhere to these rules. If I remove the width_src line above, I resolve
> the issue for this example, but other tests show an artifact. In the
> attached image, there is an additional column on the right-hand side
> that goes away when I retain this line.
>
> The only real resolution is to overhaul the composite transition as I
> recently did for the affine transition. I plan to do that by the end
> of the year. In the meantime, you might be able to use affine
> filter/transition for some of your effects - it too takes a
> keyframable geometry property, but its behavior is somewhat different.
>
> --
> Ken Burns effect is choppy
> https://bugs.launchpad.net/bugs/507872
> You received this bug notification because you are a member of OpenShot
> Developers, which is subscribed to OpenShot Video Editor.
>
> Status in OpenShot Video Editor: New
>
> Bug description:
> This example video has two Ken Burns effects, one zooming to 200,200,-50,50
> and the other to 120,120,-10,-30.
>
> Any idea why the picture is jumping around so bad? Video was exported to
> DVD-NTSC.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openshot.developers<https://launchpad.net/%7Eopenshot.developers>
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.developers<https://launchpad.net/%7Eopenshot.developers>
> More help : https://help.launchpad.net/ListHelp
>

[Andy Finch (fincha)]

There is a fix in MLT for this - just not sure what we need to do in Openshot to make use of the fix...

[Marco Hunsicker (ubuntu-triemax)]

Thanks much for your hard work. Please try and fix this with the next release. As of now, zooming in not usable, which is a pity...

[Andy Finch (fincha)]

See commit 412.

[Jonathan Thomas (jonoomph)]

There is now a "Smooth Scrolling" preference, which uses the affine filter in MLT, and requires version 0.6.0+ of MLT (which is not widely available yet). So, it might take a little while before most users can test this feature. But, the scrolling is now silky smooth. =)

[Jonathan Thomas (jonoomph)]

I made this new preference (Smooth Scrolling) require MLT 0.6.0 or greater, otherwise the preference is disabled. This will prevent people from setting the preference, and wondering why everything is still choppy.