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

High fps reported by kvssink #326

Closed
js1972 opened this issue Jan 12, 2020 · 2 comments
Closed

High fps reported by kvssink #326

js1972 opened this issue Jan 12, 2020 · 2 comments
Assignees

Comments

@js1972
Copy link

js1972 commented Jan 12, 2020

I find that the FPS logged to the console when running a simple gstreamer pipeline and kvssink is always much higher than the actual rtsp sources fps.

Using this pipeline as an example:

The reported fps value range from around 21 to 90. The actual Hikvision source camera is set to 640x360 and 10fps.
Sometimes I see kvssink report values as high as 180.

The fps value tend to trend lower over time.... I've been running this pipeline just now for about 10 minutess and I'm starting to see the fps reported by kvssink come down to 12 - 14 which is much closer at least.

Why is this and is it a problem.

@zhiyua-git zhiyua-git assigned zhiyua-git and MushMal and unassigned zhiyua-git Jan 20, 2020
@MushMal
Copy link
Contributor

MushMal commented Jan 20, 2020

@js1972 the SDK has collects some metrics internally as the streaming progresses - it doesn't have internal threading so the frame rate information is generated when a higher-level logic calls put frame API. The PIC uses EMA (exponential mean averaging) to add some "inertia" to the rolling aggregates. The C producer layer calls public PIC API to extract the metrics and simply prints them with every key frame after certain time elapses. In this case, the GStreamer pipeline uses RTSP which is "bursty" - aka, it produces frames not at a constant rate as the encoder produces but at the rate the RTSP plugin receives them over the network which produces bursts of frames, resulting in the observed frame rate to fluctuate. This is similar to an offline intermittent streaming mode when a number of frames are being produces in bursts resulting in high FPS. The reality, though, the reported FPS is the observed FPS - each frame should have its own timestamp so it shouldn't cause problems with the persistence or indexing.

Please let us know if you have more questions. Resolving for now.

@MushMal MushMal closed this as completed Jan 20, 2020
@js1972
Copy link
Author

js1972 commented Jan 20, 2020 via email

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

3 participants