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?

CheersShanuson

Possible. Possibly with some better work on the transport stream that can be determined to be the case or ruled out. The try1.ts file's iframe3 is a bit larger than the others at 9005 bytes.

there are still two small sequences which I +/- randomly put: 14:02:5342,41:02:-1 and 0:14:50695,43:14:-1

Be careful how you pick blocks, you can start to create an image that does not represent reality. The lower portion of the rocket is not visible.

No no, I used iframe 2 to align the image features, only the two small mentioned blocks are not where they should be. There might be condensation on the lens or the rocket was in a cloud, reducing a lot the contrast.

In other news. Iframe8 is becoming amazing. I'm still working on the lower part, but if anyone want's to try their hand at blocks 05:21 through 27:21 or fixing the ugly color/brightness cast into the bottom right, it'd be much appreciated. That's bit 107247 to 108877 or 1630 bits spread over 23 blocks for an average of 71 bits per block.

MMB split out into multiple lines to be readable.08:14:-1:15:-15:1:14:-2:1,09:14:56683,05:21:-1:0:-20:-5:2,06:21:-1:-20:-20:6:5,07:21:-1:0:0:3:5,08:21:-1:0:0:0:0,09:21:-1:10:15:0:0,10:21:-1:15:15:0:0,11:21:-1:5:10,12:21:-1:5:3:0:0:-2,13:21:-1:4:4,14:21:-1,28:21:108878,X:126932:80,04:27:-1:0:-4:13:7,05:27:135412,X:143273:80,X:143386:80,06:28:144012

As a note, in every image there should be two black triangles in the bottom right corners. I suspect this is part of the camera housing. They are good cues for reconstructing the lower part of the image.

As to the previous conversation about things breaking off the legs. In this iframe you can clearly see a white lump on the right side that would probably line up with that leg. I'm reasonably certain that that section of the image isn't corrupted, or if it is corrupted would be very minor and something of the leg would still be showing. Good chance something actually did bust off.

Edit: One more thing. If this is actually the case, getting this video showing the break-off point suddenly becomes pretty important for SpaceX if they weren't aware of it. Gives more reason for us to continue work on it after Saturday's launch.

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".

I like that idea best! Phew! Good thinking! And if you peer at frame 10 in the right way you can start to make out a smudge there as well. You'd think that if it was a water droplet doing the lensing that it would move with the wind, so maybe it was some sort of damage to the window of the camera housing, or something that froze at a higher altitude and then didn't melt by the time it landed. We'll probably see more clearly when these heroic bit-wranglers persuade frames 4 and 5 to emerge and we can start to make out the deployment.

Maybe someone should try an alignment of frame 2 with the "smudge" idea in mind, coupling it with the little black quotation mark.

EDIT: Also, smudge or damage, either way it looks worse than it actually is. Take a look at the tip of the leg in the shop-floor photo: it's just a hollow shell of composite. And take a look at Grasshopper - the load-bearing pieces of the legs are the steel (or some sort of highstrengthtoweightium alloy) tubes, and even if the fairing got smashed by ice or ripped away from a stuck latch, it would have absolutely no implications for the business parts of the leg.

"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

As to the previous conversation about things breaking off the legs. In this iframe you can clearly see a white lump on the right side that would probably line up with that leg. I'm reasonably certain that that section of the image isn't corrupted, or if it is corrupted would be very minor and something of the leg would still be showing. Good chance something actually did bust off.

Edit: One more thing. If this is actually the case, getting this video showing the break-off point suddenly becomes pretty important for SpaceX if they weren't aware of it. Gives more reason for us to continue work on it after Saturday's launch.

Not sure, the waves on the water surface also missing in this section.

Rampant speculation about something "damaged" when it could as easily be a video artifact or misaligned video data block is why Elon and SpaceX are leary about releasing such things in the first place. To me the anamoly it looks like it has right angled edges which align with the macro blocks. Let's not get too crazy about this yet.

I have to go with the "smudge on the lens" theory as well. If (as appears to be the case) a suspiciously blank patch is present in the same location on the images from before leg deployment, as well as after the leg has been partly submerged, then it is very unlikely to be a physical chunk missing from the leg, in my non-expert opinion.

I have to go with the "smudge on the lens" theory as well. If (as appears to be the case) a suspiciously blank patch is present in the same location on the images from before leg deployment, as well as after the leg has been partly submerged, then it is very unlikely to be a physical chunk missing from the leg, in my non-expert opinion.

That's very true. Either way, we'll find out as we get the video completed.

Rampant speculation about something "damaged" when it could as easily be a video artifact or misaligned video data block is why Elon and SpaceX are leary about releasing such things in the first place. To me the anamoly it looks like it has right angled edges which align with the macro blocks. Let's not get too crazy about this yet.

I wouldn't call it "rampant" - that implies "unbridled" and "widespread," and nobody here seems particularly breathless and it's only been four hours. It's a little more than "idle," yes, but not "rampant." Plus, it's only been four hours and folks may already have come up with another fixed reference point for MB alignment in addition to the quotation mark. Welcome to the wonderful and exciting world of "crowdsourcing."

Logged

"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

Rampant speculation about something "damaged" when it could as easily be a video artifact or misaligned video data block is why Elon and SpaceX are leary about releasing such things in the first place. To me the anamoly it looks like it has right angled edges which align with the macro blocks. Let's not get too crazy about this yet.

I wouldn't call it "rampant" - that implies "unbridled" and "widespread," and nobody here seems particularly breathless and it's only been four hours. It's a little more than "idle," yes, but not "rampant." Plus, it's only been four hours and folks may already have come up with another fixed reference point for MB alignment in addition to the quotation mark. Welcome to the wonderful and exciting world of "crowdsourcing."

Any shape in highly compressed MPEG will tend to "blur" because of the reduction of the pixel data to sets of something akin to 2D Fourier transforms (Discrete Cosine Transform) resulting in "ringing" on any sharp edges in an image. Further those blurs cannot extend beyond the edge a block (or a sub-block) which can lead to sharp cutoffs.

Every 8x8 pixel sub-block is encoded like this. Example from wikipedia of encoding an image of the letter A.

In other news. Iframe8 is becoming amazing. I'm still working on the lower part, but if anyone want's to try their hand at blocks 05:21 through 27:21 or fixing the ugly color/brightness cast into the bottom right, it'd be much appreciated. That's bit 107247 to 108877 or 1630 bits spread over 23 blocks for an average of 71 bits per block.

MMB split out into multiple lines to be readable.08:14:-1:15:-15:1:14:-2:1,09:14:56683,05:21:-1:0:-20:-5:2,06:21:-1:-20:-20:6:5,07:21:-1:0:0:3:5,08:21:-1:0:0:0:0,09:21:-1:10:15:0:0,10:21:-1:15:15:0:0,11:21:-1:5:10,12:21:-1:5:3:0:0:-2,13:21:-1:4:4,14:21:-1,28:21:108878,X:126932:80,04:27:-1:0:-4:13:7,05:27:135412,X:143273:80,X:143386:80,06:28:144012

As a note, in every image there should be two black triangles in the bottom right corners. I suspect this is part of the camera housing. They are good cues for reconstructing the lower part of the image.

If this is actually the case, getting this video showing the break-off point suddenly becomes pretty important for SpaceX if they weren't aware of it.

They're bound to already have telemetry that would indicate this, if it indeed happened at all. Things like pressure vs. time profile in the cylinder compared to the other 3 indicating more resistance to deployment, etc.

In other news. Iframe8 is becoming amazing. I'm still working on the lower part, but if anyone want's to try their hand at blocks 05:21 through 27:21 or fixing the ugly color/brightness cast into the bottom right, it'd be much appreciated. That's bit 107247 to 108877 or 1630 bits spread over 23 blocks for an average of 71 bits per block.

MMB split out into multiple lines to be readable.08:14:-1:15:-15:1:14:-2:1,09:14:56683,05:21:-1:0:-20:-5:2,06:21:-1:-20:-20:6:5,07:21:-1:0:0:3:5,08:21:-1:0:0:0:0,09:21:-1:10:15:0:0,10:21:-1:15:15:0:0,11:21:-1:5:10,12:21:-1:5:3:0:0:-2,13:21:-1:4:4,14:21:-1,28:21:108878,X:126932:80,04:27:-1:0:-4:13:7,05:27:135412,X:143273:80,X:143386:80,06:28:144012

As a note, in every image there should be two black triangles in the bottom right corners. I suspect this is part of the camera housing. They are good cues for reconstructing the lower part of the image.

Edit: Attached before image.

Edit2: Forgot to mention. I used try1.ts iframe8.

That's amazing!

Key thing is that all the information is more or less still there. It's just that the nature of MPEG means that flipping a single bit from 0 to 1 (or reverse) can mean the entire image being decoded wrong. MPEG is designed to be error resilient despite this though (its how we all get our cable TV or satellite TV or over the air digital TV), just that SpaceX didn't turn on many of the error resilience features apparently that could have stopped the propagation of the errors as far as they did.