Open obilodeau opened 3 years ago
@h3xstream suggested to use a fps of 25 (which can divide 1000 cleanly) and see. What I like about this solution is that it would also make the conversion faster and video files smaller. Remembering some captures I looked at, we clearly don't do 30 fps over RDP anyway.
I believe that the way we encode frames we create the possibility of a drift between the real time and the resulting video times. This is exacerbated on large captures.
In Mp4EventHandler's init:
then:
However:
There's a 0.3ms per 1000ms drift opportunity. On a long capture this amount to a very large maximum theoretical drift:
Further investigation: I will record an RDP session playing a high precision clock and timer on a screen for a long time and compare after video encoding.