cirquit / trdrop

trdrop - a raw video analysis program
MIT License
386 stars 33 forks source link

The program looking for screen tearing even if "Enable tear analysis" slider is disable #71

Open mrDMG89 opened 3 years ago

mrDMG89 commented 3 years ago

Hi! Trying a new version of the program. Faced with issue when the frame time graph is clean, but FPS graph report lower FPS. After some experiments I could find the problem. On the ninth second of the video at the top of the frame there is horizontal bulk. If I enable tear analyzes it think that it is a tear. But same behavior on FPS graph with tear detection disable. If I enable tear detection, but set "dismissed tear percentage" on 100%, the issue is gone. As far I can understand, "Enable tear analysis" slider does not turn off tear detection, but only turn off its visual representation. YouTube Link

cirquit commented 3 years ago

Hm, so it looks interesting. Could you maybe send me the raw video via wetransfer.com to alex.isenko@protonmail.com?

The yt video is hard to analyze because they apply an encoding.

mrDMG89 commented 3 years ago

Sorry, it more than 2GB. Maybe Mega or other file transfer service?

cirquit commented 3 years ago

Sure a mega link is fine too.

mrDMG89 commented 3 years ago

Mega

cirquit commented 3 years ago

So first of all - I really need to include a time description in the export window. This would make debugging easier for the future.

The enable tear detection does indeed only "disable" the visualization, I still included the detection of the tears in the framerate as its very important to handle them somehow. Otherwise the framerate will just jump from from 30 to 60 if we just remove this part of the algorithm.

So from the first impression, I feel this shouldn't be detected as a tear at all, am I right with that? Cause if I check the video without delta-rendering it doesn't look like a tear to me. Would you propose is to update the tear algorithm that it doesn't affect this video?

The frame-index 568 -> 569 shows a "tear" with 29.9 FPS (pixel-difference set to 10) but in reality its just that the screen is moving perfectly from top to bottom which results in a false-positive. From this I actually found a bug in the code, which I will have to fix with then next release (https://github.com/cirquit/trdrop/blob/master/trdrop/headers/cpp_interface/frameprocessing.h#L400).

To make the correct 30 FPS shown you have to do the following:

I will take a look at the tear detection algorithm as its really naive as this did video showed. I'll keep this issue opened to remind myself to fix the bugs found, but I hope that the proposed solution helps you for the time being.