Review Session Performance Degradation with Large Playlists - Browser Memory Limitations

General
1

I’m experiencing significant performance issues when loading large playlists in AYON’s web-based review sessions. The review player starts loading smoothly but progressively degrades in performance (RAM usage, CPU, decoding speed) until becoming unusable or crashing with “Out of Memory” errors.​

Environment:

  • Browser: Chrome/Firefox (tested both)
  • System: 64GB RAM, NVIDIA Quadro K2200
  • Playlist Size: [number of shots] shots/videos in MP4 format

Issue Details:

When creating a review session from a List with many shots (approximately 63 videos), the browser-based player exhibits the following behavior:

  1. Initial Phase: Loads quickly, memory usage climbs normally
  2. Degradation Phase: After loading 3 GB of data, performance progressively slows
  3. Failure: Eventually hits browser memory limits (~2-4GB in Chrome) and shows “Out of Memory” error, or continues with severe performance degradation​

Observations:

  • Chrome crashes with “Aw, Snap! Out of Memory” error despite 60GB+ system RAM available​
  • Firefox handles it better (doesn’t crash) but Data Decoder process plateaus at ~7GB and performance degrades significantly​
  • The issue is not hardware-related - system has abundant RAM/CPU available
  • Smaller playlists (10-20 shots) work perfectly
  • Performance degradation is progressive, suggesting memory leak or inefficient resource management in the review UI​

Browser Limitations Encountered:

Chrome/Edge have hard per-tab memory limits (~1.8-4GB) that cannot be bypassed. Firefox can use more memory per tab but still shows progressive slowdown when loading large playlists.​

Current Workaround:

Splitting large reviews into smaller batches of 10-20 shots works fine, but this disrupts the review workflow when directors/supervisors need to see full sequences.

Request:

Could the AYON team investigate optimizing the review session’s video loading strategy for large playlists? Possible improvements:

  1. Lazy loading: Only decode/buffer videos near the current playhead position instead of preloading entire playlist
  2. Memory management: Release decoded frames for videos not currently visible in timeline
  3. Desktop review client: Consider developing a native desktop review application that bypasses browser memory limitations (similar to ShotGrid’s RV or ftrack’s desktop player)​
  4. Playlist streaming: Stream video metadata without loading all videos into browser memory simultaneously

Questions:

  1. Is this a known limitation of AYON’s web-based review system?
  2. Are there any AYON server-side or client-side settings to optimize review session memory usage for large playlists (e.g., limiting preload buffer, lazy loading configuration, video queue limits)?
  3. Is there a way to bypass browser memory limitations when using AYON review sessions? Are there any recommended browser configurations or alternative approaches?
  4. What do other studios typically do when reviewing large sequences (50+ shots)? Is splitting playlists the standard workflow, or are there better strategies?
  5. Are there plans to develop a native desktop review application for AYON that would bypass browser limitations entirely (similar to ShotGrid RV, ftrack Desktop Review, or DJV)?
  6. Can AYON review sessions integrate with external review tools that might handle large playlists better? For example, could review data be exported to SyncSketch, ftrack, or other platforms that have desktop clients?​
  7. What is the recommended maximum playlist size for web-based review sessions? Should we establish studio guidelines for batch sizes based on this limitation?

This appears to be a fundamental architecture issue with browser-based video review at scale. I’d appreciate any guidance on best practices or upcoming features that might address this workflow bottleneck.

Thank you for your consideration.

2

Thank you for all the details.

We’re actually doing a large push this month to get the review sessions to the next level. We’ve been gathering feedback for past 6 months since the initial release and you can expect a few new releases in short succession now.

But to answer your questions directly:

  1. It was a choice in the first iteration to prioritize a very smooth playback of the whole timeline, so you can scrub anywhere instantly once the media is loaded. But it was fully intended to be improved based on usage feedback.
  2. not at the moment. The biggest difference is of course how optimised your media itself is for web payback.
  3. Not a whole lot that can be done there right now.
  4. Mostly reviewing per sequence from what we’ve seen and larger review are then loaded into editorial, RV or similar place.
  5. We’re currently full steam ahead on adding review sessions integration with openRV and eventually other system. OpenRV will be the first out though.
  6. You could certainly get the done fairly easily. the review sessions have a full API support, however, by that time, I’m pretty confident this issue will be resolved.
  7. I regularly demo review sessions with 50-60 clips 1080p, .mp4

In general though this is very much a question of lesser evil and we might expose some options for user preference. Load everything and have very responsive scrubbing, or lazy load around the playhead, but sacrifice fast scrubbing to some extend. One way or another we’re on it already.

1 Like
3

Thank you so much for the detailed response and for prioritizing this! It’s great to hear that review sessions are getting major improvements this month.

The OpenRV integration sounds like the perfect solution for our large playlist workflows - that’s exactly what we need for handling 50+ shot sequences without browser limitations. Very excited to see that coming soon.

I really appreciate the transparency about the design tradeoff between instant scrubbing vs. lazy loading. For our use case, I think having the option to choose (as you mentioned) would be ideal - perhaps a user preference or playlist setting where we can select:

*Preload all (smooth scrubbing) for smaller reviews
*Lazy load (memory efficient) for large sequences

The current instant-scrubbing approach works beautifully for 10-20 shots, so having that flexibility would cover all scenarios perfectly.

Thanks again for the quick response and for actively gathering feedback. Looking forward to the upcoming releases - it sounds like you’re already addressing exactly what the community needs. The fact that you’re hitting 50-60 clips in demos gives me confidence this will be solved soon.

Really appreciate the work the AYON team is doing!

4

I guess it’s not about the number of shots as much as it’s about the reviewable size.
Could you elaborate more about the specs of your reviewables (like length, width, height and file size) and how the reviewables were generated (e.g. were they generated via Extract Review)?