Streams Not Locally Caching

What is the name of the domain?

agentpronto.com

Type

Video

What is the issue you’re encountering

We run a video embedded on our website with no controls, preload enabled, loop enabled, mute enabled, and autoplay enabled. We find that the video segments are re-pulled fresh every time the video loops, rather than the browser re-playing the segments already pulled in the last loop. This behavior is observed both on our website and in the CF Videos dashboard where we setup / configure the embed widget. Aside from being a detriment to performance, we’re concerned this is causing us to be billed more minutes than necessary since every loop is now considered ‘play minutes’

What steps have you taken to resolve the issue?

The CF Videos embed javascript code appears to be closed source (?) so we couldn’t dig too far here; just tried a lot of different settings combinations to see if segments would cache on the browser but none did

What are the steps to reproduce the issue?

Upload a video to the CF Streams dashboard, go to the ‘embed’ tab as if you’re going to configure the HTML embedder, activate autoplay and loop, watch your network tab as segments of the video keep getting re-pulled with every loop

Screenshot of the error

I am not able to replicate this with the Stream player on a test loop video I have. I still see each segment reported in the network requests list but after the initial load, they’re coming from disk cache as intended.

Is there a URL where this is hosted, or a video ID you can share? Send in a DM if you’d prefer not to list publicly.

Interesting! No worries with the public URL; it should be in the hero at Best Real Estate Agents & Realtors in Columbus, OH - Agent Pronto

Oddly, I was able to reproduce this by playing that video on your website and in Dash. I cannot reproduce this on any of my videos. Do you have other videos in your account that do this?

We thought it might be file size related or something but have tried a few. Some examples:

  • 4dd03fb9593cc5d57381a6f27adee70f
  • 0d109d72b7f6cb79b230ef68ca44a17f
  • e50bb96eb5a00eb1698f9ddca7ccf486
  • e4a9d00d51076e17f52ef2412d4d310e

They’re similar content but we exported them with different compression styles and file sizes, I think.

I can’t tell yet but there may also be a browser-specific component here — Safari vs. Chromium may be behaving differently