Repository navigation
[Bug]: Timeline in editor video preview stuck or laggy #1475
Description
Search existing issues
- I have searched the existing issues
Describe the bug
I am experiencing a severe performance issue where the video preview window in the editor timeline completely freezes/stuck. When I press play, the audio plays perfectly in real-time, but the visual player stays frozen.
The preview frame takes an incredibly long time to render. If I leave the timeline paused and wait for about 5 minutes, the current frame will finally load and can be played. However, the moment the playback reaches a cut area (split clip) or if I press the pause button, the preview window immediately freezes again, forcing me to wait another 5 minutes for the next frame to render.
System Specifications:
• OS: Windows 11 (64-bit)
• Processor (CPU): AMD Ryzen 7
• Dedicated GPU: NVIDIA GeForce RTX 5060
• Integrated GPU: AMD Radeon Graphics (Dual-GPU Setup)
• OpenScreen Version: 2.2.1 (Standalone Desktop Installer / microsoft store version)
Troubleshooting Steps I Have Tried (None Resolved the Issue):
- Switched the app's graphics preference between iGPU (AMD) and Dedicated GPU (RTX 5060) via Windows Graphics Settings.
- Toggled Windows "Hardware-Accelerated GPU Scheduling (HAGS)" On and Off.
- Cleared the application caching data in %appdata%\openscreen.
- Launched the application with Chromium flags: --disable-gpu, --disable-software-rasterizer, and --use-gl=angle --use-angle=d3d11.
Despite all the configurations above, the audio-video desync and the 5-minute frame-rendering delay persist on all videos. It seems like a core issue with how the Chromium/Electron playback engine handles hardware video decoding or frame composing on a dual-GPU laptop setup.
Thanks you
Expected behavior
smooth timeline even when pause, cut, etc
To Reproduce
- record
- go to edit
- cut video or pause video
Screenshots
No response
OS
Windows
OS Version
windows 11
Other OS
No response
Browser
Chrome
Browser Version
No response
Other Browser
No response
Device Type
Laptop
Other Device
No response
Additional context
No response
Activity
EtienneLescot commentedon Nov 3, 2026
Thanks for the detailed report and for everything you already tried.
To narrow this down, could you share:
Openscreen.exefrom a terminal (PowerShell), reproduce, and paste what it prints.That will tell us whether the preview's decoder or the compositor is the one stalling.
anggana-putra commentedon Nov 3, 2026
The console output remains completely blank even after the preview freezes. Here is the exact printout from PowerShell after reproducing the issue and toggling play/pause:
RECORDINGS_DIR: C:\Users\Anggana\AppData\Roaming\openscreen\recordings
User Data Path: C:\Users\Anggana\AppData\Roaming\openscreen
Global shortcut registered: CommandOrControl+Shift+0
however there is 2 warning while rendering :
[D3D11VA @ 00000231ff2d9140] AMF failed to initialise on the given D3D11 device: 4.
[h264_amf @ 00000231edda8fc0] Failed to create derived AMF device context: No such device
..
log while capturing :
source: { type: 'display', sourceId: 'screen:1:0', displayId: 0 },
audio: {
system: { enabled: false },
microphone: {
enabled: true,
deviceId: 'communications',
deviceName: 'Communications - Microphone Array (Realtek(R) Audio)',
gain: 1
}
},
webcam: {
enabled: true,
deviceId: '---',
deviceName: 'ASUS FHD webcam (13d3:52ba)',
width: 3840,
height: 2160,
fps: 30
},
encoder: { preferSoftwareEncoder: false },
cursor: { mode: 'editable-overlay' },
bounds: {
dip: { x: 0, y: 0, width: 1920, height: 1080 },
helper: { x: 0, y: 0, width: 1920, height: 1080 }
},
sourceId: 'screen:1:0',
usedDisplayMatch: false,
anggana-putra commentedon Nov 3, 2026
Here is screenshoot of task manager that maybe could help you
Additional performance observation:
During the preview freeze, the OpenScreen app only utilizes around 1% of the CPU, occasionally peaking at just 8% before immediately dropping back down to 1%. Even during that brief 8% CPU peak, the video timeline remains completely frozen and refuses to play, while the audio continues to stream normally. still need to waiting around 5 minutes to make the video preview in timeline played
This extremely low hardware utilization suggests that the app is throttling itself internally or failing to distribute the frame-composing workload to the system resources, rather than the hardware being overwhelmed.
Thank you
EtienneLescot commentedon Nov 4, 2026
Thanks, that narrows it down a lot: long take, 4K webcam, and the freeze hits exactly at cuts and on pause.
One question to tell a 2.2 regression from an older limit: does the same 11-minute project play smoothly in 2.1.2? You can install it from https://github.com/getopenscreen/openscreen/releases/tag/v2.1.2 (your projects stay where they are), open the project, and play across a cut and pause once.
If 2.1.2 also freezes, a quick extra check helps too: hide the webcam layer in 2.2.1 and see whether the screen alone still freezes.
EtienneLescot commentedon Nov 7, 2026
Thanks again for all the details. We rebuilt your setup on a Windows AMD machine: an 11-minute 1080p60 screen take plus a 4K30 webcam track, with a cut in the middle, on 2.2.2. Seeks took about 0.1 to 0.25 s, playback ran at 59 fps, and crossing the cut paused for under a second. We could not get anywhere near the multi-minute freeze you see, and the seek path has no wait that could last that long.
What we could not reproduce is specific to your machine: the preview running on the NVIDIA card of a dual-GPU laptop, and a real file from your "FHD" camera that reports 4K. So I'm closing this for now. Please reopen it if you can share any of these:
Any one of them is enough for us to pick it back up.
anggana-putra commentedon Nov 8, 2026
Hello, just got back from work and finally had time to test this out. Thank you so much for your patience!
It appears that I cannot open my previous project in the newer version (v2.2.1) due to a schema validation error. The app prints the following error log:
"[ {"code": "invalid_value", "values": [ 8 ], "path": [ "schemaVersion" ], "message": "Invalid input"}]"
Because of this error, I tried creating a brand new project and recording a new video to test the timeline performance. Unfortunately, the exact same freeze issue still persists in this version (2.1.2) as well.
anggana-putra commentedon Nov 8, 2026
here is the download link to the project https://drive.google.com/drive/folders/1roOmUAOQJbVtTCuICvIvrDKE1Ge4vq5F?usp=sharing (the 10 minutes video, the 5 minutes video that have same problem and recording from my webcam)
it appear i cannot reopen issue because i don't have permission to do so @EtienneLescot
marcgabe15 commentedon Nov 8, 2026
Hi @anggana-putra can you give access to this project on google drive? Just asked for it so I can debug and re-opened the issue
anggana-putra commentedon Nov 9, 2026
hello @marcgabe15 , already gave you permission on google drive. thank you
EtienneLescot commentedon Nov 11, 2026
Thanks for the files and the details @anggana-putra. We have a likely cause: on some GPUs the Windows recorder writes very few key frames, so every seek in a long take decodes from the start. A fix for new recordings is in #1540.
To confirm it on your take, could you run this on the screen video of the 10-minute project and paste the first lines of the output?
One line per key frame. If there is only one, or very few, that is the cause.
anggana-putra commentedon Nov 12, 2026
You were spot on! I ran the
ffprobecommand on the 10-minute screen recording file, and it only returned a single key frame at the very beginning of the video:anggana-putra commentedon Nov 12, 2026
Just wanted to give an update and confirm that your diagnosis is 100% spot on!
I tested re-encoding a new 40-minute screen recording to manually inject key frames every 60 frames using the following FFmpeg command:
After verifying with
ffprobethat the file now contains regular key frames, I imported it into the OpenScreen timeline. The editor now runs completely smoothly! Cutting clips, pausing, and scrubbing/dragging across the 40-minute timeline happen instantaneously with zero freeze or lag.This completely confirms that setting the GOP size in #1540 will fully resolve the issue. Thanks again for the quick investigation and fix!
marcgabe15 commentedon Nov 12, 2026
Glad to hear that this is fixed for you! Going to resolve this
fix(windows): write a key frame every second in captures
EtienneLescot commentedon Nov 14, 2026
Hi @anggana-putra, #1540 just merged: Windows captures now write a key frame every second, which should stop the preview freezing at cuts on long takes. Could you confirm once it ships in the next release? Thanks!