Lottie crawl is stuttering

I built up a ticker-crawl in AfterEffects (1080p50), exported everything by the bodymovin plugin and integrated it to an html-template.

When playing my template on the decklink-output the crawl is continually stuttering (or is it a flicker?)
When playing my template in the chrome browser without casparcg everything works fine.

I’m using casparcg server version 2.2.0 stable
The configuration of my caspar-channel is 1080i50

In the attachement there is an example which plays the lottie-player after DOMLoad with the default text.

Any suggestions what could be wrong?

Or is there another rocket proof technic to get smooth ticker-crawls in html-templates?

sometimes I have the same issue, it seems like that CasparCG’s html performance need to improve, especially when you have gradient transparent html template.

Yes it seems to me that html producer lacks performance a bit.
Sometimes it takes very long that html templates are loading.

I had best experience to build templates with greensock library (in flash and html). But pure scripting isn’t a well tool for designers to build up animations. It really lacks a nice editor similar to after effects. And lottie isn’t really ready for complex dynamic graphics now. It still needs heavy javascript tweaking to build up shapes whos length depend on dynamic text. Or I struggle with dynamic ticker-graphics or there are problems with textareas to keep individual kerning of letters and so on. It would be a great effort if lottie accepted all expression objects from after effects. But it doesn’t.

Flash is dead. I sometimes think with its editor and integrated action script possibillities it wasn’t really that bad at all.

Try using the 2.3.0-rc and add the following to the config


This may not work well without an nvidia gpu, which is known limitation and why it is not enabled by default

I did enable-gpu in 2.2.0 and in 2.3.0-rc.

In 2.2.0 there is no difference, it works but it’s not scrolling smooth.

In 2.3.0-rc the bodymovin player doesn’t show up. It throws the event DOMLoaded for my bodymovin-animation but it’s not showing up the animation in the casparcg output.

If I debug with the remote debugging in chrome the animation shows in the browser.

Is there a change in the html producer of version 2.3.0-rc?

In server 2.2.0 I’ve tested with an output 720p5000. In progressive mode the ticker runs smooth. But I need 1080i5000 output.

If it runs smooth in progressive mode you need to change the speed of the crawl to make it look good in interlace mode.

Or there is a performance issue, I think 2.2 had started doing everything internally as progressive so even if your channel is 50i the internal processing is 50p. 1080p50 is more than 2x the size pr. frame than 720p50 and is rendered twice per frame for 50i.

But also, like didi says above, the golden rule of tickers and other items that have continuous motion is to have a fixed pixels pr. frame move.

If watching the computers parameters cpu, ram, gpu then there is much headroom. I don’t think it’s a performance issue. But I get a clean crawl also when playing 1080i5000 in a virtual channel 2 and routing this one to channel 1 (interlaced, too) with the decklink output. I don’t really understand why.

And it only goes the right way if I use subframes enabled in the lottie player.

That is weird. You say, that a virtual interlaced channel routed to a Decklink interlaced channel makes the problem go away? How does it look? Like a doubled text? Showing everything twice? Then it would be a field sequence error That would then result in an issue on GitHub.

Yes, interlaced channel to interlaced channel did it for my lottie-crawl. There is no doubled frame then. The letters are clean. Before there was a constant flickering in the text and a bit of stuttering when scrolling from right to left. It must have been something with the field sequence. But playing interlaced video seems to be good no matter which channel I choose.

As I wrote on top of this topic you could try with this example:


It works with no parameters it just plays as you call it.

If whitout the route trick it is a kind of interlace error, that can not be solved by changeing the speed of the crawl, it is probanly a bug in the way the HTML consumer handles interlace video.

I am in vaccation and have no access to anything except my iPhone, so I can not see the error anyway. :weary:

This sounds like it is caused by https://github.com/CasparCG/server/issues/1165 which should be better in 2.3.0-rc

I tried it with server 2.3.0-rc on windows 10. Now it works pretty well. thanks for your advice!

Privacy Policy   Terms of Service