Hope you are fine.
I have some question regarding video integration in my website with DatoCMS and MUX.
What I an used to do is splitting videos in 2 categories:
Illustrative videos: used as background for Hero banners for example. They are short videos (under 10s) and played with native player using progressive download, usually webm format, at least.
Informative videos: more than 10s videos (let say more than 1 minute), used directly in a Video section with a custom video player and played with streaming technology ( HLS support)
With DatoCMS, I would like to have your advices regarding the best strategy and performance, and budget.
While I am quite convinced that for informative videos, HLS is the way to go, as far as I understood, for my āIllustrative videosā topic, your advices would be different from what Iām used to do ā¦ and go also with streaming?
According to me, streaming means having a video player library to be loaded ā¦ increasing page weight ā¦ loading time ā¦ decreasing webperf.
Could you please tell me what is your strategy for my 2 use cases ?
This is a great question, and something that several of our customers have wondered about.
Unfortunately, I donāt think there is a perfect answer for this situation Itās a common enough use case, but also a challenging one to implement due to the tradeoffs between design/marketing and the technical considerations of end-user UX.
Every video maker of course wants their beautiful artwork to autoplay at high resolution in near full-screen as soon the user sees the page (what better way to make a first impression?), but thatās not always easy on an Internet with so many different device types, viewport sizes & orientations, and connection speeds
What some of our customers end up doing is, as you said, sacrificing the HLS stream and making a short clip on a loop that they directly serve as a MP4 file. However, thatās not without its own drawbacks:
If you serve it directly from us (i.e., through datocms-assets.com), it will very quickly eat through your bandwidth allowances, because every visitor ends up downloading that whole file (or as much of as they can, before they navigate away). You pay for the bandwidth charges even if they only look at it for half a second and then scroll past it.
Some customers will rehost that one video on another CDN as a static asset, especially if their frontend hosts offers more or cheaper bandwidth than we do. You might want to check your host to see if putting that on their CDN would be cheaper.
Regardless of where you host it, you might also need to check your video tag settings (lazy load vs preload, etc.) to make sure that video doesnāt block any other content from downloading. It wouldnāt be great if they were prevented from navigating if their browser was using all the bandwidth to download the video instead. In your own browserās console, you can throttle down your connection speed to 3G/4G to see what itād be like on a slower connection.
For the video itself, you might have to sacrifice some visual fidelity (i.e. encode it at no more than 720p or 1080p, rather than 4k) and/or trim it to a short loop (3-5 seconds)
Determine if you want to use that same video hero for mobile viewport sizes
Alternatively, sometimes customers also decide maybe their video isnāt THAT important, and just make an animated slideshow type thing that cycles through 3-4 pictures instead of a whole video.
Sorry I donāt have a better answer for you! Itās not something Iāve seen a perfect, one-size-fits-all solution to yet, and we donāt have an official guide on the topic because thereās no foolproof way (that I know of) to do this well without sacrificing something (usually performance and UX).
My personal opinion (i.e. me as an individual developer only, not representing DatoCMS officially) is that usually the visitor doesnāt care about this to warrant the performance degradation, and Iād try not to use an automatic video at all if possible. But many times itās hard to convince your designers/marketers/bosses of that, so youāre left with no choice but to find an awkward compromise between the video and performance. Depending on your target audience (i.e. are they typically on computers and have fast connections), it may or may not matter. Maybe sometimes itās worth making them wait a few seconds for an extraordinary first impressionā¦ but thatās up to you and your visitorsā¦
BTW, I also posed your question to Mux (our CDN partner) to see if they have any better feedback for you. They are the video experts, after all Iāll let you know if I hear back!
As you can see, Iām in a 1920/1080 format, and 25s, so, it can be improved for background usage.
So, in my opinion, if we want to rely on a fully DatoCMS experience, I would go with this:
Short videos: Progressive download with a webm encoded version of the video
Long videos: Use your HLS version of the video.
That would be awesome!
I donāt know Mux so well and if itās able to resize videos on the fly (like CLoudinary does) but it could be an alternative to generate on demand resized video versions of the selected one when passing query strings onto the video URL, even more with the comeback of media queries on video tags.
Thanks for your answer.
Hope that having a webm version of the video will be listened.
Iām checking with Mux to see if they support cloud conversion of MP4 to WebM (didnāt find anything in their docs). In the meantime, though, you can always do the conversion on your own and upload the WebM to Dato. Example using ffmpeg:
Hey guys, I work at Mux so thought Iād chime in with whatās possible with Mux for this sort of thing.
We donāt produce WebM files currently but we do have a static renditions feature that gives you access to MP4 files of your assets as an alternative to HLS for scenarios like this (in our docs under āenable static mp4 renditionsā, it wonāt let me post a link in this message) [Moderator note: Added link]. We generally recommend using these for use-cases like short looping backgrounds and have many customers using them for this.
Depending on what you intend to support I would be careful relying on av1 as the codec. Safari specifically until not that long ago couldnāt play it. I believe anything before the iPhone 15 Pro canāt play it as Apple limits it to devices with hardware decoding. WebM with VP8 has broader support though.
Thanks for chiming in, @AdamJ_Mux! Glad to have you here
For DatoCMS customers, the static MP4 renditions are enabled by default. The URL format is: https://stream.mux.com/{muxPlaybackId}/{low|medium|high}.mp4
You can get the muxPlaybackId either through our UI (just click an asset in your media library, and the playback ID is in the metadata at the bottom) or via our APIs.
The low, medium, or high determines which (fixed) resolution MP4 you get. We donāt support their capped-1080p.mp4 or audio.m4a parameters.
This gets charged the same as a DatoCMS āstreaming minuteā, same as a HLS stream.
PS Sorry about it not letting you post the link. I manually added it for you, and tweaked the settings so that shouldnāt happen again.
Thanks for your answers. @AdamJ_Mux, I donāt really agree about your recommendation on using mp4.
From a webperf point of view, and webm VP9 support, I would much more rely on this format.
I know that it is not supported by all browsers but, with the magic of video tag in HTML, you can set multiple sources and the browser will take the one is able to play: https://web.dev/learn/performance/video-performance
Webm file are much more smaller for videos than mp4 ā¦ I mean short videos ā¦ and suits very well for this use case. Video quality can be adapted and itās not 100% crucial when used as background.
@jesperās advice is great for thumbnails (which are typically smaller in dimensions and may have lower framerates), but for looping background heroes (which are typically high-resolution and high-fps), I donāt know if animated WebP encoding will be efficient enough (i.e., whether the compressed output is small enough to serve and cache at a typical heroās resolution and frame rate).
Itās a common enough use case, but also a challenging one to implement due to the tradeoffs between design/marketing and the technical considerations of end-user UX.
Iāll let you know if I hear back!