SpaceX (rocket company) recently conducted a test on their latest re-supply mission to the International Space Station. It involved adding legs to the first stage of the rocket (the bottom, big part, which usually drops into the ocean and sinks) and 'soft landed' it over the ocean. Here is a test vehicle that shows what I mean:
During the actual CRS3 launch, the on-board camera transmitted video to a nearby plane before 'soft landing' and sinking in the ocean, and the video is pretty bad. Wondering if any experts here could help?
The best their team could do:
Raw TS File: http://www.spacex.com/sites/spacex/files/raw.ts
Repaired TS file: http://www.spacex.com/sites/spacex/files/repair1.ts
If you can fix it, email them in the link on their site.
+ Reply to Thread
Results 1 to 15 of 15
- recorded over a very lossy RF link.
- MPEG 4 Part 2, P/I 15, 15fps, NTSC, fixed bitrate
- repaired version includes the following: First we took a pass on the data to align every MPEG packet on a 188 byte boundary and set the packet start byte to 0x47. Then we identified blocks within keyframes that contain bit errors, and then manually flipping bits in those corrupt blocks to see if it recovers more of the image.
The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:
4703e8: 15,014 times
471fff: 4,966 times
4743e8: 263 times
474000: 81 times
474020: 74 times
The actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data.
The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".
It looks pretty hopeless to me, especially if rocket scientists can't fix it.I am not responsible, and it's been proven over and over again.
If a TS cannot withstand the sheer enormity of errors, you have a very error-prone transmission indeed! I hate to say it, but with the exception of those 2 moments, the current "repaired" version is really no better than the raw version. Where to start? You truly wouldn't know where the error was entering in, and with 23,838 TS packets, it's like a domino effect.
Too bad you hadn't a 3-way storage (local solid-state, broadcast to 1 plane, broadcast to 2nd plane or base), because that would isolate (and hopefully remove) different KINDS of errors.
Not sure to whom you were addressing there, lordsmurf, but if it was me, I'd say "potato - potahto". When digital media is compressed, it gives it a degradation fragility to the data that is similar to analog, and attempts to correct the structural bits start overlapping with attempts to improve the elemental quality.
Restoration implies the content is there, just ugly.
Recovery implies it's not there, as is the case here.
There's a difference.
Just a quick update, a few guys (including Michael Niedermayer of FFmpeg) are doing some amazing work with this on the nasaspaceflight.com forum. They're painstakingly repairing the I-Frames with a customized version of FFmpeg, and it's progressing:
Go SpaceX! Is that the Tesla guy?
Don't count these guys out yet..
This is with correct I-Frames.
The P-Frames are the next objective, I believe.
Not perfect by any means, but that is a HECK of a lot better! I'm impressed.
Last edited by Asmegin; 23rd Jun 2014 at 19:18.
It still has a ton of data corruption that, as I said to being with, essentially makes it a series of stills. You can probably get back the I frames, but good luck with the P, and especially the B -- especially on long GOP formats.
SpaceX should be ashamed of themselves for using such a crappy camera setup, with a low resolution.