You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 [18]: 1000//30
Out[18]: 33
In [19]: 1000/30
Out[19]: 33.333333333333336
There's a 0.3ms per 1000ms drift opportunity. On a long capture this amount to a very large maximum theoretical drift:
In [26]: ((1000/30-1000//30) * 12*60*60) / 60
Out[26]: 240.0000000000017
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.
The text was updated successfully, but these errors were encountered:
@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.
The text was updated successfully, but these errors were encountered: