×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

SpaceX Landing Video Cleanup Making Progress

timothy posted about 6 months ago | from the from-worse-to-bad dept.

Bug 54

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.

Sorry! There are no comments related to the filter you selected.

Special edition (2, Funny)

abies (607076) | about 6 months ago | (#47171247)

Will they add small robots and funny looking animals in background later? I don't think that even cleaned version represents artistic vision of landing they had in mind.

Capricorn 1 (-1)

Anonymous Coward | about 6 months ago | (#47172009)

I commend SpaceX on their latest fraud. Better than Capricorn 1.

Just do it again (2)

Starvingboy (964130) | about 6 months ago | (#47171259)

To heck with fixing up the video, just launch another rocket already and try again.

Re:Just do it again (5, Interesting)

arse maker (1058608) | about 6 months ago | (#47171327)

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... [space.com]

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.

Re:Just do it again (4, Insightful)

Anonymous Coward | about 6 months ago | (#47171423)

This landing in particular holds some interesting extra data though, as this landing was during a storm strong enough to keep ships out of the area. So seeing how well the rocket performs in such extreme circumstances, where you can have considerable lateral wind loading, in as much detail as possible could be quite useful for later engineering work.

Re:Just do it again (2)

VideoPrincess (3683567) | about 6 months ago | (#47172799)

This is true - in the repaired video, the rocket can be seen adjusting its course significantly as it descends towards the sea. The control software seems to be able to cope with it well, which is good!

Re:Just do it again (0)

Anonymous Coward | about 6 months ago | (#47176253)

Actually, I think the "most important" parts are the leg extension segments. This was the first time that they had launched with legs, and the grasshopper/F9R-dev1 test flights had always had stationary legs. Getting video of the legs extending was super cool.

Re:Just do it again (5, Funny)

StripedCow (776465) | about 6 months ago | (#47171449)

Or they could just pay the license fee to unlock the DRM.

Re:Just do it again (1)

Anonymous Coward | about 6 months ago | (#47173363)

They should use the same software that's used on those CSI shows. Those police can enhance a cheap security camera image into a full color HD quality image that can zoom in and read a newspaper article from 3 blocks away.

Just do it again (0)

Anonymous Coward | about 6 months ago | (#47176221)

This is the video documentation of the very first soft "landing" of a rocket's first/booster stage. EVER. As such, it is documenting a huge milestone in rocketry/aeronautics (SpaceX was also able to get uncorrupted telemetry data). Maybe it's not quite on the same scale of the Wright Brother's first flight at Kittyhawk, but just getting the video from a subsequent launch isn't the same thing. This was the first major step in SpaceX's project to make a fully reusable launch vehicle. If they are eventually successful, they will have started a revolution in spaceflight. Or at least in access to space.

Besides, the next scheduled launch for SpaceX is scheduled for NET (not earlier than) June 12th, ~9pm EDT, so a night launch when there is not much hope of very good video of the booster's landing.

MM delicious government teat. (-1)

Anonymous Coward | about 6 months ago | (#47171265)

Italian fascism in full party mode.

cheap webcam (4, Funny)

Cheeze (12756) | about 6 months ago | (#47171297)

looks like they tried to use video conference software over a dialup modem with a webcam from 2001.

Re:cheap webcam (2, Insightful)

geogob (569250) | about 6 months ago | (#47171407)

The technical challenges of running a telemetry link with something falling through the sky from a moving aircraft has little to do with that of plugging two televisions together over a wired network. I'd expect the bandwidth for the video to be, in fact, comparable to that of a dial modem, especially considering that the bandwidth is shared with a lot of other housekeeping data which are probably much more important and useful than the video feed.

Re:cheap webcam (5, Interesting)

kaiser423 (828989) | about 6 months ago | (#47171841)

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 :)

Re:cheap webcam (3, Interesting)

mvpel (18165) | about 6 months ago | (#47172897)

The story we heard from SpaceX is that due to the weather, they couldn't get a boat out in the 15-foot seas, and the NASA chase plane they usually use wasn't available, so they went up in Elon's private jet equipped with an antenna jerry-rigged from a pizza pan stuck in the window. Maybe next time they'll use a Pringles can instead. :D

One of the mpeg experts was lamenting the encoding - there was no error correction enabled in the MPEG encoding, and the images were interlaced from an NTSC 29.97 down to a 15-fps feed into the encoder, and interlacing crushes the compression ratio, I gather. They've been informed of this, so hopefully the next launch will see some rock-solid quality video.

Re:cheap webcam (1)

kaiser423 (828989) | about 5 months ago | (#47256523)

I typically supply the NASA chase plane for downrange TM :) We could have supported, just weren't asked to (likely a cost thing and potential safety thing).

Re:cheap webcam (3, Interesting)

Anonymous Coward | about 6 months ago | (#47172497)

Well considering HOW they actually got the video, I guess it's not too shabby. Here's a quote from Musk from the recent Dragon v2 unveiling:

"As far as the soft landing of the boost phase, it was interesting, when we got the corrupted video back, because we really actually had a real difficult time getting the telemetry. In fact, I'll tell you a funny thing. We actually had to - because normally we get the bulk of the telemetry from a boat. We also have a backup, an AP3 that was going to go up, and the P3 got iced up, the boats couldn't go out, so I sent my plane up with my pilots, and... we had to design and fabricate an antenna that exactly fit in the window of the plane. We started off with a pizza dish and we were able to do a double loop antenna with a pizza dish and point it out the window to get the link."

Digital vs analog (2)

Hamsterdan (815291) | about 6 months ago | (#47171331)

Old debate, but analog video would at least be watchable (like analog vs DTV reception). Digital is nice and all, but it's all or nothing. Or they could have added error correction (what was the codec BTW?)

Re:Digital vs analog (1)

geogob (569250) | about 6 months ago | (#47171421)

But you wouldn't get it through the telemetry data feed. You'd have to have an separate analog transmitter just for the video feed. I'd say that it would be worth it if the video feed was critical. I doubt it is... it's most likely only a nice to have feature.

Re:Digital vs analog (1)

werepants (1912634) | about 6 months ago | (#47171587)

I believe the codec was FFMPEG - they've got one of the codec's authors helping out on the recovery effort.

Re:Digital vs analog (0)

Anonymous Coward | about 6 months ago | (#47171695)

Highly doubtful as ffmpeg isn't a codec... it's a software stack that uses other libraries (including libavcodec) to do the codec processing.

Re:Digital vs analog (0)

Anonymous Coward | about 6 months ago | (#47172597)

Correction: The codec was MPEG-2, which is why there was all of the talk about I-Frames and tweaking headers in the original stream. Much of the "error correction" is simply fixing up MPEG headers where it appears that the header may have been garbled up.

Yes, the author of FFMPEG is involved with this cleanup effort, but that is because he is familiar with the MPEG specification. That software seems to have been used by SpaceX in the encoding process of the video image in the first place though.

Re:Digital vs analog (3, Informative)

VideoPrincess (3683567) | about 6 months ago | (#47172761)

No, codec was MPEG4 as explained [nasaspaceflight.com] by the author of ffmpeg!

Re:Digital vs analog (3, Informative)

VideoPrincess (3683567) | about 6 months ago | (#47172747)

Codec was MPEG4 in an MPEG-TS transport stream. The author of ffmpeg confirms it here [nasaspaceflight.com] .

Re:Digital vs analog (1)

werepants (1912634) | about 6 months ago | (#47172871)

Good to know - I defer to you, as I have next to no idea what I'm talking about with video stuff.

Re:Digital vs analog (1)

arse maker (1058608) | about 6 months ago | (#47171685)

Sure but they weren't making a TV show. They have the telemetry (from what I can tell), its just the video that is so poor. Getting high bandwidth data from below the horizon of a fast moving object is hardly easy.

They will have nice enough videos when they bring the first stage back to land :)

Re:Digital vs analog (1)

citizenr (871508) | about 6 months ago | (#47171857)

FEC is a standard feature of any digital video broadcast

problem is they only have TS file from the receiver with badly interpreted FEC, not a raw stream of I/Q samples that can be worked on more extensively, so only way to recover anything now is to try and guess what went wrong in the receiver and what got shifted/xored.

It would be prudent in the future for SpaceX to have SDR as a backup receiver.

Re:Digital vs analog (1)

tibit (1762298) | about 6 months ago | (#47174851)

This! I can't agree more.

Re:Digital vs analog (0)

Anonymous Coward | about 6 months ago | (#47173697)

Old debate, but analog video would at least be watchable (like analog vs DTV reception). Digital is nice and all, but it's all or nothing. Or they could have added error correction (what was the codec BTW?)

Obviously digital isn't all or nothing as they did get something.

Summary of techniques used? (3, Interesting)

Whip (4737) | about 6 months ago | (#47171373)

I would *love* to see a summary of the types of problems the video stream has, and the techniques used to recover them. Anyone feel like sorting through the ~70 pages of thread and cataloging them? :)

Re:Summary of techniques used? (1)

Anonymous Coward | about 6 months ago | (#47171627)

Sorry- the people who could/would do this for you are.. you know.. actually helping with the restoration.

Re:Summary of techniques used? (2)

VideoPrincess (3683567) | about 6 months ago | (#47172701)

Some of us can spare the time! Ask any questions you want, I've been fixing the MPEG-TS data in the file.

Re:Summary of techniques used? (4, Informative)

werepants (1912634) | about 6 months ago | (#47171661)

I've been following the thread, but I don't know shit about video codecs or recovery so my understanding is limited at best. That said, it seems like FFMPEG (the codec used, I think) gains a lot of its compression by containing occasional keyframes that contain the full image, and then calculating deltas for providing subsequent frames. So, if you miss a few keyframes, you get huge swaths of video that are totally unintelligible. And, I think errors can cascade down into many subsequent frames because of the way the original image is modified and modified again.

As well, I get the impression that blocks within images can have the same sorts of issues, where an early bit or two in error can corrupt the entire thing. So, the effort has seemed to focus on trying to go through and fix keyframes first, and sometimes human pattern recognition can pick out the errors quickly, sometimes it looks like it has been a frame-by-frame trial and error where someone flips a bit and sees what comes out.

Given ~20 seconds of video, ~30 FPS, and probably several hundred blocks per frame, that's on the order of 100,000 pieces that are being repaired by human trial-and-error. It's a pretty herculean effort led by some extremely capable people.

Re:MPEG compression (0)

Anonymous Coward | about 6 months ago | (#47172541)

Your analysis is essentially correct.
I frames are essentially JPEG images.
P frames are deltas against the previous I or P frame.
B frames are deltas against the previous and following I and P frames.
https://en.wikipedia.org/wiki/... [wikipedia.org]

Re:Summary of techniques used? (1)

Anonymous Coward | about 6 months ago | (#47172853)

It's actually ~15fps - the camera itself is apparently running NTSC 29.97 fps and interlacing two frames to produce one frame to hand off to a non-interlaced MPEG encoding for transmission over the radio. "FFMPEG" is the open-source video software tool - see http://www.ffmpeg.org/

The cascading corruption occurs because each "macroblock" - an 8x8 square block of pixels - which makes up the video image can depend on the block above it or the block to its left, and for pframes, the corresponding block in the previous frame, and so you wind up with an error avalanche, as it were, as an invalid value spreads through each frame and through subsequent frames until the next iframe comes up 19 frames later to reset everything.

The Wiki page mentioned below has some good links to key explanatory forum posts.

Re:Summary of techniques used? (1)

adisakp (705706) | about 6 months ago | (#47174141)

FFMPEG is a program that supports hundreds of Codecs. It's likely they used a H264 or a compatible variant as the actual codec because a) its currently the most commonly used advanced video compression algorithm, b) there is plentiful hardware and software support for encoding / decoding, and c) it has a very good tradeoff for quality, bitrate, and processing horsepower required.

There is no guarantee you will get keyframes using H264 if you are compressing video without detectable screen cuts. Some H264 compliant codecs, like the very commonly used x264 library (used by FFMPEG), do not even need to have dedicated keyframes at all but rather use a technique called Periodic Intra Refresh [wikipedia.org] to encode videos without keyframes. Periodic Intra Refresh provides much better streaming /live capture performance since it lowers both encode and decode latency for transmission and it lessens the incidence and severity of data rate spikes when using variable bit rate compression schemes.

Re:Summary of techniques used? (1)

werepants (1912634) | about 6 months ago | (#47174747)

Ya, I realized that shortly after posting this. A more knowledgeable poster said it was MPEG4 in an MPEG-TS transport stream.

Re:Summary of techniques used? (5, Informative)

VideoPrincess (3683567) | about 6 months ago | (#47172671)

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 [nasaspaceflight.com] 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).

Re:Summary of techniques used? (0)

Anonymous Coward | about 6 months ago | (#47176267)

Ah, that's an absolutely wonderful link, thank you! That had a lot of the details I'm looking for.

One outstanding question I had, though -- do we have any idea why the corruption existed to start with? Was it just low signal strength so some bits got lost in the noise?

I WANT TO BELIEVE (2)

Thud457 (234763) | about 6 months ago | (#47171379)

It still looks like it was filmed with a Logitech potato.

Re:I WANT TO BELIEVE (1)

Anonymous Coward | about 6 months ago | (#47171419)

Unfortunately the hight quality cameras are specified for 0-70 degrees Celsius and indoors use only.

Re:I WANT TO BELIEVE (1)

mvpel (18165) | about 6 months ago | (#47173185)

Not to mention melting due to aerodynamic heating:
http://www.youtube.com/watch?v=7cvYIHIgH-s

you wouldn't throw away a car after one use... (2)

Thud457 (234763) | about 6 months ago | (#47173099)

Somebody needs to throw together one of those X-Files "I WANT TO BELIEVE" parody posters with a fuzzy Falcon 9 1st stage coming down for a fiery landing exactly as described by Ezekiel.

Conflicting advice. Great editting, timofee ! (0)

Anonymous Coward | about 6 months ago | (#47171409)

Poster: "It worth looking at the original video to see how bad it was *and then* at the latest restored video."

Timofee: "I'd suggest watching the restored version first"

Do Slashdot "editors" even read the stories they comment on ?

PROOFREAD... (0)

Anonymous Coward | about 6 months ago | (#47171515)

"It worth looking at"

Well done.

I've got an idea (-1, Troll)

rsilvergun (571051) | about 6 months ago | (#47171797)

just hire the guys that did the post production on the moon landing. I couldn't even see the wires much less the boom mics when those guys were done.

Mod this funny! (1)

SpammersAreScum (697628) | about 6 months ago | (#47184439)

Somebody with a major Humor Deficiency apparently moderated the parent.

Uncrop and enhance... (0)

Anonymous Coward | about 6 months ago | (#47171907)

.. then zoom out and enhance even more.

And we make laugh of arguably bad tv shows that extract DNA from random piece of hair found in the crack between two tiles on the floor near a crime scene...

VLC to the rescue! (0)

who_stole_my_kidneys (1956012) | about 6 months ago | (#47172479)

they just did a conversion in VLC and bamn! clear video!

For those of you carping (1)

Anonymous Coward | about 6 months ago | (#47172911)

Keep in mind that this was transmitting in a storm. As such, they were losing data. All in all, what they have cleaned up, has been impressive.

Next time (0)

Anonymous Coward | about 6 months ago | (#47173787)

use data partitioning and other error resilient features on the mpeg encoder. Defaults do not suit everyone, especially on video encoding field.

CSI to the rescue (0)

Anonymous Coward | about 6 months ago | (#47178379)

* video shows random noise because camera broke
* "We need to see some legs, can you do that?"
* Forensic shaman presses magic button "ENHANCE!"
* posts it on /.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?