Playlist & Media Performance
In Ouva, a playlist is an ordered set of activities (3D scenes), not a video playlist.
Each playlist item points to a scene route (for example /scene/fish or
/scene/four-seasons?stage=autumn).
Companion messaging can also include image, video, and audio assets. Those media assets are separate from the scene itself and follow different loading behavior.
How Playlist Content Loads
Section titled “How Playlist Content Loads”| Content type | Loading behavior |
|---|---|
| Playlist scene items | Loaded one scene at a time as navigation moves through the playlist |
| Scene assets (models/textures) | Loaded when the scene opens; not bulk-downloaded for all upcoming scenes |
| Companion message images/audio | Preloaded from playlist message sequences when sequence data is available |
| Companion message videos | Preloaded in the browser using HTML5 video preloading with a concurrency limit of 2 |
For companion message videos, Ouva attempts to preload and then reuse video elements for playback when available.
Ouva does not bulk-download an entire long playlist to local disk before playback. Loading is incremental, with bounded preloading for companion videos.
Caching, Storage Location, and Eviction
Section titled “Caching, Storage Location, and Eviction”Media and assets can be cached in two places:
- Browser-managed HTTP cache (subject to response headers and browser policy)
- In-memory runtime caches used by the app while the page is open
Current behavior:
- Scene loader caches are actively cleared on scene transitions to avoid long-run cache growth during playlists.
- Companion video preloads are kept in an in-memory map for the browser session.
- Local storage is not used for scene/video payload caching.
Eviction behavior:
- Scene asset caches are explicitly cleared during scene cleanup.
- Browser HTTP cache eviction is managed by the browser.
- In-memory companion video cache remains for the life of the page session and is released on refresh/restart.
Performance Impact for Longer Playlists
Section titled “Performance Impact for Longer Playlists”Playlist length by itself is not the main performance driver because only one scene is active at a time and scene resources are cleaned up between transitions.
Performance is mainly affected by:
- The complexity of the current scene (geometry, effects, lighting)
- Output resolution and display configuration
- Video decode workload when companion videos are used
- Total size and count of companion media preloaded for the playlist
As video count and average video size increase, RAM usage and decode load may rise during preload/playback windows. CPU/GPU pressure is driven more by current scene and active media decode than by raw playlist item count.
For very media-heavy messaging, startup/preload time and RAM usage can increase.
Recommended Practices for Long Playlists
Section titled “Recommended Practices for Long Playlists”There is no single hard maximum that fits every deployment, because practical limits depend on hardware, display resolution, and media size.
Recommended approach:
- Build playlists around scenes first; add companion videos selectively.
- Keep companion videos short and web-optimized.
- Reuse media assets across sequences instead of attaching many unique videos.
- Prefer image/audio messages when video is not necessary.
- Validate the longest expected playlist on target kiosk hardware before production.
- Define a deployment-specific cap for companion video count after UAT baselining.
- If you observe degradation, split very large programs into smaller playlists.