Slashdot Mirror
SpaceX Landing Video Cleanup Making Progress
Maddog Batty (112434) writes 'The fine people at the NASA Space Flight Forum are making good progress on restoring the corrupted landing video reported earlier. It worth looking at the original video to see how bad it was and then at the latest restored video. It is now possible to see the legs being deployed, the sea coming closer and a big flame ball as the rocket plume hits the water. An impressive improvement so far and it is still being actively worked on so further refinements are likely.' Like Maddog Batty, I'd suggest watching the restored version first (note: the video is lower on the page), to see just what a big improvement's been made so far.
They will shortly, there was a planned launch last month but it has been pushed back for various reasons. http://www.space.com/25822-spa...
The fact they have this thing vertical at well below terminal velocity and apparently not spinning means the rest is just details. Controlling it down from supersonic is the hard part. They have made many successful landings with grasshopper from a vertical, low speed non spinning state.
Or they could just pay the license fee to unlock the DRM.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Video feeds are typically their own streams. They're typically in the couple of Mbit range, but really can be anything. We've had 10+Mbps video links, but they're typically high frame rate versus high resolution. The thing to remember here is that you can't do any real fancy compression or modulations schemes typically, so every a couple of Mb/s really isn't that high of resolution. This is because you know that you're dropping bits, you're signal is fading unpredictably, the signal propagation path is changing wildly, etc so things like QAM don't work, and compression actually hurts because you're often getting errors in the blocks, etc really throws a wrench in the whole thing. So you almost have to ship the video raw over some fairly inefficient modulation scheme like FM or SOQPSK (more efficient, but more likely to burst-lose lots of data).
:)
I took a quick look at the embedded video stream, and it looks like there would have been a better way to pack it (looks like some asynchronous frames inside, with multiple sync words inside needing to be correct to get a good frame, made it harder than it had to be. But still, this isn't easy stuff. I expect them to come out shooting next time though. They really didn't have much in the area to grab the video with good fidelity because they had other things to focus on, but this time I expect a bit more.
I do telemetry chase form aircraft, boats, etc for exactly this type of thing for a living. Fun job
Hi, I'm the user "Princess" on the NSF site and I've mainly been involved with cleaning up the file at the TS level. I can answer any questions you like. The best summary for the Slashdot audience would be this one by Lourens, it explains things simply without dumbing things down. The types of problems we have are basically that bits have been either flipped or (rarely) omitted. The flips tend to clump together, i.e. you'll get an area that's good and then an area that's awful. The work is approximately divided into two parts: fixing up the file, and fixing up the video that results. I work on fixing the file, and from that I can find extra frames and pieces of MPEG4 data for the video people. Fixing the video is done by using a modified version of ffmpeg that can change macroblock pointers, ordering, luma and chroma. This work is not done on the file directly and can't easily be mapped back to the file, so it's not just a question of flipping bits once you get to the video level. Other technical info: The video itself is a broadcast (fixed bandwidth) MPEG-TS stream containing one video stream, a 704x480 MPEG4 stream at approx. 15 fps (technically half the NTSC framerate which is 15000 / 1001 fps).