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 record screen and mouse movement info at the same time. I later 'blend it' together, so I need to know the exact time when recording actually started to avoid video<>mouse-data time missmatch.
.startRecording() promise resolves when recording starts, but it can be delayed by multiple reasons, eg main thread being busy.
It would be great if .startRecording() would return promise with something like firstFrameTimestamp
This way I would know exactly at which point in time actual visual recording starts.
Do you have any suggestions how can I do that (even if it requires some hacks)
Alternatives I tried:
I thought 'stopRecording' method is way more lightweight, so I can capture 'endTime' (either before or after calling stopRecording), then measure recording duration reading recording file and then doing startTime = endTime - videoDuration. It might be more precise, but it is still subject to delays.
The text was updated successfully, but these errors were encountered:
I agree, it would be useful to include the timestamp, however, it's unfortunately not something I have time to look into right now. PR welcome though. I think you could include the timestamp in one of the events sent from the Swift back-end.
Thank you for this amazing lib!
I record screen and mouse movement info at the same time. I later 'blend it' together, so I need to know the exact time when recording actually started to avoid video<>mouse-data time missmatch.
.startRecording()
promise resolves when recording starts, but it can be delayed by multiple reasons, eg main thread being busy.It would be great if
.startRecording()
would return promise with something likefirstFrameTimestamp
This way I would know exactly at which point in time actual visual recording starts.
Do you have any suggestions how can I do that (even if it requires some hacks)
Alternatives I tried:
I thought 'stopRecording' method is way more lightweight, so I can capture 'endTime' (either before or after calling stopRecording), then measure recording duration reading recording file and then doing
startTime = endTime - videoDuration
. It might be more precise, but it is still subject to delays.The text was updated successfully, but these errors were encountered: