Video capture fails, though ffmpeg does capture video.

[pbeeken]

I am a physics teacher whose school has a set of these drones and I am trying to develop some labs with my students using the drones. I have been playing with this library for a short while and the basic commands seem to work well (better than my initial attempts at device control) but I have been having trouble with the video capture.

Using the following simple code

from djitellopy import Tello
import cv2

tello = Tello()
tello.connect()

tello.streamon()
frame_read = tello.get_frame_read()

def show_frames():
    while True:
        img = frame_read.frame
        cv2.imshow("Tello", img)
show_frames()

yields a long stream of errors and warning with no video (regardless if it is presented on screen or saved to a file)

[INFO] tello.py - 122 - Tello instance was initialized. Host: '192.168.10.1'. Port: '8889'.
[INFO] tello.py - 437 - Send command: 'command'
[ERROR] tello.py - 457 - 'utf-8' codec can't decode byte 0xcc in position 0: invalid continuation byte
[INFO] tello.py - 437 - Send command: 'command'
[INFO] tello.py - 461 - Response command: 'ok'
[INFO] tello.py - 437 - Send command: 'streamon'
[INFO] tello.py - 461 - Response streamon: 'ok'
[h264 @ 0x1efe380] non-existing PPS 0 referenced
[h264 @ 0x1efe380] non-existing PPS 0 referenced
[h264 @ 0x1efe380] decode_slice_header error
[h264 @ 0x1efe380] no frame!
... etc. etc.
followed by:
[h264 @ 0x1efe380] error while decoding MB 55 40, bytestream -5
[h264 @ 0x23984c0] left block unavailable for requested intra mode
[h264 @ 0x23984c0] error while decoding MB 0 38, bytestream 3908
[h264 @ 0x23acc40] error while decoding MB 55 40, bytestream -5
[h264 @ 0x23984c0] error while decoding MB 13 36, bytestream -6
[h264 @ 0x23984c0] left block unavailable for requested intra mode
[h264 @ 0x23984c0] error while decoding MB 0 40, bytestream 2567
[h264 @ 0x21e6140] error while decoding MB 37 38, bytestream -12
[h264 @ 0x23984c0] left block unavailable for requested intra mode
... and so on.

If i capture the video using ffplay -v 0 -f h264 udp://0.0.0.0:11111, however, the video (though delayed and somewhat noisy) seems to work fine.

If I print the image stream I get arrays as values represented as strings. I would have thought it would be binary values.

[[[  4  44  86]
  [  6  46  88]
  [ 10  48  90]
  ...
  [ 84  92  89]
  [ 84  92  89]
  [ 84  92  89]]

 [[  5  45  87]
  [  6  46  88]
  [ 11  49  91]
  ...
  [ 90  98  95]
  [ 90  98  95]
  [ 90  98  95]]

 [[  4  46  90]
  [  2  44  88]
  [  6  46  90]
  ...
  [ 87  95  92]
  [ 87  95  92]
  [ 87  95  92]]

 ...

 [[ 65  74 114]
  [ 72  81 121]
  [ 75  84 124]
  ...
  [ 39  88  98]
  [ 36  85  95]
  [ 35  84  94]]

 [[ 70  79 119]
  [ 79  88 128]
  [ 81  90 130]
  ...
  [ 40  92 100]
  [ 41  91  99]
  [ 43  93 101]]

 [[ 70  79 119]
  [ 79  88 128]
  [ 84  93 133]
  ...
  [ 40  92 100]
  [ 43  93 101]
  [ 44  94 102]]]

Is there something I am missing here?

[Hoiidman]

Over 2 years later, have you found a solution?

[pbeeken]

No. I have kind of given up on the lab. I have some other tools I now use to achieve the same pedagogical goal. I don't think the original development package is being supported anymore. Other issues I've had which are not the manufacturers fault given the price point of the drones: There is no servo control of motion so the drones can't help but drift about even in a closed environment (like a gym or large classroom). This defeats the whole idea of having the drones move in a controlled repeatable way.

[M4GNV5]

Sorry for the late response. In my experience the image based flight stabilization of the drones works very well (at least compared to other/cheaper drones ive tried).
Maybe the floor below your drone does not have enough difference to act as orientation and/or the light is too low?

Regarding your original problem:
The frame you printed does in fact look like a proper frame, so everything seems to be working fine.
Maybe the cv2.imshow is broken somehow? Could you try using the latest djitellopy version running the take-picture example?
This way we can rule out problems with the video receiving (having a lot of spammy h264 messages is 'normal')