"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

And to continue the analogy... a new book will be written this Saturday....lol

Let's hope they have changed the page layout to contain additional information to help detect sentence boundaries, errors and such. This macroblock necromancy goes only so far.

Should let one of us hop on their plane with an SDR with a patchfeed into their radios.

three important things that should be communicated back to SpaceX:

1) turn on the error correction features in their camera/encoder (probably too late for Saturday's launch.. but maybe)

2) turn off interlace

3) make an analog recording of the telemetry stream..

(2)Why is anything still recorded using Interlaced processing(OK.. 1080i.. but still)? And my personal favorite.. TV commercials that are recorded in interlaced SD..

(3)High resolution(24bit with high sample rate) "Analog" copy of the data stream with time reference to assess where S/N and coherence are bad would be very helpful. I think I mentioned that many pages ago.

"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

I had a go at frame 1, I managed to find most of the timestamp and a bit of the top of the rocket (notice the darker feature bottom left, which appears to match some of the other frames - though I'm not sure how well its aligned).

One more note. X doesn't behave quite as you think. The bitmask is inverted. X:pos:1 actually flips the bit 8 positions away from pos. It reads the next 8 bits starting from pos with pos being the MSB of those 8 bits. If you want to flip just the target bit, do X:pos:80.

Ah, boundary conditions/endianness/alignment, how do I love thee. I start doing this manually, 01,02,04,08,10,20,40,80, increment by 8, then decided to automate it without looking at the source.

Empirically, it worked fairly well as a semi-targeted brute force search. The correct one should work better. I'm playing with a #define TRACE build, but don't understand quite what I'm doing when twiddling bits yet to narrow the search range smaller than the whole macroblock.

Ok, so no additional help from SpaceX tonight at least I'm told, as they are all busy bees with the next launch (including a lot in transit to the Cape). Again, this thread is being watched, big time, and by one rather well known name at SpaceX I'm reliably informed! So stay focused as much as you can with what we've got.

I'll get more eyeballs on it when I add a few paras and links to here in my F9 v1.1 Static Fire article tomorrow.

One more note. X doesn't behave quite as you think. The bitmask is inverted. X:pos:1 actually flips the bit 8 positions away from pos. It reads the next 8 bits starting from pos with pos being the MSB of those 8 bits. If you want to flip just the target bit, do X:pos:80.

Ah, boundary conditions/endianness/alignment, how do I love thee. I start doing this manually, 01,02,04,08,10,20,40,80, increment by 8, then decided to automate it without looking at the source.

Empirically, it worked fairly well as a semi-targeted brute force search. The correct one should work better. I'm playing with a #define TRACE build, but don't understand quite what I'm doing when twiddling bits yet to narrow the search range smaller than the whole macroblock.

-Bob

I pushed up one of michaelni's changes from the other day to the repo if you want to grab it. Adds some warnings when data is possible off. Haven't found it very useful. They print out in yellow.

Ok, so no additional help from SpaceX tonight at least I'm told, as they are all busy bees with the next launch (including a lot in transit to the Cape). Again, this thread is being watched, big time, and by one rather well known name at SpaceX I'm reliably informed! So stay focused as much as you can with what we've got.

I'll get more eyeballs on it when I add a few paras and links to here in my F9 v1.1 Static Fire article tomorrow.

Thanks for the heads up Chris... it's understandable with another launch coming up this weekend that everyone's busy with that ... and with that said...

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.

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?

I.e. 19.37.SS.mm timestamp spans MBs with following coordinates:* colums 1 and 2 are for "19" hours,* columns 3 and 4 are for ".35" minutes* column 5 is for dot between minutes and seconds* columns 6 and 7 are for SS. seconds* column 8 and 9 are for mm miliseconds* row 28 is for upper part of timestamp* row 29 is for lower part

And once I'm experimenting with the image, I can see the recognizable elements, having seen them the POS in the stream would let me fixate the coordinates of that MB in the mmb string.

This would let some parts of the frame to snap in places even if there are other errors. It look like if whole row of MBs decodes properly the second row "sticks to previous one visually and lets to recognize the picture.

Is there a sense in the approach?

Besides the timestamp there are other notable features to watch for:* dirt patch in the middle of top part of the picture.* engine* legs* stage body edges (left and right)* large dark spot above timestamp on the body of the stage* camera lens edge (left and right bottom corners of the frame)

How would one go about re-encoding the video with the replacement iframes, what's the command line for ffmpeg?

The following should workassuming you have extracted the frames with -vcodec copy into individual mpg4-img filesyou could replace one withffmpeg -framerate 44999/3003 -i ../tests/lena.pnm -s 704x480 -aspect 22:15 -f image2 -r 44999/3003 image120.mpg4-imgthe image this creates seems close enough to the original parameters to work

and the following would put it all back into one file:ffmpeg -i image%3d.mpg4-img -vcodec copy video.avi