1 fps and 2 fps seem to work well across a wide set of devices, with file size being the main limiter for higher fps, especially with GOP 1
Smaller GOP sizes (GOP 1) make the videos faster to scrub and seek through, but they don’t compress as efficiently
1 or 2 fps and GOP 1 provide a good balance between seekable frames and scrubbing, with 3fps still being an option
Context
We’re using ArcGIS's SceneView to render georeferenced videos tied to climate data. One of the challenges is optimizing performance across mobile devices, so we tested videos with different frame rates (1 fps, 2 fps, 3 fps), while sticking with a GOP size of 1 for good seekability as we're manually scrubbing the videos.
The goal: smooth scrubbing, small file sizes, and wider device compatibility
1 fps, 2 fps, and 3 fps are viable, but 3 fps is about where performance might become an issue on certain devices or network environments.
:information_source: Additionally, performance also depends on SceneView's internals, which we don't have access to. This could vary across devices and may limit optimization efforts further.
Key points
We’re using requestAnimationFrame to sync video frames with the line chart (manually scrubbing the video)
Higher fps means bigger files. But even at 3 fps, it still performs well enough on modern devices
Performance heavily depends on the browsers SceneView sdk and how well it handles video playback across different devices, which could impact performance in ways outside of our control
Problem
Higher frame rates (like the original 12 fps) led to a bigger file size especially if encoded with GOP 1 (used for better video scrubbing). This will affect performance, especially on mobile. Scrubbing seems laggy, and the videos took some time to load. Dropping to 1 fps, 2 fps, or (max) 3 fps reduced the file size and load times, making scrubbing smoother across devices.
Performance tests
Configurations tested
Configuration
Frame Rate (fps)
GOP
CRF
Compression
Performance Outcome
Original (12fps)
12
1
N/A
Uncompressed
Big files, sluggish scrubbing, not great.
Optimized (1 fps)
1
1
18
H.264 (Compressed)
Best performance, smooth scrubbing, smallest file size
Optimized (2 fps)
2
1
18
H.264 (Compressed)
Good performance, slightly bigger files, scrubbing still smooth
Optimized (3 fps)
3
1
18
H.264 (Compressed)
Decent, bigger files, but may start to become sluggish or too large on certain devices
Tested on LambdaTest emulator. Actual device performance may vary.
Note: These tests were performed on LambdaTest emulators. Performance on actual devices may differ and potentially be more optimized.
Summary
1 fps and 2 fps perform well. 3 fps is still an option, but it starts to push the limits with our approach, and performance also depends on how SceneView handles it on certain devices, which we have no internal control over.
Compression and seekability
Does compression affect seekable frames?
Short answer: Yes, it can, if it changes the GOP size
Why GOP is set to 1
Setting GOP to 1 ensures that every frame is a keyframe, so that the "frame seeking" which we do by manually scrubbing the video works smoothly and is fast. There's a nice explanation in this thread
TL;DR
Context
We’re using ArcGIS's SceneView to render georeferenced videos tied to climate data. One of the challenges is optimizing performance across mobile devices, so we tested videos with different frame rates (1 fps, 2 fps, 3 fps), while sticking with a GOP size of 1 for good seekability as we're manually scrubbing the videos.
The goal: smooth scrubbing, small file sizes, and wider device compatibility
1 fps, 2 fps, and 3 fps are viable, but 3 fps is about where performance might become an issue on certain devices or network environments.
:information_source: Additionally, performance also depends on
SceneView's internals, which we don't have access to. This could vary across devices and may limit optimization efforts further.Key points
requestAnimationFrameto sync video frames with the line chart (manually scrubbing the video)SceneViewsdk and how well it handles video playback across different devices, which could impact performance in ways outside of our controlProblem
Higher frame rates (like the original 12 fps) led to a bigger file size especially if encoded with GOP 1 (used for better video scrubbing). This will affect performance, especially on mobile. Scrubbing seems laggy, and the videos took some time to load. Dropping to 1 fps, 2 fps, or (max) 3 fps reduced the file size and load times, making scrubbing smoother across devices.
Performance tests
Configurations tested
Preview Links
Deployment url with the different fps versions:
Test devices
Laptop:
Key metrics
SceneViewlayerDevice tests
Note: These tests were performed on LambdaTest emulators. Performance on actual devices may differ and potentially be more optimized.
Summary
1 fps and 2 fps perform well. 3 fps is still an option, but it starts to push the limits with our approach, and performance also depends on how
SceneViewhandles it on certain devices, which we have no internal control over.Compression and seekability
Does compression affect seekable frames?
Short answer: Yes, it can, if it changes the GOP size
Why GOP is set to 1
Setting GOP to 1 ensures that every frame is a keyframe, so that the "frame seeking" which we do by manually scrubbing the video works smoothly and is fast. There's a nice explanation in this thread
cc @j08lue