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

Reduce framerate before downscaling #7022

Merged

Conversation

madsciencetist
Copy link
Contributor

It is cheaper to drop frames and downscale those that remain than it is to downscale all frames and then drop some of them. This is achieved with the filter chain -cv fps=FPS,scale=W:H, and perhaps was the original intention here. The plain -r and -s flags do not execute in order though - they each put themselves at the end of the filterchain, so -r FPS -s WxH actually applies the scale filter first, and then the rate filter.

This fix can halve the CPU used by the detect ffmpeg process.

It is cheaper to drop frames and downscale those that remain than it is
to downscale all frames and then drop some of them. This is achieved
with the filter chain `-cv fps=FPS,scale=W:H`, and perhaps was the
original intention. The plain `-r` and `-s` flags do not execute in
order though - they each put themselves at the *end* of the filterchain,
so `-r FPS -s WxH` actually applies the scale filter first, and then the
rate filter.

This fix can halve the CPU used by the detect ffmpeg process.
@netlify
Copy link

netlify bot commented Jul 3, 2023

Deploy Preview for frigate-docs canceled.

Name Link
🔨 Latest commit e1639ab
🔍 Latest deploy log https://app.netlify.com/sites/frigate-docs/deploys/64a33da4e68e3d0008f1a6d9

@NickM-27
Copy link
Sponsor Collaborator

NickM-27 commented Jul 3, 2023

We had problems with this approach in the betas, using -vf alone would not actually / fully limit the fps in some cases which caused the process to use more resources

@NickM-27
Copy link
Sponsor Collaborator

NickM-27 commented Jul 3, 2023

The relevant PR is #5210

@madsciencetist
Copy link
Contributor Author

@NickM-27 Do you remember the specifics? You'd set it to 5 fps and sometimes get 5.1? Can I replicate?

If it's not worth the effort...I brought back the -r

@NickM-27
Copy link
Sponsor Collaborator

NickM-27 commented Jul 3, 2023

No, it was multiple frames off on my cameras. Usually would be 6 or 7 even though it was set to 5

@kdill00
Copy link

kdill00 commented Jul 3, 2023

I have never been able to get ffmpeg to be consistent with fps dropping and smooth video across different cameras unless I re-encode the video after scaling and dropping using nvidia gpus. I’ve never tried cpu but nvidias cards drop frames or generate corrupt ones which they claim the -vsync 0 is needed to prevent. I thought there had to be a better way but I just gave up doing it in Frigate and do a full duplicate and transcode outside of frigate using another application.

@madsciencetist
Copy link
Contributor Author

@NickM-27 ICYMI, I brought back the -r - are there other changes you'd like to see?

@NickM-27
Copy link
Sponsor Collaborator

NickM-27 commented Jul 5, 2023

Makes sense, how much performance improvement are you seeing in this case?

@madsciencetist
Copy link
Contributor Author

madsciencetist commented Jul 5, 2023

With HW decoding but SW scaling, this reduces ffmpeg CPU load from 58% to 33% (on my Xavier with a single camera stream)

@blakeblackshear blakeblackshear merged commit f30ba25 into blakeblackshear:dev Jul 6, 2023
11 checks passed
@madsciencetist madsciencetist deleted the rate_before_scale branch July 6, 2023 13:39
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.

None yet

4 participants