Add Low latency mode for video

[Williangalvani]

This setting disables the rtpjitterbuffer and sets the videosink to non-sync (assynchronous? mode. This reduces the latency here from ~380ms to ~200ms.

@jaxxzer can you please test?

[DonLakeFlyer]

This needs to be a setting? It kinds of reads like "check this box to make your video not suck"!

[Williangalvani]

This needs to be a setting? It kinds of reads like "check this box to make your video not suck"!

@andrewvoznytsa pointed out that some encoders can send frames out of orders, which the sync takes care of.
The rptjitterbuffer is useful for people with 4G links which seem to enjoy sending packets out of order.

So the lower latency mode is probably less robust, and higher-latency smoother.

[DonLakeFlyer]

There is no way to autodetect that somehow? if not, then we need some good way to explain this completely techy thing to a user

@Williangalvani Can you screenshot the new setting?

@hamishwillee Getting hamish involved...

[Williangalvani]

There is no way to autodetect that somehow?

We'll have to ask @andrewvoznytsa. Maybe based on the amount of bad frames decoded? I'd still prefer some artifacts over a high latency video.

Making it low-latency-only or making it the default both sound ok to me, I was just being cautious as it could harm other users I'm not aware of.

PS: I got the image on the PR description

[jaxxzer]

This will fix #8489 . The setting is working over here, no app restart is necessary.

In controlled tests (ethernet connection, udp, h264 1080p 30fps):

QGC 3.5: 202ms
QGC 4.0: 389ms

After this patch:
box unchecked: 393ms
box checked: 205ms

What this does is enable/disable an internal buffer that will wait for missing/out-of-order packets for 200ms, then reorder the packets for a nice display. This is very good for wireless connections, but it adds up to 200ms latency to the video stream, which is quite noticeable to a pilot. If the internal frame buffer is disabled, the video stream may have more tearing/breaking and lower framerate (especially for a poor wireless connection), but the 200ms latency overhead of the internal frame buffer is eliminated.

I suggest calling the setting 'disable (200ms) frame buffer' or something along those lines.
@Williangalvani and I can help @hamishwillee with the docs.

[DonLakeFlyer]

Ok, so I'm maybe fingers crossed at a point with Stable that this next point release may last more than a couple days. So I'd like to wait on it until we get some good wording here. Then I'll merge and get a point release out.

[andrewvoznytsa]

There is no way to autodetect that somehow? if not, then we need some good way to explain this completely techy thing to a user

There are some ways to autodetect if this rtp jitter buffer is needed (in fact this is something that good jitter buffers do - they are able to adjust buffer length depending on QoS). But they are very risky to be added in the last moment and not really trivial to do. Our silver bullet for 4.0 is to explain that if you see some video lag AND video quality is good then you can try to experiment with low latency check box - enabling low latency (disabling buffering) switches QGC into 3.x buffering mode. In this mode you can expect a bit choppy video and/or frame losing in some cases - that's what user needs to know (feel free to re-phrase into more readable text).

[Williangalvani]

Updated, thank you @andrewvoznytsa for the help.

[patrickelectric]

Note: It's possible for QGC to inform the user about the video latency:
https://gstreamer.freedesktop.org/documentation/additional/design/tracing.html?gi-language=c

[DonLakeFlyer]

Is this ready to merge?

[Williangalvani]

I am running some tests here on a real vehicle.

[jaxxzer]

@DonLakeFlyer This pr is testing ok, and I believe we have @andrewvoznytsa blessing on the implementation.

Docs pr is here: mavlink/qgc-user-guide#251

[andrewvoznytsa]

LGTM, if you need me to test then I can do it tomorrow (past midnight here).

[DonLakeFlyer]

Thanks folks. I'll spit out a point release tomorrow.