Author Topic: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread  (Read 911732 times)

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1929
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 524
  • Likes Given: 210
My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.

Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.
« Last Edit: 05/09/2014 02:06 PM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
Also, for completeness, this guy commented on the wiki page but has not posted in this thread:

http://aeroquartet.com/wordpress/2014/05/08/spacex-falcon-first-stage-landing-part-ii/

Seems to know his stuff. From his page,

Quote
I have seen in some forums that people is trying to improve the video by fixing the TSHs.
This doesn’t hurt, but it will not improve the video, because while TSHs are easy to fix, a bad TSH indicates that probably several bits in the neighborhood are also bad. And those are the critical ones, and video won’t improve until you fix them all.

As mentioned previously, an error rate higher than 1/50,000 is impossible to fix. And if you have bad TSHs you probably have an order of magnitude more errors than that in the neighborhood.

Sound's pretty pessimistic to me :/

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1929
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 524
  • Likes Given: 210
Also, for completeness, this guy commented on the wiki page but has not posted in this thread:

http://aeroquartet.com/wordpress/2014/05/08/spacex-falcon-first-stage-landing-part-ii/

Seems to know his stuff. From his page,

Quote
I have seen in some forums that people is trying to improve the video by fixing the TSHs.
This doesn’t hurt, but it will not improve the video, because while TSHs are easy to fix, a bad TSH indicates that probably several bits in the neighborhood are also bad. And those are the critical ones, and video won’t improve until you fix them all.

As mentioned previously, an error rate higher than 1/50,000 is impossible to fix. And if you have bad TSHs you probably have an order of magnitude more errors than that in the neighborhood.

Sound's pretty pessimistic to me :/

Quote
I’ve been repairing videos full time for the last 7 years, so I immediately knew that the bitstream was corrupt and that at best we could hope to partially fix some frames. Maybe a 50% chance of recovering one or two frames.

I think he's referring to restoring it to 100% working video. If he wasn't, we already vastly beat his predictions. Not sure whether to trust his posts or not. Either that or his experience isn't as much as he claims it is as I'm apparently doing better than him with 1 week of experience and possibly superior tools.

Repairing the TSHs is important for getting access to the frames, that was already done. We're going beyond his anticipations and repairing the iframes which in a properly repaired transport stream (or newly created transport stream) will produce a possibly working video.
« Last Edit: 05/09/2014 01:56 PM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline moralec

Here's what I have so far. It's about 2-3 seconds of video almost up to splashdown:

[youtube]<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/CxheyOUAlG8"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/CxheyOUAlG8" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>[/youtube]

This looks good. Was this only adding the improved iframes to the video as described earlier?

Offline SwissCheese

  • Full Member
  • *
  • Posts: 164
  • Liked: 249
  • Likes Given: 90
My meager contribution for iframe 10
0:3:8818,0:4:11564

This reveals another two rows of blocks showing sea spray, but corrupts the rest of the image in a way that I haven't figured out how to fix.  Help me SwissCheese, you're my only hope!

Fantastic effort everyone.

It improved a bit the image, I also added a line with the new option -2 to avoid having the flame "contaminating" the image bottom:

43:2:-1,
0:3:8818,4:5:-1,
7:5:14847,18:05:-1,
0:7:18695,23:13:-1:-30:-30:-30:-30,24:13:-1,
0:16:-2:50:50:50:50,0:17:-1,
7:17:47677

« Last Edit: 05/09/2014 02:27 PM by SwissCheese »

Online AncientU

  • Senior Member
  • *****
  • Posts: 5791
  • Liked: 3642
  • Likes Given: 5055
Here is a give comparing IF5 and IF8,
legs lookl like they are not yet in their final position.

Created with via Imgflip GIF Maker
Agree.  You can also see the end of the (left) leg in 5 where it mates to the tip fairing -- this piece would only be visible if the legs were basically still pointing up (at say 30-60 degrees from fully stowed).  The longest extent of the legs away from the stage axis would be just before reaching 90 degrees.

Edit: typos (need more coffee)
« Last Edit: 05/09/2014 02:35 PM by AncientU »
"If we shared everything [we are working on] people would think we are insane!"
-- SpaceX friend of mlindner

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1929
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 524
  • Likes Given: 210
My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.

Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.

I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline mvpel

  • Full Member
  • ****
  • Posts: 1124
  • New Hampshire
  • Liked: 1295
  • Likes Given: 1686
I think he's referring to restoring it to 100% working video. If he wasn't, we already vastly beat his predictions. Not sure whether to trust his posts or not. Either that or his experience isn't as much as he claims it is as I'm apparently doing better than him with 1 week of experience and possibly superior tools.

MLindner, I think the key advantage which you and your one week of experience bring to the table is that you have no idea what's supposed to be impossible.  :D

Perhaps because he does video recovery as a business, he never considered the possibility of a team of people staying up until the wee hours of the morning fueled by Red Bull and Doritos twiddling bit combinations in a single macro block of a single iframe looking for the best incremental improvement in a nearly-uniform stretch of blue ocean among hundreds of variations, because no customer could ever afford that, even ULA. (I hope he's not wasting a bunch of time trying to suss out more of iframe 8 on his own.)

Since the remuneration for the folks here, and your cheering section, is not mere cash but the excitement of seeing these historic images emerge from the tangled snarl of the transport stream, it becomes an affordable effort. I wonder if they'll have this discussion thread on display next to the restored video that visitors will find looping at the kiosk in front of the first recovered Falcon 9R at the Smithsonian?  ;D
« Last Edit: 05/09/2014 03:03 PM by mvpel »
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline Swatch

  • Full Member
  • **
  • Posts: 273
  • Official Aerospace Engineer as of June 13th, 2009
  • Cincinnati
    • ProjectApollo/NASSP: Virtual Systems and Flight Simulation of the Apollo Program
  • Liked: 28
  • Likes Given: 16
More work on iframe8. Will post the mmb later.


Did you ever post the mmb for this?
Ex-Rocket Scientist in Training, now Rocket Scientist!
M-F trying to make the world of the future a smaller place through expanding horizons...

Offline Shanuson

  • Full Member
  • **
  • Posts: 272
  • Liked: 184
  • Likes Given: 466
My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.

Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.

I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.

Also the Postion in the Video suggest that interpretation:
iFrame2 at 1146612
iFrame3 (which probably is no iFrame) at 1207712
iFrame 4 at 1446284

all other iFrames are also separeted by around 300000 bits.

Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?
Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3.

Cheers,
Shanuson


Offline SwissCheese

  • Full Member
  • *
  • Posts: 164
  • Liked: 249
  • Likes Given: 90
My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.

Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.

I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.

Also the Postion in the Video suggest that interpretation:
iFrame2 at 1146612
iFrame3 (which probably is no iFrame) at 1207712
iFrame 4 at 1446284

all other iFrames are also separeted by around 300000 bits.

Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?
Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3.

Cheers,
Shanuson

I do not know for the beginning, but for iframe 6 the blocks are "heavier"  (more bits)  than in the other iframes. The file is roughly twice larger than the other ones.

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1929
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 524
  • Likes Given: 210
More work on iframe8. Will post the mmb later.


Did you ever post the mmb for this?

That was a hackjob i threw together in time for Chris's article. I wasn't exactly happy with how I did some of the erasing of parts of the image. I'll release something better later. Right now I'm fussing with the transport stream to see if we can get the actual first iframe.
« Last Edit: 05/09/2014 04:10 PM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline moralec

My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.

Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.

I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.

Also the Postion in the Video suggest that interpretation:
iFrame2 at 1146612
iFrame3 (which probably is no iFrame) at 1207712
iFrame 4 at 1446284

all other iFrames are also separeted by around 300000 bits.

Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?
Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3.

Cheers,
Shanuson

I do not know for the beginning, but for iframe 6 the blocks are "heavier"  (more bits)  than in the other iframes. The file is roughly twice larger than the other ones.

I have the feeling that there is at least two additional iframes before IF1. In the original video there is a section of the rocket surrounded by clouds, with no sea visible.

Offline mikes

  • Full Member
  • ***
  • Posts: 329
  • Norwich, UK
  • Liked: 67
  • Likes Given: 43
I am approaching it from a post-processing standpoint, so use ffmpeg to create a PNG, then consume the PNG with a separate application. My biggest limitation here is that the output has to go to file (due to image2 spec), so I have it writing to a ramdisk. Is there any way to have to write PNG data to stdout instead?
Have you tried using "-" as the output file specifier?

Offline david1971

  • Full Member
  • *
  • Posts: 196
  • Liked: 67
  • Likes Given: 6311
The first thing that went though my head when I read about the ORBCOMM launch delay was "this means the video folks will get a few extra days to get their clean version of a landing done before SpaceX has new video."

Offline rsnellenberger

  • Amateur wood butcher
  • Full Member
  • ****
  • Posts: 593
  • Houston, TX
  • Liked: 61
  • Likes Given: 19

The first thing that went though my head when I read about the ORBCOMM launch delay was "this means the video folks will get a few extra days to get their clean version of a landing done before SpaceX has new video."

Same here...

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1929
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 524
  • Likes Given: 210
My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.

Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.

I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.

Also the Postion in the Video suggest that interpretation:
iFrame2 at 1146612
iFrame3 (which probably is no iFrame) at 1207712
iFrame 4 at 1446284

all other iFrames are also separeted by around 300000 bits.

Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?
Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3.

Cheers,
Shanuson

I do not know for the beginning, but for iframe 6 the blocks are "heavier"  (more bits)  than in the other iframes. The file is roughly twice larger than the other ones.

I have the feeling that there is at least two additional iframes before IF1. In the original video there is a section of the rocket surrounded by clouds, with no sea visible.

Further investigation.

I think there is only a single iframe not being decoded. I found all the relevant frame headers and everything at 0x03E3EC position in the file.

0x000001B0 = visual_object_sequence_start_code
0x03       = profile and level indication
0x000001B5 = visual_object_start_code

There are exactly 13 of these patterns in this sequence in the transport stream. I did some copy and paste searching of the starts of the various iframe file dumps and each one lines up to one of these code sets. Importantly, we entirely skip the first set of these codes. The first iframe is the second set of these. I'm trying to figure out why its not decoding, but not there yet.

We also need to somehow disable iframe3 from being used as that will screw up any video that could possibly be correct that would otherwise reference iframe2.
« Last Edit: 05/09/2014 05:00 PM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 121
Further investigation.

I think there is only a single iframe not being decoded. I found all the relevant frame headers and everything at 0x03E3EC position in the file.

0x000001B0 = visual_object_sequence_start_code
0x03       = profile and level indication
0x000001B5 = visual_object_start_code

There are exactly 13 of these patterns in this sequence in the transport stream. I did some copy and paste searching of the starts of the various iframe file dumps and each one lines up to one of these code sets. Importantly, we entirely skip the first set of these codes. The first iframe is the second set of these. I'm trying to figure out why its not decoding, but not there yet.

We also need to somehow disable iframe3 from being used as that will screw up any video that could possibly be correct that would otherwise reference iframe2.

Here's the current iframe frame numbers and timestamps as best as I can make them out:

 1  33 19:35:03.6
 2  53 19:35:04.?
 3  57 ?
 4  73 19:35:??.?
 5  93 19:35:07.6
 6 113 19:35:08.9
 7 150 ?
 8 169 19:35:12.9
 9 188 19:35:14.3
10 207 19:35:??.?
11 227 19:35:1?.?
12 246 19:35:18.2

Assuming a few of the sequences are contiguous, we can reconstruct some timestamps.

 1  33 19:35:03.6
 2  53 19:35:04.9
 3  57 ?
 4  73 19:35:06.3
 5  93 19:35:07.6
 6 113 19:35:08.9
 7 150 ?
 8 169 19:35:12.9
 9 188 19:35:14.3
10 207 19:35:15.6
11 227 19:35:16.9
12 246 19:35:18.2

So, here are the gaps:

 2   53 19:35:04.9
-3   ?? 19:35:05.1
 4   73 19:35:06.3
 5   93 19:35:07.6
 6  113 19:35:08.9
-7a 13? 19:35:10.2
-7b 150 19:35:11.5
 8  169 19:35:12.9

It's possible the data for iframe 3 isn't even in the stream. We are clearly missing some p and b frames too.

Online seanpg71

  • Member
  • Posts: 26
  • Liked: 21
  • Likes Given: 0
So I could align better iframe 5 (coerced.ts) with the other ones and add a few sequences, still room for improvement.

We clearly see that the legs are not completely deployed!

0:0:550,14:0:-1,
0:5:9736,26:7:-1,
4:10:22722,25:12:32001,28:12:-1,16:13:-1:0:-25:0:0,17:13:-1:-15:0:0:0,
19:13:34518,10:14:-1,
17:14:39053,24:14:-1,21:15:-1:-25:-10,22:15:-1,
34:15:42349,24:16:-1,
27:16:47754,42:19:-1,
43:19:69441,43:20:-1,
01:21:76873,11:22:-1,
12:22:85489,26:22:-1,
17:23:91682,22:24:-1,
23:24:97869,00:27:-1,
16:27:109631,24:27:-1,
25:27:110437,28:28:-1,
3:29:124970

I added a few more sections to that.  Definitely still some more areas to get a bit of improvement from though.

0:0:550,14:0:-1,
32:4:9085,25:7:-1,
4:10:22722,25:12:32001,28:12:-1,
16:13:-1:0:-25:0:0,17:13:-1:-15:0:0:0,
18:13:34192,10:14:-1
17:14:39053,23:14:-1,
21:15:-1:-25:-10,
25:15:41044,
23:16:46465,
28:16:47954,
41:19:69012,
43:19:69441,43:20:-1,
1:21:76873,11:22:-1,
12:22:85489,26:22:-1,
27:22:87056,42:22:-1,
38:22:88152,10:23:-1,
11:23:91098,16:23:-1,
17:23:91682,22:24:-1,
23:24:97869,
0:25:100325,0:27:-1,
2:27:105388,
22:27:110276,30:28:-1,
31:28:121730,1:29:-1,
2:29:123876









Offline xcg001

  • Member
  • Posts: 1
  • Liked: 2
  • Likes Given: 0
Here's the current iframe frame numbers and timestamps as best as I can make them out:

 1  33 19:35:03.6
 2  53 19:35:04.?
 3  57 ?
 4  73 19:35:??.?
 5  93 19:35:07.6
 6 113 19:35:08.9
 7 150 ?
 8 169 19:35:12.9
 9 188 19:35:14.3
10 207 19:35:??.?
11 227 19:35:1?.?
12 246 19:35:18.2

Assuming a few of the sequences are contiguous, we can reconstruct some timestamps.

 1  33 19:35:03.6
 2  53 19:35:04.9
 3  57 ?
 4  73 19:35:06.3
 5  93 19:35:07.6
 6 113 19:35:08.9
 7 150 ?
 8 169 19:35:12.9
 9 188 19:35:14.3
10 207 19:35:15.6
11 227 19:35:16.9
12 246 19:35:18.2

So, here are the gaps:

 2   53 19:35:04.9
-3   ?? 19:35:05.1
 4   73 19:35:06.3
 5   93 19:35:07.6
 6  113 19:35:08.9
-7a 13? 19:35:10.2
-7b 150 19:35:11.5
 8  169 19:35:12.9

It's possible the data for iframe 3 isn't even in the stream. We are clearly missing some p and b frames too.

I am not a video specialist but looking at these timestamps there is ~1.3 seconds difference between each I frame so most likely there should be no I frame between frame 2 and 4.

Tags: