There are quite a lot of systems out there with real-time requirements, where the system is not running a real-time predictable operating system - instead the likelihood of a missed deadline are averted simply by over-provisioning. You can get away with murder pretty much this way by just making your processor several times faster than is strictly necessary, provided you don't have any really long pauses in processing (like for instance having to swap in a page from disc). It works well enough most of the time for video playback.
In essence, a job that requires 90% of the CPU time on predictable hardware can often be solved by just throwing faster hardware at it. If the RasPi can do it using 5% CPU, then it's probably fine.
YMMV. Don't do this on medical equipment, space rockets, or self-driving cars.
In the literature, that's often distinguished as soft real-time vs hard real-time requirements. Hard real-time is for when you absolutely cannot miss a deadline without adverse effects (production stalls, equipment crashes, etc), while soft real-time is for situations where missing a deadline is recoverable (like your example, a video renderer would simply skip the current frame and start processing the next frame).
That's funny because I was coming here to say that I built a real-time system running on Windows... for a medical instrument. Windows was fine because speed didn't matter, predictability did, and our latencies were measures in hundreds of milliseconds and Windows has no problem keeping up with that. The only time I saw CPU usage go above 1% was when the instrument was shutting down and had to clean up a lot of objects.
- DRAM refresh
- cache hits/misses