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

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
Another way of doing this is to say to a block: don't "listen" to your left block, instead "listen" to the left "block" of 0,0 (initial state I guess). I believe these things are called "predictions" in mepg-4.

Implemented, example:
-mmb 40:3:-2
or
-mmb 20:19:-2:32:32:32:32:50:-11

Offline Okie_Steve

  • Full Member
  • ****
  • Posts: 1886
  • Oklahoma, USA
  • Liked: 1141
  • Likes Given: 725
Every block has 6 sub-blocks, 4 luma blocks (brightness) and 2 chroma blocks (color). The 4 luma blocks are the 4 squares in a block you often see. Both color blocks cover the entire block and are two different color planes. https://en.wikipedia.org/wiki/YUV There are 4 Y blocks and 1 U and 1 V block. Each one of those sub blocks references either the block above it or the block to the left of it (they all don't have to reference the same block). Which block they reference is determined on-the-fly (not hardcoded) so if a block is screwed up then it could cause blocks that would reference it, to not reference it or vice versa.
Hmmm, I suspect that color is not really important here, has anyone tried stripping/ignoring the chroma information and just generated "black & white"? The human visual system is *MUCH* more sensitive to intensity then color which is part of why the chroma is sampled at half (or less) of luma in most cases.

The data is there regardless, why not get it for free while we're at it?
Because approximately half of the bit stream is chroma information and hence half of the errors needing to be dealt with. Given the way errors cascade color is probably just a distraction in this case.

Offline John_L

More on frame 2...
this is not from the try1.ts file, the older one.

40:3:11229,16:10:18210,40:28:76955,25:8:18680,4:28:-1

Online Asmegin

  • Member
  • Posts: 37
  • Canada
  • Liked: 26
  • Likes Given: 3
Frame 3 is disgusting  >:(

I can't do anything with it (disclaimer: I have no idea what I'm doing)

Offline HALtheWise

  • Member
  • Posts: 1
  • Liked: 0
  • Likes Given: 2
Every block has 6 sub-blocks, 4 luma blocks (brightness) and 2 chroma blocks (color). The 4 luma blocks are the 4 squares in a block you often see. Both color blocks cover the entire block and are two different color planes. https://en.wikipedia.org/wiki/YUV There are 4 Y blocks and 1 U and 1 V block. Each one of those sub blocks references either the block above it or the block to the left of it (they all don't have to reference the same block). Which block they reference is determined on-the-fly (not hardcoded) so if a block is screwed up then it could cause blocks that would reference it, to not reference it or vice versa.
Hmmm, I suspect that color is not really important here, has anyone tried stripping/ignoring the chroma information and just generated "black & white"? The human visual system is *MUCH* more sensitive to intensity then color which is part of why the chroma is sampled at half (or less) of luma in most cases.

The data is there regardless, why not get it for free while we're at it?
Because approximately half of the bit stream is chroma information and hence half of the errors needing to be dealt with. Given the way errors cascade color is probably just a distraction in this case.
Unfortunately, the information that is needed to separate the chroma and intensity values has also been corrupted in many cases. AFAIK, until the macro blocks have been correctly identified and placed, separating the streams simply isn't possible. After that, however, it may in fact make sense to focus (at least initially) on bit-level corrections for the intensity alone before worrying about chroma. Most the I-frames haven't yet reached nearly-complete Macro block identification yet, though. It can also be much easier to identify the correct placement of blocks by using the color information.

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Frame 3 is disgusting  >:(

I can't do anything with it (disclaimer: I have no idea what I'm doing)

Agreed. It seems to be totally random noise.

Offline dorkmo

  • Full Member
  • ****
  • Posts: 710
  • Liked: 338
  • Likes Given: 848
Frame 3 is disgusting  >:(

I can't do anything with it (disclaimer: I have no idea what I'm doing)

Agreed. It seems to be totally random noise.

yeah i think its just the fact that it has so few bytes, its got 8927. while the best picture so far (iframe8) has 20428. i think its interesting that iframe 6 has the at most 29622 but so far looks just as garbled as others. might be the one with most room for improvement?

Offline GregA

  • Full Member
  • ****
  • Posts: 524
  • Liked: 269
  • Likes Given: 61
Amazing work guys, I'm really looking forward to the video, and wish I had knowledge/ability to add.

With something like I Frame 3, would you be able to reconstruct based on I-Frame 2 plus all the P & B frames applied (which would theoretically be one frame before the i-frame)? I haven't seen that kind of thing mentioned here. I would assume you theoretically could - but that if i-frame 3 is gone then the preceding frames are probably also junk.

Similarly, would you replace a junk i-frame with a generic shot (plain blue plus image of rocket?) to then have the change frames act on, or would you leave the junk frame? (Of course, you need a good generic shot of the rocket for that to be possible!)
« Last Edit: 05/08/2014 06:04 am by GregA »

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Frame 9, cleaned up some single-bit errors up top.

20:04:-1,24:04:16023,X:16410:01,16:5:-1,17:05:18692,X:19903:1,X:27244:1,
1:15:-1,3:16:79127,41:19:-1,8:20:96220,15:04:16023

More cleanup on iframe 9. I am less convinced now that the odd shapes on the right leg are bugged bits. They seem to be consistent across multiple blocks and sub-blocks.

X:19164:10,X:32551:80,X:32743:1,20:04:-1,24:04:16023,X:16410:01,16:5:-1,
17:05:18692,X:19903:1,X:27244:1,24:08:-1,25:08:32410,1:15:-1,3:16:79127,
41:19:-1,8:20:96220,15:04:16023

Online Shanuson

  • Full Member
  • ***
  • Posts: 395
  • Liked: 327
  • Likes Given: 2542
Frame 9, cleaned up some single-bit errors up top.

20:04:-1,24:04:16023,X:16410:01,16:5:-1,17:05:18692,X:19903:1,X:27244:1,
1:15:-1,3:16:79127,41:19:-1,8:20:96220,15:04:16023

More cleanup on iframe 9. I am less convinced now that the odd shapes on the right leg are bugged bits. They seem to be consistent across multiple blocks and sub-blocks.

X:19164:10,X:32551:80,X:32743:1,20:04:-1,24:04:16023,X:16410:01,16:5:-1,
17:05:18692,X:19903:1,X:27244:1,24:08:-1,25:08:32410,1:15:-1,3:16:79127,
41:19:-1,8:20:96220,15:04:16023

They look a bit like the holding clamps which attach the legs to the body of the rocket.

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
I was about to suggest that depending on the altitude at that moment, which you could probably estimate knowing the time interval between iframes 9 and 10, perhaps the apparent distortion of the center portion of the right leg could be a splash of brightly-illuminated water between the camera and the leg.

But then after looking at the emerging details of frames 7 and 8, I'm beginning to fear your suspicions may be correct that they are not bugged bits but rather a big gnarly dent in the leg.  :o Maybe a chunk of muddy ice smashed into it in just the wrong way?

Looking at the image of the freshly-installed legs it's hard to picture how something like that could have happened, but then again I've seen the heartbreaking proof of what a mere  chunk of foam can do to composite structures with my own eyes down at the USSRC in in Huntsville. I fervently hope that the meticulous grooming of the iframes you guys are doing will prove this notion wrong. Keep up the utterly amazing, amazing work! You guys deserve medals!
« Last Edit: 05/08/2014 07:57 am 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 arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I was about to suggest that depending on the altitude at that moment, which you could probably estimate knowing the time interval between iframes 9 and 10, perhaps the apparent distortion of the center portion of the right leg could be a splash of brightly-illuminated water between the camera and the leg.

But then after looking at the emerging details of frames 7 and 8, I'm beginning to fear your suspicions may be correct that they are not bugged bits but rather a big gnarly dent in the leg.  :o Maybe a chunk of muddy ice smashed into it in just the wrong way?

Looking at the image of the freshly-installed legs it's hard to picture how something like that could have happened, but then again I've seen the heartbreaking proof of what a mere  chunk of foam can do to composite structures with my own eyes down at the USSRC in in Huntsville. I fervently hope that the meticulous grooming of the iframes you guys are doing will prove this notion wrong. Keep up the utterly amazing, amazing work! You guys deserve medals!
I suspect what happened is that one of the bolts attaching the leg to the rocket did not let loose. So that part of the leg snapped off and is still attached to the body of the rocket. This event is somewhere in this video!
« Last Edit: 05/08/2014 08:09 am by arnezami »

Offline luinil

It would be interesting to see if we can determine if the part of the leg is still on the rocket body (that would confirm the hypothesis).

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
It would be interesting to see if we can determine if the part of the leg is still on the rocket body (that would confirm the hypothesis).
It could also have damaged the sidewall of the rocket. Maybe bending it outwards or possibly creating a hole.
« Last Edit: 05/08/2014 08:12 am by arnezami »

Offline ugordan

  • Senior Member
  • *****
  • Posts: 8520
    • My mainly Cassini image gallery
  • Liked: 3543
  • Likes Given: 759
I suspect what happened is that one of the bolts attaching the leg to the rocket did not let loose. So that part of the leg snapped off and is still attached to the body of the rocket.

That sounds plausible, IMHO.

Offline fatdeeman

  • Full Member
  • *
  • Posts: 134
  • Liked: 112
  • Likes Given: 29
I suspect what happened is that one of the bolts attaching the leg to the rocket did not let loose. So that part of the leg snapped off and is still attached to the body of the rocket. This event is somewhere in this video!

That sounds very plausible to me, those rams look similar to what you would see on an excavator so it was going to fully deploy whether the leg was partially attached or not, if the ram is as powerful as it looks then causing that damage wouldn't have made it break a sweat!

Online eriblo

  • Full Member
  • ****
  • Posts: 1367
  • Sweden
  • Liked: 1670
  • Likes Given: 270
How sure can we be that it's actual damage to the leg? The "cutout" edges matches the video block, which for at least the first and the second image is obviously corrupt in some way. That the same block would be corrupt in all three images is of course a coincidence, but there are a lot of errors and they are most visible in these high contrast blocks (going from water to leg).

Two other things: First, it's hard to see the leg cylinder in these images, shouldn't it show more clearly at least in the last image (although we might be well into sub resolution territory here ;))? Second, I have a hard time believing that the bolts would be designed to be stronger than the leg - if it fails to release the failure modes you want are either failure to release the leg or failure of the bolt, not ripping half the leg and/or chunks of the tank off.

Also remember that even if the pistons are capable of large forces (lets say about 10-15 tonnes) they have a very small leverage during the start of the extension - maybe even negative, see relevant discussion threads.

EDIT to add: Relatively large forces (mass/4 times 1.5 or so for the angle) are only necessary if the legs support the stage on gas pressure alone, which is much less likely than some sort of locking mechanism. Even so they are nowhere close to hydraulic systems that operate at a magnitude higher pressure.
« Last Edit: 05/08/2014 09:29 am by eriblo »

Online Shanuson

  • Full Member
  • ***
  • Posts: 395
  • Liked: 327
  • Likes Given: 2542
Frame 3 is disgusting  >:(

I can't do anything with it (disclaimer: I have no idea what I'm doing)

Agreed. It seems to be totally random noise.

yeah i think its just the fact that it has so few bytes, its got 8927. while the best picture so far (iframe8) has 20428. i think its interesting that iframe 6 has the at most 29622 but so far looks just as garbled as others. might be the one with most room for improvement?

Can it be that due to bit errors the size of Iframe3 is not correctly determined and part of IF3 is interpreted to be part of the next frame?

Cheers
Shanuson

Offline Microphobe

  • Member
  • Posts: 5
  • Liked: 9
  • Likes Given: 4
But then after looking at the emerging details of frames 7 and 8, I'm beginning to fear your suspicions may be correct that they are not bugged bits but rather a big gnarly dent in the leg. 

Hi, I think it might be some sort of splodge of high refractive index stuff on the camera bending light around it (see attached image: red circle in same place on the two frames, aligned them using the black mark above it) Its an oval region without any internal texture (ie blurred) in all other frames AFAICS, bordering another dirty mark, and still appears to be there in frame 12 where the leg is underwater. I reckon the leg was probably OK until hitting the water, but it would be nice to get more clear images of the "splodge".

Great work guys, although I don't understand a word of what you are talking about re: video decoding !!

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Aligned iframe 1 from the previous solutions with:

-mmb 40:00:-1,14:02:5342,41:02:-1,7:05:17826,26:12:-1,0:14:50695,43:14:-1,31:16:66620,
7:21:-1,10:21:-1:-5:10:0,11:21:-1,20:21:87382,25:21:-1:0:-20:0,26:21:87827,
22:27:-1,28:27:109726,41:27:-1,03:28:112199,09:29:-1,15:29:131724,20:29:-1,24:29:132485

there are still two small sequences which I +/- randomly put: 14:02:5342,41:02:-1 and 0:14:50695,43:14:-1, and line 21 could be improved
« Last Edit: 05/08/2014 10:59 am by SwissCheese »

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1