MP tlog representation lags 10%

When MP represents a tlog it lags 10% in time (or I miss something). Here is a video showing it:

Lower clock should have quartz precision. Moreless 10 seconds on the hud GPS clock really last 11 seconds.

If thinking it is due to the video capture program, here are window captures at start and end with MP representing the tlog (without video recording).

So 13 minutes of tlog really last 14 minutes and 5 seconds, but this is variable for whatever the reason.

MP 1.3.72 build 7473.2320
MP generating the tlog slightly earlier.
This 10% delay has always happened (or I always have missed something). For tlog videos requires ffmpeg corrections for video and audio.

BTW, the video above corresponds to this other (mission of a 10x12 spiral repeated three times):


There is a ROI waypoint at the beginning, so the yaw should be 235º. At t=253 (first mission):

the ROI is forgotten, and yaw changes constantly till the end of the mission (on second and third mission all is normal). It corresponds to (t=197):

I have seen another “ROI forgotten” here (helicopter):


(tlog)

(video)
as described here.

Tlog records the incoming and outgoing Mavlink packets. If your datalink is not 100% (absolutley zero packet loss). Then there will be always missing packets in the tlog.

log playback times are best effort, and not designed to be exact. it would depend alot on your machine, how much cpu its using and a few other factors.

you may even notice jumps forward in time if there is alot of missing data. ie if the time between packets is > 1second it will jump ahead whats above the 1 second… ie 3 seconds of no data will only take 1 second to pass

Here is another video, with telemetry through USB cable (optimal), and quad as quiet as possible:

and captures in tlog 10 minute interval:


The delay around 16-17 seconds (2.7%) persists.

It is like voice recording GPS clock time readings on a very old cassette magnetic tape recorder (no quartz based timing). Recording has atomic precision, but playing has RC precision (there could be timing differences between recording and playing).

On this other video of the same quad:

on the left there is the live MP capture while flying (no problems, no delays) and on the right the MP tlog capture. They appear moreless synchronized since the tlog capture is 10% time corrected.

I feared that; ffmpeg is a workaround. I deeply appreciate your efforts on this fantastic program.

Note that I have been doing MP tlog video capturing on two different laptops with huge speed differences:
·Core i5-3380M 2.9 GHz with Intel 4000 graphics;
·Core i7-3740QM 2.7 GHz with NVIDIA Quadro K4000M graphics,
but differences on the timing corrections are minimal: ffmpeg corrections needed are around 10% on both laptops.

i will look into improving the time playback, but its not a high priority right now.

could you test without the voice turn on? i have a feeling that could actually reduce this issue

I unchecked “Enable Speech” and restarted MP (just in case):

20200622_QuadX7_USB

39’ tlog capture last 42’52" (9.91% more).
Capture was done on the slow laptop mentioned above.

MP: 1.3.72 build 1.3.7477.15237.

BTW1: has this feature, representing aditional data, taken away? It was nice for seeing battery voltage in big size while flying.

BTW2: it would be nice if when undocking the hud its position would be remembered, so as not to have to reposition it (above upper left flying area).

BTW1 - right click the map and change it using “change icon description”
BTW2 - certainly doable, your the first person to ask

Corrected with ffmpeg to 39’ length:

The result is not good:

Thanks: powerful right click.

Is this on the way?

Test (MP 1.3.7514.18833):

  1. Double click on hud: detached.
  2. Place hud somewhere.
  3. Close it (X up right).
  4. Double click it again: it does not appear where it was placed and closed before.