1 Topic by Love2Golf

  • Love2Golf
  • Member
  • Offline

Hi Joan,

I just upgraded from 2023.1.1 to 2025.2 and am experiencing an issue where the replay speed steps down after every capture.  I didn't experience this in 2023.1.1.  (By the way, thanks for including a setting to set the capture camera as Armed on startup - that was a request of mine many months ago.)

This may be the reproduction case for what bnord reported in the 2025.1 thread (posts #5 and #7). Same symptom, but on hardware that is clearly not resource limited, and with the playback cache configured but apparently never used. The cache part seems like the more useful signal.

SYSTEM

Kinovea 2025.2.0
Windows 11
AMD Ryzen 7 5800X (8 core, 3.8 GHz)
16 GB RAM
NVIDIA RTX 3070
All windows displayed on a single 60 Hz TV

SETUP

Golf simulator. Four separate Kinovea instances: two capture (face-on and down-the-line), two playback running as replay folder observers. Each camera writes to its own local folder. Storage is a local drive, not cloud synced. No default annotation file for capture or playback.

CAMERAS

Both identical: 1280x720 @ 100 fps, MJPG, DirectShow.

Capture infobar during recording, both instances:
Signal: 98.71 and 98.83 fps
Throughput: 336 and 386 MB/s
Load: 0%
Drops: 0

SETTINGS

Capture > General: Record uncompressed unchecked, MP4, display framerate 20
Capture > Memory: delay buffers 1021 MB
Capture > Recording: Delayed, threshold 99, replacement framerate 60
Capture screen: delay 1.50 s, duration 2.50 s
Playback > Memory: cache 2998 MB per playback screen

PRIMARY ISSUE: THE WORKING ZONE NEVER CACHES

Kinogram is greyed out on every clip, which I understand means the working zone did not load into memory.

It should fit comfortably. Throughput divided by frame rate gives roughly 3.7 MB per frame (1280 x 720 x 4 bytes). A 2.5 second clip at 100 fps is 250 frames, about 925 MB. The cache is set to 2998 MB per playback screen, and since these are separate instances each should get its own full allocation.

Task Manager with all four instances running and videos loaded:

Kinovea 138.5 MB, 7.9% CPU
Kinovea 127.8 MB, 8.3% CPU
Kinovea 141.9 MB, 7.0% CPU
Kinovea 132.1 MB, 7.6% CPU

System memory 62% total, CPU 43% total (includes GSPro and a browser). Each instance holds around 135 MB against a permitted 2998 MB, with several GB free system wide.

So the cache is configured, memory is available, the clip should fit, and nothing loads. If frames were being decompressed in advance I would not expect the player to fall behind at all on this hardware.

SECONDARY ISSUE: SPEED STEPS DOWN

The speed slider steps down roughly 5% at a time across successive recordings in the replay observer. It does not recover. Before a clean reinstall it would reach 0% and stop playing. After the reinstall it settles rather than bottoming out, but still drifts down over a session.

The effect scales with declared framerate. At replacement framerate 15 playback is completely smooth and stable with no stepping. At 40 and above it steps down. This looks proportional to rendering load, which is consistent with frames being decoded live rather than served from cache.

RULED OUT

Full uninstall and clean reinstall of 2025.2.0, no change to the caching behavior
Working zone trimmed to roughly one second, still would not cache
Record uncompressed unchecked, output confirmed .mp4 rather than .mkv
Separate local output folders per camera, neither cloud synced
No default annotation file
Display framerate reduced to 20
Capture side clean: 0% load, 0 drops on both cameras
CPU and RAM not saturated

Happy to run any test, or send logs or a sample file.

Thanks for the continued work on 2025.x.

2 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Hi, yes if I remember correctly I deactivated the full caching mode on replay players to make sure it opens the video instantly instead of spending time caching it which can be disruptive if you want instant feedback. In the context of capture/replay loop people usually just replay the video a few times rather than do full analysis so it's a good tradeoff. I think it was also an issue for dual replay synchronization.

Regarding the auto-slow down I'm currently working on updating ffmpeg libraries and reviewing player performance so hopefully I can improve the behavior here. Right now it tries to not drop any frames and it slows down to maintain this goal. But for playback it's probably better to drop frames. I think I have the upgrade figured out at this point and starting to look into performance.

3 Reply by Love2Golf

  • Love2Golf
  • Member
  • Offline

Thanks Joan,
Good to know the caching behavior is intentional in replay players rather than something misconfigured on my end. The instant-open tradeoff makes sense for the capture/replay loop.

One data point in case it's useful while you look at player performance. My use case may sit at the heavier end of what you had in mind. In a practice session I'll put fifty to sixty recordings through the replay observers, and because the slowdown carries across files rather than resetting per video, it compounds over the session. Starting at 60% I'll be somewhere well below that by the end, without ever having touched the slider. Dropping frames instead of slowing down would fix that entirely for what I'm doing, so I'm glad to hear that's the direction.

Thanks

4 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Some people do it intentionally, setting the replay speed to 50% once and so having it automatically carry over was a feature request, to make a feedback loop that's always in slow motion. I could add an auto-reset option though. But first I want to try to improve the playback perfs.