Today I played a bit more with the quadcopter. My idea was to dump the video stream somehow and find out how the video was encoded. My idea was to create a TCP socket to port 8888, write the 106 byte magic message that I saw the mobile app send before the quadcopter starts spitting out what looks like a video stream and then read whatever comes from the quadcopter. The following Python script can do this:
import socket import sys s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('172.16.10.1', 8888)) magicword='495464000000580000009bf89049c926884d4f922b3b33ba7eceacef63f77157ab2f53e3f768ecd9e18547b8c22e21d01bfb6b3de325a27b8fb3acef63f77157ab2f53e3f768ecd9e185eb20be383aab05a8c2a71f2c906d93f72a85e7356effe1b8f5af097f9147f87e'.decode('hex') s.send(magicword) data = s.recv(106) n=0 while n<1000: #write replace by while 1 if you want this to not stop data = s.recv(1024) sys.stdout.write(data) n=n+1 s.close()The result -almost- worked straightaway. You will notice in the code above that I discard the first 106 bytes that the quadcopter returns, this seems to correspond to one of these magic messages that the app and the quadcopter exchange and I have no idea what they mean. The rest of the data that comes from the quadcopter seems to be raw h264 video stored in "nal" format. I dumped the output I got and managed to play it in vlc using the following commands:
$ python test.py > video.h264 $ vlc video.h264 --demux h264The vlc successfully plays the video but complains about some errors in the headers.
My next step is to find a proper way to read the TCP stream and make some video player play it with the lowest possible lag. I'll keep you posted.