-
Notifications
You must be signed in to change notification settings - Fork 94
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
Non-null renderers cap performance test #307
Comments
Thanks for the report. In my experience this seems to be a limitation of some video renderer filters. It may be possible to work around it by building with a different video renderer filter but unless you're testing overall rendering performance it would be simpler to use a null renderer filter. I don't think this frame rate limit is something we can change in GSN. |
DXVAchecker benchmark has no problem in doing so with, say, LAV video decoder. |
Sounds like the graph building logic in this dialog needs to be amended to choose a different default video renderer as limiting to frame rate to the monitor refresh rate is clearly not helpful when the graph is being created for performance testing. |
I'm starting to think the problem may be on the fps_calculating logic, realtime_ns specifically. |
I mean, when the actual video is played back, it is sped up normally as I'd expect.
But when result is reported in the "results window" everything seems like bottlenecked to monitor refresh rate.
The text was updated successfully, but these errors were encountered: