64/128px Block size?

more motion => more artifacts
bigger block size => less "local" motion
less motion => less artifacts

this's all about a balance between motion (smoothness) and artifacts

though 64/128 blocks could be useful for 4k video...

Looking further into the code, it would appear that in src\svpflow1\MVAnalyse.cpp the following code is present on lines 102-107

    if (( ad.nBlkSizeX != 8 || ad.nBlkSizeY != 8 ) &&
            ( ad.nBlkSizeX != 16 || ad.nBlkSizeY != 8 ) &&
            ( ad.nBlkSizeX != 16 || ad.nBlkSizeY != 16 ) &&
            ( ad.nBlkSizeX != 32 || ad.nBlkSizeY != 32 ) &&
            ( ad.nBlkSizeX != 32 || ad.nBlkSizeY != 16))
        env->ThrowError("SVAnalyse: Block's size must be 8x8, 16x8, 16x16, 32x16, 32x32");

Would it break the code in any way to simply add 64, 128 and 256 options? I'm not sure how to compile the code, so I couldn't test it myself.

Fair enough, so it is not a priority for development then?

But I gave you the evidence you want in the OP. I used a GIF in the OP to show that reducing the frame size(in effect emulating larger block sizes) dramatically reduces the artifacts of animated footage, while preserving camera motion interpolation.

Even the "animation guide" on the SVP website recommends 32px block size, albeit with overlap. I don't recommend the overlap as it doesn't improve camera motion and only increases artifacts, but this and my GIF proves the trend that increasing block size reduces object artifacts while preserving camera motion.

The reason few if any anime/cartoon watchers use SVP is because animation is impossible to motion interpolate without introducing awful artifacts everywhere.
It doesn't matter if you argue that "the algorithm does a pretty good job", because one bad frame is enough to turn off most interested people, and you are guaranteed to get a few bad frames in any animated video.

Increasing the block size allows for camera interpolation in the place of object motion interpolation, which delivers only the benefits of SVP with none of the drawbacks.
64 and say 128px block size would in effect create an option where those who like the idea of camera interpolation, but hate the idea of object interpolation, can still enjoy some benefits to SVP.

Plus as you mentioned, the benefits are also present outside of animated footage, as 4K footage is essentially double the frame size of 1080p footage, so it would make sense to have at least double the block size available, and 8K video is obviously going to happen in the distant future, but could be brought into consideration now.

As a stopgap, I suppose it could be possible to analyse a downsampled 1080/720p-540/360p video but then apply the interpolation to the original footage? I'm not sure if this would reduce performance, though I imagine it could be implemented easily.

tehen
or to have other way to smooth only panning shots and only big objects on the screen

this's the correct question!
there're tons of options in motion vectors search algorithm, and with "analyse.main.penalty" options group it's possible to get global motion only

try to set analyse.main.penalty.lambda in override.js file to some higher value, for example 100.0

Bringing this post back from the dead a little, but over the past month I have tried manipulating just about every combination of variable in the override.js, including the settings recommended by chainik.

analyse.main.penalty.lambda actually benefited from lower values, and most other variables barely affected the resulting interpolation at all. Even trying to mask artefacts will create new artefacts in many cases.

The only setting that made a consistent reduction in all the artefacts was increasing the block size to its highest-possible value. Sadly of course this means that 480p video is just about perfect, 720p video has problems, and 1080p video is unwatchable.

At some point I gave up and stopped using SVP, but In the hopes that someone can shed some light on this problem case, I have uploaded a webm of this scene.

http://a.pomf.se/aojlih.webm