Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Player performance issues with long sessions #488

Open
jmvermeulen opened this issue Mar 8, 2025 · 1 comment
Open

Player performance issues with long sessions #488

jmvermeulen opened this issue Mar 8, 2025 · 1 comment

Comments

@jmvermeulen
Copy link

The player does it's job well. Once the sessions become more then 1-2 days, the performance of the player drops a lot.
Seeking in the progress-bar freezes for longer periods and there is not workable way to reverse or forward the stream.

I've tried to split the replay file in separated files (respecting the binary format). But it seems only the delta's are in the PDU's.
Is there a way to find the closes full-image PDU easily?

Also the player seems to be single-threaded, my CPU is not used fully.

@jmvermeulen
Copy link
Author

@olivier-lemelin i'm working on a solution.

By limiting the number of still frames in the code below, the performance of the mp4 convert is much better (factor 10).

  nframes = (dt // self.delta)
        if nframes > 0:
            for _ in range(nframes):
                self.writeFrame()
            self.prevTimestamp = ts
            self.log.debug('Rendered %d still frame(s)', nframes)

But it seems to miss some key/index-frames in the video now. Only deltas are shown until the fill windows refreshes.
Do you know how to solve this a better way?

To optimize the forward/reverse of the stream playback, I was thinking to keep a copy reference to a full-frame image every x interval during playback. Then when the user goes back 1 min, we look for the last full-frame image and only playback the PDU's from there. This might boost performance a lot.

Another solution in therms of usability might be to have a option to have the option to seek to the next user-interaction event. Like a keyboard of mouse action. This only usefully during user inactivity for a long time.

Was looking to extend the ReplayThread.py in not only having the notion of events and timestamp. But to include the PPUType here. Then it would be possible to scan for the next relevant event and set the player to that point in time.

Would you agree?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant