Video capture fails, though ffmpeg does capture video.
pbeeken opened this issue · 3 comments
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?
Over 2 years later, have you found a solution?
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.
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')