Smooth-scrolling text?

[Die Kuh macht Muh]

Suppose I want to add scrolling text to a video, like the credits at the end of a movie. If I use animate() and subtitle(), the motion can be jerky, depending on the scroll speed. If, for instance, the text moves 0.8 pixels per frame, it will move up one pixel for 4 frames, then pause one frame, then move for 4 frames, then pause, etc.

Is there a way of producing scrolling text that doesn't have this problem? I suspect this would have to be done using a subpixel algorithm and / or anti-aliasing.

Has anyone seen a filter that can produce smooth-scrolling text?

[wonkey_monkey]

The simple answer would be to scale everything up vertically 4 or 8 times, then scale back down after applying the (suitably scaled) subtitles. I'm not sure what effect this would have on speed.

David

[check]

your best bet would simply be to move the subtitles at an equal number of pixels per frame. If this isn't possible, you can do as suggested above and upscale the video before applying the video. You might not want to scale down as well, depending on your requirements.

[foxyshadis]

If you feel like learning SSA, you can use the Banner/Scroll style with TextSub(). Or also SSF, which has all kinds of animation capability, but isn't fully implemented. Supersampling will be easier, but probably slower than the text subtitling.

[hanfrunz]

you can use the crop-parameter in the resize filters to "move" the image in steps like 0.8. use the search function, there was a thread in this forum a while ago.

EDIT:
i found the thread:
http://forum.doom9.org/showthread.php?t=93915

[IanB]

When using Animate the graph is recompiled every frame, i.e. for each compile only 1 frame is rendered. If speed is important Lanczos is not the resizer to use.

To calculate the required lookup table it evaluates 2 Sin's per pixel tap, which is quite slow. i.e. Lanczos3 uses 6 taps per pixel so for a 720x480 image there will be 720*480*6*2= 4147200 Sin calculations.

Bilinear and Point would be the fastest to compile but quality can be marginal. The Splines are very quick to calculate with only 3 multiplies, 6 adds and some if's per pixel tap, and have good quality. The Bicubic calculations are a little bit more complex.

Note this is compile time we are talking about here. All the resizers once compiled run at a speed purely related to the number of taps used.