streamon format and and datagram lenght

[f41ardu]

After successful implementation of the video stream for Raspberry PI I am still looking into an approach based on Processing for Windows.
I'm still struggeling with the format instead of 11 packeages (11*1460 bytes + 12 lower < 1460 bytes) I receive 4 times 1460 bytes and then a smaller one? Tello is in sdk mode and I use stream on to initiate video streaming.

Any video content in the smaller package?

Strange number off 1460 byte packages differ? Sometimes 4, then 8 then 11???

[19-03-09 08:12:59.168 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.168 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.169 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.169 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.169 +0100] receive packet <- from /192.168.10.1, port:62512, length: 481
Received datagram with 481 bytes.
[19-03-09 08:12:59.201 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.201 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.201 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.201 +0100] receive packet <- from /192.168.10.1, port:62512, length: 1460
Received datagram with 1460 bytes.
[19-03-09 08:12:59.201 +0100] receive packet <- from /192.168.10.1, port:62512, length: 311

Thanks in advance
f41ardu

 

[Mike Shock]

After successful implementation of the video stream for Raspberry PI

And how long is the lag time of the video-stream on Raspberry Pi? I tried dji-sdk/Tello-Python on Raspberry Pi 3 and the freezes are terrible.

 

[f41ardu]

I regret to say that the performance is slow on even a Raspberry PI3+ and it freeze.
That was the main reason for my python 3.5 approach. I'll just prepare a 386 based Raspberry and expect better video performance. I'm also looking to downscale the size of the video , but without success so far.
You may have a look at my Processing based implementation. The video performance on a Raspberry is much better than the python implementation.