When loading MP4 files from R2 they’re not being downloaded “in chunks” as expected
What steps have you taken to resolve the issue?
I have been using an R2+Sippy, from which files are accessed through a domain URL registered with Cloudflare since September/2024 to host MP4 and HLS videos from a certain platform. Nothing has changed in any R2 or domain configuration in the last three months.
However, since the beginning of January/2025, MP4 videos hosted on this R2 (no matter if new ones or old ones) have started to present an anomaly within the players from web and native Android applications: the video has to be completely downloaded to the device before it can be played. On web it happens even with the default MP4 player on Chrome, Opera and Firefox.
I tested the videos in other environments with direct access (such as, for example, directly from AWS S3) and when accessing the direct URL the problem doesn’t happen.
If they’re not uploaded as “chunks”, how else should they be served and downloaded?
Cloudflare R2 doesn’t make “chunks” by default. It’s a single object, since S3.
Since serving from R2, I’d suggest to split it with ffmpeg into smaller chunks as .ts files and serve as .m3u8 list to create a video playback which would work perfectly fine for the end-user without lagg (stuttering, etc.) while skipping some frames or minutes of watching (which could take longer).
I doubt anyone viewing such video(s) would have great experience, especially when they start to “skip” from X to Y time and it starts to lagging.
Also, are you caching them as well?
The 1GB video needs to be downloaded each time for each of your visitor(s), which might be quite a “heavy task” if more than 100MBs.
I don’t know which Web browser does differently. Neither this depends on the player itself. It’s not YouTube. Otherwise, I’d use Cloudflare Stream for such case.
Might be you’d have to add the missing HTTP headers for cdn.cleanyogaclub.com.hr to create such behaviour as accept-ranges: bytes with Transform Rules → Modify Response Headers:
Otherwise, might give it a try using a Worker:
Keep in mind:
Cloudflare R2 implements the AWS S3 API, and as per the AWS S3 object documentation: Amazon S3 doesn’t support retrieving multiple ranges of data per GET request.
Maybe you have to disable/bypass the cache for such file(s)
Nevertheless, might want to lookup on these forums if not found, please create a new topic and add it into the Feature Request Submitting & Feedback category.
fritex, thanks for your answer, but it has a lot to do with “chunked downloads” due to what I believe is a lack of understanding. I ended up finding the solution and I’ll explain it here:
When you open an MP4 file in an internet browser a “web player” is used. This web player allows the video to start when the video’s metadata arrives. The correct thing is for this metadata to be at the beginning of the file, which allows the video to start promptly and to load gradually as the user watches it. What’s happening to me is that many of the videos were encoded with errors and the metadata is at the end and, then, the web player is able to start playing it only when the file is full downloaded. The same happens on Android apps, btw.
All I have to do is move this metadata to the beginning by converting it using the following command line:
When I try to change an MP4 to a moment ahead of the current time in the player it doesn’t do it
What steps have you taken to resolve the issue?
I have MP4 files in an AWS S3 that are transferred to a Cloudflare R2 via Sippy integration.
The integration works, but there is a problem where when trying to fast-forward the video, it does not load correctly, as expected. This loading works normally if the video is loaded directly from S3.
The target video is already fully loaded to R2 and listed as type: video/mp4 . It was fully loaded to R2 through Sippy yesterday (the original video file is from 2024)
“heavy task” if more than 100MBs.