I understand mp4 playback won’t work in the HTML producer because of the underlying missing support in CEF. However there are builds of CEF that include the mp4 container format (Nik build from memory). Is there a particular reason Caspar isn’t using a build supporting mp4, or is it possible to add this support?
Thanks
Going a little bit sideways on the answer, but couldn’t you achieve the same outcome by playing your html template on top of a casparcg video layer?
Yes but!!! You loose the ability to manipulate the video to the extent that the template can. The idea is in HTML templates, you can break video into sections and edit them independently like this example or this one. And it gets even better with video and Canvas!
Some HTML sources I want to utilise have embedded video and therefore I unfortunately can’t manipulate the video into different layers. One example is social media. VP8 isn’t as common as google would like it to be 
I think the main reason for not supporting mp4 is that is how the default builds of CEF are configured. If we want to enable that then that will require one of the maintainers to build it every time we want a new version.
It is a fairly simple task if all goes well, but it takes quite a while.
That said, I am hoping this can be done for 2.3
Good to hear. Would love to see this implemented.
Hi everyone,
As we push the boundaries of what’s possible within the CEF producer, we are hitting a significant bottleneck: the lack of native MP4/H.264 support. Currently, we are often forced into heavy workarounds—converting assets to WebM (VP8/VP9) or using high-bitrate image sequences. While these work, they introduce friction into modern production pipelines for several reasons.
The performance gap is most evident when using video masking or multiple layers in an HTML template. While VP9 is available, its decoding is incredibly resource-heavy compared to H.264, where hardware acceleration is ubiquitous and highly optimized. Native MP4 support would unlock massive efficiency, allowing for rock-solid stability and smooth playout of complex, video-rich templates that currently spike CPU usage.
Beyond raw performance, this is about production velocity. Since 90% of industry assets arrive as H.264, eliminating the mandatory transcode-to-WebM step is vital for fast-turnaround environments. This update would future-proof CasparCG as the undisputed leader for web-based broadcast rendering.
thanks
You are right, it would be a good improuvent.
That said, what I am wondering - just out of curiosity - why do you need to convert incoming H264 videos to WebM? Can’t you not just play the video with the normal FFMPEG based player embedded into Caspar?
Based on a few quick searches I think the main issue around enabling hardware decoding support is the complex licensing rules in H.264 and even more complex rules in H265. H.264 has some patents that do not expire until 2030. Licensing conditions and patent expiry dates also vary by country.
My searches suggest CEF can be compiled with H.264 decoding enabled, but the default setting of the compile control flags is hardware decoding disabled.
Stand-alone web browsers can call operating system modules in Windows or MacOS to use hardware supported decoding. Microsoft and Apple have paid the relevant licenses. I was unable to find any statements about hardware supported decoding for any of the Linux implementations. I think we would all want the Windows and Ubuntu versions of CasparCG server to remain matched.
Enable proprietary codecs with OS decoding support only · Issue #3559 · chromiumembedded/cef · GitHub gives some reading/background
But as I see it, we are already shipping support/decoders for h264/h265/whatever as part of ffmpeg for general video playback, so if there are any licensing issues, enabling support in CEF doesnt have any impact on that.
For me, this is simply a case of having to build CEF from source, to enable this. While quicker than it used to be, its still a tedious process
Looking at the past years of releases of Caspar we can see that the CEF version used doesn’t change very frequently.
I was forced recently to go through the tedious process of building it and man, I feel you. I don’t want to go through that again if I don’t need to. Whole days were wasted on that.
That said, if that process would be required only every 6 months or so, that burden gets a little lighter.
While the FFmpeg producer is great for full-screen playback, it cannot handle integrated dynamic logic. Using video directly in the HTML allows for:
- Using CSS Flexbox/Grid, video elements can automatically resize or crop based on dynamic text length. Doing this via AMCP requires calculating pixel coordinates and sending manual MIXER commands, which is difficult and there is a chance of misalignment.
- HTML provides ontimeupdate and onended events to sync graphics to video frames instantly. Achieving this with the FFmpeg producer requires parsing heavy OSC data streams to get the playback state.
- It allows for “punching holes” in video for stylized PiP windows or complex masking (like text-on-video clipping).
- In HTML, you can apply real-time filters (Blur) or you could dynamically change a video background’s color to match a team’s branding based on live data.
To build data-driven Templates, the video must be an element in the DOM, not just a separate layer underneath it."
I understand all of the above. But do you regularly get to change the videos inside the HTML template? Are they somehow dynamic? What is the use case?
Templates where you need live video or video coming from an already in place H.264 workflow. FFmpeg is excellent for playout but integrating content like news clips into complex templates is quite hard. Live video is on its own a very complex case on Caspar. The focus on frame accuracy doesn’t play nice with latency-sensitive content.
Like @noumaan brought up, loading a video inside a video element in HTML is trivial. And you get to do all kinds off CSS trickery like dynamic clip-paths, filters and blending modes with a couple of lines. With AMCP you can do some of that but you have to send a bunch of commands every single time to accomplish that. And most of the time it’s out of sync.
Some visual effects are plain impossible, like blurring a background or using the video as a 3D texture.
In my specific use case, I needed to convert a lot of live feeds to WebRTC (VP8) to show up in a very complex template but I hit a brick wall when the servers couldn’t keep up with the encoding so I switched to NVENC instances but quickly remember that CEF lacks H.264 codec support.
Interesting, I never tried to do anything like that. - And, understand me right, I am not against integrating H.264 into Caspar, I just wanted to understand why.