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

Offline grythumn

  • Full Member
  • **
  • Posts: 207
  • Liked: 116
  • Likes Given: 131
Ok, first try at auto-marking bad MBs based on ffmpeg log output and primitive analysis.

...

Edit: Here's the Java source if anyone else wants to play. http://pastebin.com/bKgzCRqD The mammoth inner class at the bottom is for writing the animated gif :)
Great stuff!!

One suggestion: when comparing a block with other block its best to only compare it with the one above and the one to the left.

This is because of how mpeg-4 works: the current block will directly affect the one below and the one to the right. So you are really comparing to yourself in a way. Also: if the current block is defect (or one until the one below is reached) it is very likely the block below is bit-shifted so you're not comparing the current block to what is supposed to be below it.

Keep that in mind.

Regards,

arnezami

Hmm ok so it is pointless to try manipulation in blocks past the first bad block? Basically we need to completely fix one bad block at a time?

I think you're okay fixing half-block errors that occur later in the image, but don't mess with full block or greater brightness/hue changes... they come and go freely as you fix earlier blocks. At least that's what I'm noticing on Frame 9... I'm having to revert some of my earlier edits.

-Bob
(the mad bit flipper)

Offline Shanuson

  • Full Member
  • **
  • Posts: 258
  • Liked: 171
  • Likes Given: 412
Working on those headers I found that some errors are single bit flips, but there are also stripes of bytes which are simply garbage/randomly turned bits one after an other. In an image you cant repair this I think. Substitute MBs maybe.
Headers can also be fixed, but if part of an frame MB itself is messed up like this you cant really hope to fixed it by flipping random bits.

Offline mvpel

  • Full Member
  • ****
  • Posts: 1116
  • New Hampshire
  • Liked: 1280
  • Likes Given: 1676
About the problem where the shift occurred: Frames are framed by large blocks of FFs with 47 1F FF 1X in them if they are large enough and X counting up. On Both sides of that IF7 they are already align. So the shift and reshift should have occurred between those. Maybe it is just enough to add a F at the end of the block before IF7 and remove one at the start of the block after IF7 (0x23cde9).

The X is the frame sequence number, which starts at zero and counts up through "F" and then back to 0 - this Wikipedia page about the MPEG transport stream has a good explanation of those four bytes starting with 0x47. The 1F FF 1X means:

0001 1111 1111 1111 0001

000 = no transport error, no payload unit start, no high priority
1 1111 1111 1111 = null packet identifier for fixed-bandwidth padding packets
0001 = 00 - not scrambled; 0 - no adaptation field; 1 - contains payload

This detail may help suss out what the packet headers should be in the bit-shifted packet. For instance, we know that the PID field can't take certain values like 0x0004 through 0x000F, etc.

Lining up the null packets in front of the bit-shifted one in a 47-column hex editor it's easy to see bad bytes, because we know that the 184 bytes following a 471FFF header should all be FF, such as this from raw.ts:

0023BB60  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 47 1F FF 18 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0023BB8F  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0023BBBE  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0023BBED  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 7F FC FF FF FF FD 7F F4 FF 7C F6 FF FF FF FF FF FF FF DE 7F 7D 76 FC F4 EB 6D 6F F6 FF 1F FD BF
0023BC1C  FF FF FF FF FF FF FF FB 03 EE 76 17 E0 1B DA 08 FF EB DF 14 C0 D8 61 01 F7 5F C8 3F FE 7B FF F8 7D 53 57 70 34 EB DC F3 3F 5C 82 FF F3 FE 3E


This packet-aligned-column view also allows you to see where the good packets pick up after this mangling - at 0x23BFDC with a 0x4703E81A, followed by 0x4703E81B. This also tells us that we have the right number of bytes in the scrambled interim, because the columns still line up.

Moving up the rows, it's easy to see where there's corrupted headers:

0023BC30 C0D86101 should be 4703E815, or something with a bit set to indicate a sequence discontinuity.
0023BCEC BE66AF8C should be 4703E816
0023BDA8 4703E817 is correct
0023BE64 77034818 should be 4703E818
0023BF20 77EB35EE should be 4703E819


So it seems like it should be practical to write a tool that can walk through the raw.ts and use the rules of the packet header formatting and sequence numbers to reconstruct a more coherent transport stream. Even just getting all the errors out of the null packets by replacing everything with FF might make it easier to discern good patterns.

Edit: For example, in raw.ts there are bytes missing or added between 0x37ACC and 0x371EC - that's the first place where the columns shift in a 47-column hex display.
« Last Edit: 05/10/2014 03:49 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 saliva_sweet

  • Full Member
  • ****
  • Posts: 508
  • Liked: 380
  • Likes Given: 1251
iframe 6 (try1)
Left leg is not fully deployed yet, but i'm perplexed by the tip of it. At least I think it's the tip because it doesn't look like a cloud or a foam spot on the sea. It kind of resembles the tip of the right leg on iframe 5, which shows the right leg in similar stage of deployment as left leg on this frame. The thing is it doesn't align. It's off by one block (half of macroblock). Is such an alignment error even possible?

Some macroblocks are highly suspect, they may be random noise that vaguely looks like information that I forced into the picture (18:12 and 25:12 are the main concerns).

Brace for mmb
X:82804:80,X:134444:80,0:0:583,39:0:5496,43:0:-1,2:1:6129,21:1:8584,22:1:8796,6:3:18105,
7:3:18276,9:3:29527,30:3:32359,31:3:-1,43:3:33591,2:6:44738,4:6:46341,5:6:48794,35:6:52255,
38:6:52740,40:06:52938,42:06:53105,0:7:53564,2:7:-1,4:10:55390,1:11:-1,10:11:63669,27:11:-1,
2:12:67622,17:12:70590,18:12:71241,19:12:71659,21:12:71834,23:12:-1,25:12:72549,26:12:72948,
27:12:73733,29:12:75341,33:12:-1,1:13:76584,2:13:-1,05:13:77037,30:13:83673,33:13:84191,
37:13:84690,14:14:87836,17:14:-1,19:14:88523,30:14:92989,8:15:95815,12:15:96507,15:15:96729,
22:16:109491,25:18:131296,42:18:135673,05:22:-1,27:22:173820,0:24:-1,27:24:192142,4:27:-1,
25:27:215436
« Last Edit: 05/11/2014 01:46 AM by saliva_sweet »

Offline maschnitz

  • Member
  • Posts: 3
  • Liked: 0
  • Likes Given: 11
If you zoom in on 6, it seems to me that 17:12 is sea foam, not the leg. The color and texture isn't right. (It'd be handy to have a magnifying glass on Slapbet for stuff like this.)

Then, I suspect 15:11 is actually 15:10. The bit offsets in rows 10 and 11 jump all over the place; there's a jump from 56129 to 63669 between 09:10 and 10:10, and by 00:11 we're at 68940.  The actual end of row 10 to 11 probably lives/lived early in that range; or earlier.
« Last Edit: 05/10/2014 10:33 PM by maschnitz »

Offline Jakusb

  • Full Member
  • ****
  • Posts: 586
  • NL
  • Liked: 307
  • Likes Given: 99
An improved version of the annotated iframe8 with many more common dirt spots I see in several other iframes.
They seem to be very useful for further aligning MB's in other iframes

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 508
  • Liked: 380
  • Likes Given: 1251
If you zoom in on 6, it seems to me that 17:12 is sea foam, not the leg. The color and texture isn't right. (It'd be handy to have a magnifying glass on Slapbet for stuff like this.)
This was my first assumption too, but there is no good place I can put it other that the top of the leg. It's very bright and causes a propagating streak if placed in other places. The range it can be in is constrained and it's in a longish piece of good data so it can't be moved much without either impinging on fixed pieces or raising the question where is the tip of the leg then. The leg section on the other hand is really dark and wants a very light macroblock on top of it.

Then, I suspect 15:11 is actually 15:10.
Can't be. 4:10 to 42:10 is a solid good piece of data anchored by the smudge on 26:10
« Last Edit: 05/10/2014 11:01 PM by saliva_sweet »

Offline maschnitz

  • Member
  • Posts: 3
  • Liked: 0
  • Likes Given: 11
Can't be. 4:10 to 42:10 is a solid good piece of data anchored by the smudge on 26:10

Good point.

Hmm. If you switch back and forth quickly between 'common_dirt2' (frame 8 ) and 6, 6's left leg is too long, not too short. And the right leg is a little short. So maybe 15:11 is more like 16:12? Then everything else shifts down and to the left one. The lower part of the leg isn't set in stone, I don't think. Or 15:12/13? Not sure, though. Wish I was more nimble with the MPEG format.
« Last Edit: 05/10/2014 11:24 PM by maschnitz »

Online seanpg71

  • Member
  • Posts: 26
  • Liked: 21
  • Likes Given: 0
So I tried to get something with iframe 4, but still a lot to do. I have to stop now for a few days so good luck to those who wish to improve it ;)

From try1.ts

5:1:4200,00:03:-1,
02:03:10968,10:03:-1,
17:06:22427,14:11:-1,
38:16:65876,19:17:-1,
00:19:78514,28:20:-1,
0:28:129509

At 17911 and 55810 there are also valid sequences, which I do not know exactly where to put, and I did not really try to improve the bottom of the frame.

Also some sequences from http://forum.nasaspaceflight.com/index.php?topic=34597.msg1195103#msg1195103 could help if put at the accurate place.
So I tried to get something with iframe 4, but still a lot to do. I have to stop now for a few days so good luck to those who wish to improve it ;)

From try1.ts

5:1:4200,00:03:-1,
02:03:10968,10:03:-1,
17:06:22427,14:11:-1,
38:16:65876,19:17:-1,
00:19:78514,28:20:-1,
0:28:129509

At 17911 and 55810 there are also valid sequences, which I do not know exactly where to put, and I did not really try to improve the bottom of the frame.

Also some sequences from http://forum.nasaspaceflight.com/index.php?topic=34597.msg1195103#msg1195103 could help if put at the accurate place.

I was able to add some more dubiously placed water to this.  But not getting much of anything in the parts that are actually interesting.  Not sure threre's a whole lot more I can do with 4.

5:1:-1,
11:1:5384,30:2:-1,
2:3:10968,10:3:-1,
13:3:14762,33:3:-1,
35:3:16382,
37:3:16550,34:4:-1,
6:5:17911,
30:5:19483,32:5:-1,
36:5:20286,8:6:-1,
9:6:21857,16:10:-1,
17:10:36140,13:11:-1,
17:11:39697,38:11:-1,
1:12:41855,16:12:-1,
29:12:43895,20:13:-1,
13:14:51698,38:14:-1,
14:15:51794,36:15:-1,
37:16:65876,18:17:-1,
14:18:74612,30:20:-1,
24:27:127453,6:28:-1

Note, this is from try1.ts.  It's fairly easy to port between coerced.ts and try1.ts frames though.  Just need to add/subtract an offset to account for the extra sections of data in try1.ts that aren't in coerced.ts.

Here's the diff and offset for frame 4.


Coerced      Try      Offset
0-4225        0-4225      0
              4225-5697   
4226-46912    5698-48384   1472
              48384-51328
46913-49856   51329-54272   4416
              54272-55744   
49857-66048   55745-71936   5888
              71936-73408   
66049-104323 73409-111683   7360
              111683-114627
104324-121984   114628-132288   10304
121985 - 132287
              132289-144485


« Last Edit: 05/10/2014 11:27 PM by seanpg71 »

Offline Jakusb

  • Full Member
  • ****
  • Posts: 586
  • NL
  • Liked: 307
  • Likes Given: 99
So I tried to get something with iframe 4, but still a lot to do. I have to stop now for a few days so good luck to those who wish to improve it ;)

From try1.ts

5:1:4200,00:03:-1,
02:03:10968,10:03:-1,
17:06:22427,14:11:-1,
38:16:65876,19:17:-1,
00:19:78514,28:20:-1,
0:28:129509

At 17911 and 55810 there are also valid sequences, which I do not know exactly where to put, and I did not really try to improve the bottom of the frame.

Also some sequences from http://forum.nasaspaceflight.com/index.php?topic=34597.msg1195103#msg1195103 could help if put at the accurate place.
So I tried to get something with iframe 4, but still a lot to do. I have to stop now for a few days so good luck to those who wish to improve it ;)

From try1.ts

5:1:4200,00:03:-1,
02:03:10968,10:03:-1,
17:06:22427,14:11:-1,
38:16:65876,19:17:-1,
00:19:78514,28:20:-1,
0:28:129509

At 17911 and 55810 there are also valid sequences, which I do not know exactly where to put, and I did not really try to improve the bottom of the frame.

Also some sequences from http://forum.nasaspaceflight.com/index.php?topic=34597.msg1195103#msg1195103 could help if put at the accurate place.

I was able to add some more dubiously placed water to this.  But not getting much of anything in the parts that are actually interesting.  Not sure threre's a whole lot more I can do with 4.

5:1:-1,
11:1:5384,30:2:-1,
2:3:10968,10:3:-1,
13:3:14762,33:3:-1,
35:3:16382,
37:3:16550,34:4:-1,
6:5:17911,
30:5:19483,32:5:-1,
36:5:20286,8:6:-1,
9:6:21857,16:10:-1,
17:10:36140,13:11:-1,
17:11:39697,38:11:-1,
1:12:41855,16:12:-1,
29:12:43895,20:13:-1,
13:14:51698,38:14:-1,
14:15:51794,36:15:-1,
37:16:65876,18:17:-1,
14:18:74612,30:20:-1,
24:27:127453,6:28:-1

Note, this is from try1.ts.  It's fairly easy to port between coerced.ts and try1.ts frames though.  Just need to add/subtract an offset to account for the extra sections of data in try1.ts that aren't in coerced.ts.

Here's the diff and offset for frame 4.


Coerced      Try      Offset
0-4225        0-4225      0
              4225-5697   
4226-46912    5698-48384   1472
              48384-51328
46913-49856   51329-54272   4416
              54272-55744   
49857-66048   55745-71936   5888
              71936-73408   
66049-104323 73409-111683   7360
              111683-114627
104324-121984   114628-132288   10304
121985 - 132287
              132289-144485


I changed 11:1:5384 to 22:1:5384 to properly align the dark dirt in top center... I really should give them numbers ;)
And also 30:2:-1 to 3:0:-1
Now a lot of dirt blobs start to align... Now I really gonna number them.. :)

5:1:-1,22:1:5384,0:3:-1,2:3:10968,10:3:-1,13:3:14762, 33:3:-1,35:3:16382,37:3:16550,34:4:-1,6:5:17911, 30:5:19483,32:5:-1,36:5:20286,8:6:-1,9:6:21857, 16:10:-1,17:10:36140,13:11:-1,17:11:39697,38:11:-1, 1:12:41855,16:12:-1,29:12:43895,20:13:-1,13:14:51698, 38:14:-1,14:15:51794,36:15:-1,37:16:65876,18:17:-1,14:18:74612,30:20:-1,24:27:127453,6:28:-1

Offline Jakusb

  • Full Member
  • ****
  • Posts: 586
  • NL
  • Liked: 307
  • Likes Given: 99
A version with the dirt spots numbered for better reference in conversation

Edit: Added dirt group 14
« Last Edit: 05/10/2014 11:59 PM by Jakusb »

Offline Jakusb

  • Full Member
  • ****
  • Posts: 586
  • NL
  • Liked: 307
  • Likes Given: 99
iframe 4:

I see another dirt group (14) that needs to go 39 blocks left (or 1 row down and 5 to right)
However I could not get it to work yet

Offline Shanuson

  • Full Member
  • **
  • Posts: 258
  • Liked: 171
  • Likes Given: 412
<snip>
The following is how it should look like IMHO.
There are 3 blocks of XXs which are different for each frame. The first one seems to contain a counter. The rest i dont know. But it should be mentioned in that ISO*.pdf how they should look like/what they should contain.

47 43 E8 37 07 10 00 xx xx xx 7E 00 00 00 01 E0 00 00 81 80 07 21 01 xx xx xx FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 xx xx 9A FC 7C 2E EE 2C 08 78 28 C7 00 00 01 B2 65 6D 34 76 20 34 2E 33 2E 30 4E 31 40 C3 FF 00 00 01 B6 1x

<snip>

The first xx xx xx is a counter. From Iframe to Iframe it increases by 60060. (the 2 red ones are calculated with this information)

Frame   Hex    Dec
IF01   2B31E7   2830823
IF02    2c1c83    2890883
IF03    2d071f    2950943
IF04    2df1bb    3011003
IF05    2edc57    3071063
IF06    2fc6f3    3131123
IF07    30b18f    3191183
IF08    319C2B   3251243
IF09    3286c7    3311303
IF10    337163    3371363
IF11    345bff    3431423
IF12    35469b    3491483
IF13    363137    3551543
IF14    371bd3    3611603
IF15    38066f    3671663


The next block of XXs is part of the Presentation Time Stamp PTS
how to get the PTS is explained quite well here: http://dvd.sourceforge.net/dvdinfo/pes-hdr.html
PTS: 21 01 xx xx xx.
We can now decode the PTS of the good frames and define the PTS of the messed up ones.

It is late again, my bed is calling.
I will calculate the PTS tomorrow, also will work out that last xx xx.
Here are the raw 5 byte PTS of the frames:

IF00: 99 31 59 14 6C
IF01: 21 01 61 23 ED
IF02: 21 01 67 CE 5D
IF03: 21 01 6F 78 CD
IF04: 21 01 77 23 3D
IF05: 21 01 7D CD AD
IF06: 21 01 85 78 1D
IF07: 21 01 8D 22 8D
IF08: 21 01 93 CC FD
IF09:  21 01 9B 77 6D
IF10: 21 01 A3 21 DD
IF11: 21 01 A9 CC 4D
IF12: 21 01 B1 76 BD
IF13: 21 01 B9 21 2D
IF14: 21 01 BF CB 9D

Cheers
Shanuson
« Last Edit: 05/11/2014 12:15 AM by Shanuson »

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 508
  • Liked: 380
  • Likes Given: 1251
Hmm. If you switch back and forth quickly between 'common_dirt2' (frame 8 ) and 6, 6's left leg is too long, not too short.

Yes while deploying the leg looks longer because of perspective and that a fully deployed leg is pointing downward.

And the right leg is a little short. So maybe 15:11 is more like 16:12? Then everything else shifts down and to the left one. The lower part of the leg isn't set in stone, I don't think. Or 15:12/13? Not sure, though. Wish I was more nimble with the MPEG format.

I can see no way that this thing can be in any other row than the one it's currently in. Leg macroblocks look in correct and unchangeable positions to me. The only place it could go is to the right. It may be possible to calculate an approximate position based on known bitpositions and average macroblock size. But try1 seems to contain large chunks of junk so that approach is questionable.

Here's what it would look like if it was shifted 1 block to the right. Pretty weird, but kind of fits. Plus this change would lighten the columns under it and darken the ones to the left. And the leg tips look pretty weird on iframe 5 as well. But again, I do not know if that such a misalignment of blocks in macroblocks is even theoretically possible.

Offline JBF

  • Full Member
  • ****
  • Posts: 1314
  • Liked: 355
  • Likes Given: 549
Let me just say you guys are amazing.
"In principle, rocket engines are simple, but thatís the last place rocket engines are ever simple." Jeff Bezos

Offline mvpel

  • Full Member
  • ****
  • Posts: 1116
  • New Hampshire
  • Liked: 1280
  • Likes Given: 1676
Here's what it would look like if it was shifted 1 block to the right. Pretty weird, but kind of fits. Plus this change would lighten the columns under it and darken the ones to the left. And the leg tips look pretty weird on iframe 5 as well. But again, I do not know if that such a misalignment of blocks in macroblocks is even theoretically possible.

I do like the fit of that image, as you can make out the curve of the tip of the leg. Perhaps the bright white is another camera window artifact, like the missing part of the left side of the left leg - maybe it just caught the white border in just the right way in the light, and you wound up with a magnified or brightened reflection. There's a similar sort of oddity at the tip of the leg in the current rendition of frame 5 as you observed - perhaps nailing that down more fully would help figure this one out.
« Last Edit: 05/11/2014 01:05 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

Online seanpg71

  • Member
  • Posts: 26
  • Liked: 21
  • Likes Given: 0


I changed 11:1:5384 to 22:1:5384 to properly align the dark dirt in top center... I really should give them numbers ;)
And also 30:2:-1 to 3:0:-1
Now a lot of dirt blobs start to align... Now I really gonna number them.. :)

5:1:-1,22:1:5384,0:3:-1,2:3:10968,10:3:-1,13:3:14762, 33:3:-1,35:3:16382,37:3:16550,34:4:-1,6:5:17911, 30:5:19483,32:5:-1, 36:5:20286,8:6:-1,9:6:21857, 16:10:-1,17:10:36140,13:11:-1,17:11:39697,38:11:-1, 1:12:41855,16:12:-1,29:12:43895,20:13:-1,13:14:51698, 38:14:-1,14:15:51794,36:15:-1, 37:16:65876,18:17:-1,14:18:74612,30:20:-1,24:27:127453,6:28:-1



More uninteresting parts of the image!

4:1:-1,22:1:5384,5:2:-1,6:2:7531,0:3:-1,2:3:10968,10:3:-1, 13:3:14762,33:3:-1,35:3:16382,37:3:16550,34:4:-1,6:5:17911,30:5:19483,32:5:-1, 36:5:20286,8:6:-1,9:6:21857,16:10:-1,17:10:36140,13:11:-1, 17:11:39697,38:11:-1,2:12:42062,16:12:-1,27:12:-1,29:12:43895,20:13:-1,13:14:51698, 38:14:-1,14:15:51794,36:15:-1,37:16:65876,18:17:-1,14:18:74612, 30:20:-1,41:20:91288,32:21:-1,34:21:96927, 25:22:-1,41:22:104774,0:24:-1,17:26:122506,0:27:-1,24:27:127453,6:28:-1


« Last Edit: 05/11/2014 03:19 AM by seanpg71 »

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
Working on those headers I found that some errors are single bit flips, but there are also stripes of bytes which are simply garbage/randomly turned bits one after an other. In an image you cant repair this I think. Substitute MBs maybe.
Headers can also be fixed, but if part of an frame MB itself is messed up like this you cant really hope to fixed it by flipping random bits.

Yeah, been working on the raw and the corruption is much worse than I had assumed. Not only are there huge swaths of garbage, but also probable missing bits (like the 4-bit offset that was found for sure).

Now I see where the aeroquartet guy was coming from - it *should* be impossible to repair this video - but all the more reason why the work being done here is so amazing. At the current pace, we'll have silky smooth HD video before the next launch :)

I'm going to continue playing with michaelni's tsfix, but I don't see a way that this can be brute-force cleaned. Missing (and possibly added) bits expand the search space well beyond computational feasibility. We might be able to tidy up some of the intermediate frames some, but the masters will have to be done by hand. So keep up the awesome work bit flippers and block movers!

One note to the maintainer of slapbet - it would probably be very easy to integrate my ffmpeg log parsing code into the webapp to enable bad-block highlighting with a checkbox. See ~499 of http://pastebin.com/bKgzCRqD and following - just string and integer parsing in Java which is a trivial port to js. 

Edit: also, a mouseover showing the x:y would be nice :)
« Last Edit: 05/11/2014 04:03 AM by theshadow27 »

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1887
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 465
  • Likes Given: 188
Working on those headers I found that some errors are single bit flips, but there are also stripes of bytes which are simply garbage/randomly turned bits one after an other. In an image you cant repair this I think. Substitute MBs maybe.
Headers can also be fixed, but if part of an frame MB itself is messed up like this you cant really hope to fixed it by flipping random bits.

Yeah, been working on the raw and the corruption is much worse than I had assumed. Not only are there huge swaths of garbage, but also probable missing bits (like the 4-bit offset that was found for sure).

Now I see where the aeroquartet guy was coming from - it *should* be impossible to repair this video - but all the more reason why the work being done here is so amazing. At the current pace, we'll have silky smooth HD video before the next launch :)

I'm going to continue playing with michaelni's tsfix, but I don't see a way that this can be brute-force cleaned. Missing (and possibly added) bits expand the search space well beyond computational feasibility. We might be able to tidy up some of the intermediate frames some, but the masters will have to be done by hand. So keep up the awesome work bit flippers and block movers!

One note to the maintainer of slapbet - it would probably be very easy to integrate my ffmpeg log parsing code into the webapp to enable bad-block highlighting with a checkbox. See ~499 of http://pastebin.com/bKgzCRqD and following - just string and integer parsing in Java which is a trivial port to js. 

Edit: also, a mouseover showing the x:y would be nice :)

This is all incremental. Anything you get us thats better than we have right now is progress!
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline arnezami

  • Full Member
  • **
  • Posts: 282
  • Liked: 262
  • Likes Given: 341
iframe 6 (try1)
Left leg is not fully deployed yet, but i'm perplexed by the tip of it. At least I think it's the tip because it doesn't look like a cloud or a foam spot on the sea. It kind of resembles the tip of the right leg on iframe 5, which shows the right leg in similar stage of deployment as left leg on this frame. The thing is it doesn't align. It's off by one block (half of macroblock). Is such an alignment error even possible?

If I understand your question correctly: yes.

It is possible the data from one block (not macroblock) is used by another block within the same macroblock. This would for example happen if somehow a bad bit was interpreted as a "stop-bit" of the data of a block. This way the next block (within the same macroblock) would use the data from its previous block. The other way around is also possible I believe.

This is all due to the variable length the VLC-codes can have. And they are the ones that have the "stop-bit". See here for more info on 8x8 block decoding.
« Last Edit: 05/11/2014 07:10 AM by arnezami »

Tags: