We are using Caspar 2.4 on a Windows computer with Black Magic DeckLinks to output HTML5 graphics via SDI.
Our HTML5 graphics solution is Flowics, and unfortunately certain animations will do a single, hard stutter during in or out animations (the animation will stop for a very noticeable 250ms-500ms or so, and then jump forward to catch up). These specific stutters are reproducible, and I’ve verified that they only occur when using GPU acceleration on Caspar, but they do not occur when using CPU-only HTML, nor do they occur when viewing the graphics via a web browser on the same machine. I’ve tried all three options, gl, d3d9, and d3d11, and the behavior on these single, hard stutters is the same.
I have also tested this on a different computer which has a DeckLink in it, and confirmed that Caspar on that computer also results in the same behavior. Both computers have NVidia Quadro cards (although different cards), both are Intel CPUs, and both are running Windows 10.
We would consider using non-accelerated HTML graphics, except Fade In/Fade Out animations on our Caspar server look relatively choppy without hardware acceleration.
Anybody else run into this, or thoughts on anything to try?
How do they behave if you output the Flowics as NDI from casparcg on the same machine. Basically a test if it is CasparCG or Decklink that causes the stutter
Also what Decklink and which firmware do you use. And you have set Windows Visual Effects to “Best performance”
Thanks for the suggestion, I’ll give that a try and get back to you. The fact that this doesn’t happen when GPU Acceleration is off suggests to me that it isn’t a DeckLink problem, but it’s certainly worth checking.
I have whatever the latest firmware is for these models, which I’ll have to grab later (the machine is being used at the moment). I do not have Windows Visual Effects set to “Best Performance”, mostly because of the font smoothing, but I have other unnecessary effects disabled.
Generally speaking, with GPU accelerated HTML everything works pretty smooth overall, but (for example) we have a text scroll that appears from behind a oval-shaped mask that expands to reveal the text, and then when it goes away, the text disappears behind a similar oval-shaped mask that closes over the text scroll. Right about at the beginning of that out animation, the text scroll will freeze for that 100ms or whatever, and then jump slightly to where it should be, and then the animation finishes smoothly. And this stutter is completely reproducible, it only happens at that spot, on the out animation. (there are a couple other animations where it does something similar)
EDIT: Just noting here I probably way overestimated the total time that it stutters, it’s probably more along the lines of 100ms, maybe slightly less. Sorry. But it is very visually noticeable, distinctly noticeable compared to other much tinier stutters which randomly occur on looping graphics.
In my experience, when GPU is enabled, new frames are only grabbed when something change in the DOM. After some time outputting the same static frame, if some animation begins, it stutters as if it gets used to be idle. It’s really odd.
A workaround I use sometimes is to make anything always changing… a moving background gradient or something that requires a repaint.
Based on your description, the issue seems to be related to GPU acceleration in Caspar 2.4 when outputting HTML5 graphics via SDI using Blackmagic DeckLinks. The stutters occur during specific in or out animations and are not observed with CPU-only HTML or when viewing graphics directly in a web browser.
I did a test with the screen consumer, and was still able to observe the stutter, so it doesn’t appear to be related to the DeckLinks.
@rrebuffo That’s interesting, and in a way this is what it feels like… but the odd thing is the times when we’ve observed it it’s been with other things already moving on the screen. For example, in this case, the text scroll is already happening, and that’s the reason why we can observe the stutter – the scroll very briefly pauses then jumps forward, and then the animation finishes like normal.
There’s an animation package available on Flowics which we’ve tested around with, and that’s the one in particular where we really noticed the stutter, and it’s visible towards the end of the full animation in that one, which is super odd. So in that case things have already been moving a bunch, but then the animation slows towards then end and stutters hard once.
About testing with the screen consumer: when we test these things we cannot take it as a reference point for ‘smooth playing’, because more often than not the stutter we see is from the consumer itself, and not the video or the html template.