Welcome! This guide will explain how to use a tool created by HeapUnderflow➚ called "Deframe" to analyse video smoothness (specificaly dropped frames, where the same frame is displayed twice), as part of ensuring your stream using Keysight is as smooth as it can possibly be.

Requirements

• The Deframe tool itself⬇ (your browser will probably attempt to block this download as suspicious)

TL;DR

• Open up all your usual streaming programs to ensure a representative environment
• In Keysight, enter the console command deframe 100 in the System tab
• In OBS, duplicate your profile and call it Deframe
• In this profile, set video output to scale down to 192x108
• Enable MIDI file looping in Keysight with the refresh icon next to the play button
• Begin MIDI playback
• Start making an OBS local recording, ensuring the top left corner of Keysight is fully visible
• Leave it recording for at least 30 minutes if you want to be confident in results
• Open up Deframe
• For Path to ffmpeg.exe, use the Keysight bundled one (probably C:\Program Files (x86)\Steam\steamapps\common\Keysight\Keysight\Content\Tools\Windows\FFMPEG\bin\ffmpeg.exe
• Ctrl-shift-C to copy the path of your recorded video into the Source file field, and remove the quotation marks at the start and end
• Set Test region width and height to 1
• Hit scan and wait (can wiggle mouse over the current-frame display to get it to update live)
• Take a screenshot of the results for later comparisons, maybe give it some useful labels
• Change settings, and repeat record + analysis steps

Why do this?

Keysight-driven content is enormously sensitive to dropped frames, much more so than even fast-paced gaming content. While watching a MIDI visualiser, your eyeballs are tracking notes moving across the screen. Since that motion should be 100% consistent and easy to predict, any dropped frames or inconsistent motion really stands out to a viewer and frame stutter is much more obvious than it might be on other capture sources.

"But why have this complicated guide? Can't you just look at a recorded video and tell if it's better or worse after changing some settings?"

Nope.

The OBS preview is not representative of the produced video. The video playback is not representative of the produced video. Your eyeballs are not to be trusted. Short recordings may appear completely fine, but those same settings may periodically lag horribly every 10 minutes or so. Seriously, you need long recordings and then automated analysis to have any sort of real confidence about the existence and proportion of dropped frames in a video.

Process

OBS configuration

• Make a duplicate of your streaming (or recording) profile in OBS, and call it something useful like "Deframe"

• In Settings > Video, set Output (Scaled) Resolution to just 192x108 (this is why we're using a separate profile, to not mess with your normal output settings)

• Make sure "use stream encoder" is enabled for recording under Settings > Output, to ensure the closest match to actual streaming settings

Keysight configuration

• In the System tab, enter the console command deframe 100. This creates a 100x100 pixel square in the top left of the screen with a colour that changes every single frame, and in such a way that it will not display the same colour twice within any sort of near time-frame

• In the MIDI tab, enable the little refresh icon toggle next to the play button for MIDI file playback. This allows MIDI files to loop upon finishing playback, and we want to apply a "reasonable" load that is representative of real-world performance (without you having to sit there and play a bunch of piano. But who knows, maybe you could just do some practice while recording test samples!)

Using Deframe

• Load up any programs you use for streaming, to ensure a representative environment for creating test recordings
• Begin recording in OBS with your MIDI file looping in Keysight
• Leave the recording running for at least 30 minutes. Certain types of frame drops can happen over long intervals, where Keysight can be smooth for 20 minutes and then lag horribly for 2 minutes before going back to being smooth again! (Although shorter recordings can be fine if you're validating a setting not causing horrendous systemic lag that would show up instantly)
• Once you have your video, open up the Deframe⬇ program
• In the Path to ffmpeg.exe field, enter the path to the Keysight-included version of ffmpeg. This is usually: C:\Program Files (x86)\Steam\steamapps\common\Keysight\Keysight\Content\Tools\Windows\FFMPEG\bin\ffmpeg.exe
• In the Source file path, copy in the path to your newly-recorded video using Ctrl+shift+C and remove the quotation marks
• Set Test region width/height to 1

Interpreting results

Hit Scan to begin analysis!

Once the scan is completed (you can wiggle your mouse on the scanning-frames window that pops up to get the counter to update), you will be greeted with a window that looks something like this:

The graph along the top bar shows spikes for any duplicate frames detected in the video. You can use the arrows by Duplicate and Frame in duplicate to view those frames and validate that they are indeed duplicates (but I've never seen Deframe give inaccurate results using the Deframe square in Keysight).

In terms of what this means, you want a line along the top bar with as minimal spikes as possible, and avoiding clumps of spikes too. For example, this is a "near-perfect" graph:

And this is a truly horrible result:

It is also very common to have "intervallic" frame drop regions, like so:

This final intervallic lag is the most common, and the most difficult to solve in my experience.

Some settings to try playing with

Now that you know how to create and analysis recordings in an automated and scientific fashion, it's time to iterate! I recommend saving a screenshot of each Deframe analysis with some labels explaining which settings you used, to compare between later.

I would also recommend starting from some sort of "optimal baseline" set of settings. For example, running at 60fps in Keysight is preferable to running at 240fps (if you can) as you'll use less system resources, so choosing 60fps as your baseline makes a lot of sense.

Settings to try toggling between:

• V-sync (especially 1:1 or 1:2 if you're on a high refresh rate monitor)
• Frame-rate caps (these are almost always bad though)
• Window capture versus Game capture in OBS (makes a surprising difference!)
• Source settings in OBS
• Fullscreen Keysight (if you can afford to have it focused)
• Keysight-driven v-sync versus driver-level sync options
• Adaptive sync on/off if you have it
• Monitor refresh rate tweaking

Limitations and closing thoughts about smoothness

Animation error

The main drawback of the current method is that this can only detect "dropped frames", where the same frame is displayed twice. There is a much more insidious form of inconsistent motion: "animation error". This is where each frame is unique but it displays a varying amount of "time" per frame, so the resulting motion is still inconsistent.

This is something I'm actively looking into and have adjusted Keysight's little Deframe square to encode the current time in Keysight as a colour for a hypothetical Deframe v2 that can extract a simulation-time-per-frame graph from it.

Where does lag come from?

From my research into this, you have three major points in the pipeline that are liable to be the source of lag:

• OBS itself, and failing to encode a frame in time. This is unlikely, and should show up in OBS stats if it does happen
• Keysight itself, if it suffers a lag spike. More likely than OBS, but still unlikely as long as you can comfortably run Keysight
• Keysight's synchronisation with OBS. This is the major one I will be discussing, as it is pervasive and cannot be fixed with stronger hardware or lowered settings

Intervallic lag

Under stock conditions, Keysight will use v-sync and render at the monitor's refresh rate. If you have a 144Hz monitor, it should be fairly self-evident why just using v-sync will cause inconsistent frame pacing:

You'd be forgiven for thinking that if you have a 60Hz monitor (or 120Hz), you should be good to go, right? 60Hz = 60fps, things match up nicely. But no, from my research at least, it seems very unlikely that your monitor's refresh rate is perfectly 60Hz. It may be something like 59.998Hz or 60.001Hz. This will lead to intervallic periods of heavy lag, which often looks like this in Deframe:

I've forced a specific refresh rate of 60.000Hz through essentially monitor overclocking in the past, I've still seen intervallic lag with a period of around 22 minutes.

Why does this happen?

My theory as to what is going on is that the rate for frames to be captured in OBS is constant, and the rate for Keysight to produce them is also constant. But the Keysight frame delivery happens at slightly different times within that constant rate, like perhaps a frame is delivered in 16.56ms and the next one is 16.78ms to compensate. This tiny "wobble" in frame delivery timing means that when the Keysight/OBS rates are slipped out of sync by half a frame, OBS is receiving frames with a chance for them to be early or late by a whole frame.

This wobble appears to be tied to how "easy" Keysight is for your hardware to run. If Keysight can only just run at 60fps consistantly, the frame wobble range is substantially wider than if you could run Keysight at 600fps. My proof for this is capturing Deframe results with just a blank Keysight scene versus a Keysight scene that is running an intensive preset and a looping MIDI file, and the blank scene performed much better (although it still shows intervallic frame drops).

Personal recommended settings

I would like to stress that frame pacing issues are incredibly hardware-dependent and what works well for me might not work well for you! But with that disclaimer out of the way, I use:

• Window capture in OBS with stock settings
• V-sync in Keysight targetting 120Hz

Other environment information: Windows 11, single monitor at 240Hz, adaptive sync turned on, Keysight at 1080p windowed, latest OBS, fairly complex OBS scene, OBS as the focused window.

I think I still get some intervallic animation error stutter, but it's vastly preferable to intervallic frame drops and nobody has ever noticed or complained about it. The "reason" this works is because when ther 120Hz input frames inevitably get into that half-frame-desynced state and the frame wobble would cause frame-drops, having double the number of frames available means it'll still always show a unique frame, just with inconsistent animation time within that frame. In other words, trading frame-drops for animation-error (which, while not perfect, is vastly preferable as shown by the above animated image).

Following that logic, more Keysight frames = more better? I don't actually know the answer there. But hogging all system resources to run Keysight at 300fps is probably not a good idea, and OBS seems to struggle to keep a smooth captured-source framerate when provided way too many frames. Perhaps the limit-capture-framerate setting might help, but I am yet to test every possible permutation of settings!

I've spent, cumulatively, weeks looking into this stuff and asking Heap to help out with specialised tools. If you have any thoughts about any of this or found settings that worked really well for you, get in touch with me via Discord!