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

Fixed high CPU on video playback and video freezing on wake #520

Merged
merged 2 commits into from
Dec 22, 2018

Conversation

oomek
Copy link
Collaborator

@oomek oomek commented Dec 16, 2018

Some snap videos ( ie. Proggetto Snaps ) consumed excessive amount of CPU. This was caused by max_sleep being dependent on the time base instead of the frame rate.
Fixed video freezing after resuming from sleep, which was caused by only showing key frames. Videos now restart when computer wakes up.

…om sleep

Some snap videos ( ie. Proggetto Snaps ) consumed excessive amount of CPU. This was caused by  max_sleep being dependent on the time base instead of the frame rate.
Fixed video freezing after resuming from sleep, which was caused by only showing key frames.  Videos now restart when computer wakes up.
@mickelson
Copy link
Owner

I understand the fix for excessive CPU usage due to how max_sleep is set, good catch there.

I'm not following the other change mixed in with the pull request though. (this is where having separate PRs for each fix helps). It appears that you are trying to stop the video from only showing key frames after resuming from a sleep.

The displaying of just key frames is currently controlled by us with the qscore variable and the set_avdiscard_from_qscore() function. I wonder if a simpler fix for the second issue would be to simply keep the qscore at a higher value when you detect that the computer is recovering from a sleep??

@oomek
Copy link
Collaborator Author

oomek commented Dec 20, 2018

Yes, max sleep for some videos was less than millisecond. I've tried reserting qscore, but it did not have any effect for some reason. Having videos restart after resuming from sleep and not stutter seemed a logical solution for me.

@oomek
Copy link
Collaborator Author

oomek commented Dec 20, 2018

Regarding the separate PRs. This is a bit troublesome when I edit the same files in separate commits. Nobody likes conflicts I believe.

@oomek
Copy link
Collaborator Author

oomek commented Dec 20, 2018

So, are you ok to merge this PR? This bug was haunting me for a long time, I'm glad I finally found the source of those crashes. The logs from FeVideo are still sometimes mangled with the main thread though. A simple mutex is not going to work without refactoring the log functions as you have used references for the log targets, but that's a minor issue to be fixed in the future.

@mickelson
Copy link
Owner

Sorry this PR is fixing crashes? Or do you mean the nowide PR?

@oomek
Copy link
Collaborator Author

oomek commented Dec 21, 2018

Sorry, this comment indeed does not belong here. I should stop answering on the mobile phone.

@mickelson
Copy link
Owner

yup I'm going to merge it now

@mickelson mickelson merged commit 2ccc959 into mickelson:master Dec 22, 2018
@oomek oomek deleted the video-playback-fix branch December 30, 2018 18:32
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

Successfully merging this pull request may close these issues.

2 participants