Will CEF be updated?

Hi,

We are using video and html together to create templates, but at this moment it´s “impossible” to sync video and html in a perfect way. It works but we can see some milliseconds between them.

After day’s trying to compile CasparCG with a newer CEF I manage to compile it with CEF 83.4.2 and all the templates that we use work like a charm, the only problem that I found was the html do not have alpha, it appears like a white background. Sorry but I don’t know how to program in c++ just used google search and try and fail, I’m trying to help.
At this moment we have the opportunity of using several html properties like requestVideoFrameCallback and advanced clip-path options. But this only work on version of chrome from +83. The version of casparcg I belive that is 71.
With requestVideoFrameCallback we can manage to put objects at the same time that the video frame, but this do not work with the existing casparcg because it do not have requestVideoFrameCallback support.

This can be a game changer for leaving flash to html.
There is any plan of updating CEF in a near future?

I’ll need to see your code if you want help with this. There are only some versions of CEF that implement OSR (off-screen rendering) correctly, I think 4183 is the newest that will do that. Upgrading CEF always means refactoring some of the existing code, sometimes by a lot.

Regarding requestVideoFrameCallback, I’ve tested that against my method of controlling playback by seeking to frames in the video (using requestAnimationFrame) and saw no performance improvement. I used clip-path extensively for the Premiere Leagure graphics a couple of years ago. Is there something you are using clip-path for that wasn’t available in older CEF?

I was going to spend my time off over Christmas on upgrading CEF and finishing the partial rendering mode I started last Christmas - but didn’t get any time off for this Christmas.

Just let the video play without messing with its playback head and monitor time with:

The biggest blocker with updating cef currently, is that it lacks ‘shared texture’ support. Which makes it slow and made webgl and some gpu accelerated css unusable. https://bitbucket.org/chromiumembedded/cef/pull-requests/285/reimplement-shared-texture-support-for-viz/diff
It might work for us to compile a custom build of cef and use that, but that is not a quick and simple task (from experience).

There were some other issues I began documenting, but stopped trying newer versions due to the shared texture being a blocker https://github.com/CasparCG/server/issues/1235

It depends of what you are doing. If you make for instance a wipe between a video and an lottie you see differences between the video and lottie file using a timer like on @rrebuffo video-freqtimeupdate. Because if you use a timer it will not sync the 2. Because it have a delay of some milliseconds, the video frame appears always before the lottie, that is visible.
We are using VideoFrame.js and changing the lottie on each frame callback.

VideoFrame.js

var video = VideoFrame({
                id: 'video',
                frameRate: 25,
                callback: function (frame) {
                    anim.goToAndStop(frame, true);
                }
            });

Using lottie anim.goToAndStop(frame, true); on each tick.

Maybe with requestAnimationFrame it will work, I will test it.

You can tell us that we can make the wipe with html but we already receive it by after effects so we do not have to recreate the wipe speed an time.

I will ask to create example of what I’m talking. Can not send this graphics. The clip-path I have to get old code, we stopped using because the templates were freezing.

You might also be interested in wipe/sting transitions: https://github.com/CasparCG/server/pull/1042

Yes, that’s a fixed wipe, we use on our templates wipes but wit different speeds and timing, with acceleration not fixed timing.

I’ve made a small video. In the first template we use a frame timer (Video Frame) and it’s visible that the video frame appears before the lottie. In real speed is more visible because etch frame you have 2 movements. On the second is with requestVideoFrameCallback and the 2 appear at the same time it appears like it was just one element. This is done in slow motion just to see the problem.

https://drive.google.com/file/d/1O8slH_F049BNuPpS--GJ788DcLlJWnRg/view?usp=sharing

With timers you can not sync video with other stuff.
Did not have the time to test requestAnimationFrame, can be a solution to this.

This appears to be a perfect example of where you’d want to seek to a frame in the video (which is always paused) and lottie at the same time and use requestAnimationFrame so the rendering is in sync with the framerate of the channel in CCG.

1 Like
Privacy Policy   Terms of Service