Hello, fellow droners!
I think I have kind of figured out this one.
Krag and Tikum almost nailed it, but there is some little unsolved problem.
"ffplay -probesize 32 -i udp://0.0.0.0:11111 -framerate 30"
Probesize will only bug you at the start of the stream. Also my ffmpeg version won't let me use anything below 2048, and the stream can only be decoded if I use something around 500.000. (which is a lot less than the default of 5.000.000)
I have noticed that ffplay has a counter named "vq=". It is a buffer that should stabilize at some time in normal conditions, but it is constantly going up.
I figured out that ffplay correctly decodes the video format, but it miss when setting the framerate. The drone produces more that 24fps, hence the buffer is constantly growing because it is sending more frames than what ffplay is displaying.
The solution to probe delay should be specifying the correct format via command line so the program doesn't have to figure out (if it is possible). The solution for the delay and buffer filling up is forcing the framerate to a number higher than what the drone can produce. (or ideally, using some parameter that forces ffplay to display the frame as soon as it is received. But normal encoders doesn't understand why would you like to use VARIABLE frame rate, that is a big NO in normal video files)
Tikum proposed 30, but during my testing the drone can produce more. so just go with 35 or 40 and you are done!
so the final command line would be:
"ffplay -probesize 5000000 -i udp://0.0.0.0:11111 -framerate 35"
Also, trying ffmpeg with sdl instead of ffplay can be a very bad idea, because ffmpeg might encode the video before sending it to display, and that would be a big cpu overhead!
So, enjoy your lagless video!