graph-studio-next icon indicating copy to clipboard operation
graph-studio-next copied to clipboard

Non-null renderers cap performance test

Open mirh opened this issue 7 years ago • 4 comments

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.

mirh avatar Apr 18 '17 21:04 mirh

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.

mikecopperwhite avatar Apr 19 '17 16:04 mikecopperwhite

DXVAchecker benchmark has no problem in doing so with, say, LAV video decoder.

mirh avatar Apr 19 '17 18:04 mirh

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.

mikecopperwhite avatar Apr 20 '17 13:04 mikecopperwhite

I'm starting to think the problem may be on the fps_calculating logic, realtime_ns specifically. Because thinking better, there's no way the rate of a 26 seconds(@ 15~30FPS) video played back in 11 seconds to be 1x.

mirh avatar Apr 21 '17 16:04 mirh