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

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1440 on: 06/07/2014 02:02 am »
Anybody in the Florida area want to get together for the OrbComm launch? I am working a temporary / long term assignment in Miami and considering driving to KSC for the OrbComm OG2 launch next Thursday (backup launch date is Friday).

I'll be in McGregor, Texas the evening of the OrbComm launch, after presenting at a symposium in Garland. If anyone would like to get together there, PM me too. :) I hope it doesn't slip, because Friday I'll be airborne flying home from DFW at that time.  :-\
"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 cscott

  • Senior Member
  • *****
  • Posts: 3471
  • Liked: 2867
  • Likes Given: 726
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1441 on: 06/07/2014 02:06 am »
But I bet it *would* be helpful if someone would compile a list of the adjusted start/end positions of the FEC coding blocks referenced to the current .ts and including the discovered bit shifts, etc, like princess did

I can calculate a mapping between file offsets in raw.ts and the current TS file if necessary, would this be useful?

Also, if people want to calculate statistics on the bitflip errors then I have TS files that have more fixes than the current TS file - my current versions have correct contents for all PIDs except the data PID, i.e. all padding is correct, the Program Association Tables and Program Map Tables are all correct and the "padding" AFs in the data are correct too. One of my side projects is trying to make a TS file that's "what the rocket transmitted", so I can make that available to people who are doing statistical anaylsis on the error distribution. Let me know what you need and I'll make it available.

I'd like to pitch in and follow up on this "triple bit flip" lead.  I *think* what I would need is:
1) the raw.ts file (no problem there)
2) princess' "corrected as best as possible" .ts file.

Are there extra bits inserted into (2)?  If so, then I'd have to correlate (1) and (2).  But otherwise it should be easy to retrace ajmartin's steps and figure precisely what he's talking about here:
The postulated 56-byte FEC coding blocks turn out to be composed of alternate 25-byte and 31-byte "sub-blocks", starting at (zero-based) offsets of the form 56n + 29 and 56n + 54.  Single bit-flips are found only in the first and last 15 bits of these blocks, with possible rare exceptions in high-error regions.  All other bit-flip errors are combinations of "triple flips" (i.e., bit shifts of 0x8003) that do not cross the block boundaries.

(That does not include frame-shift errors such as the one originally found by Shanuson, which are surprisingly common - I found at least 20 of them just in the "boilerplate" data, by amounts ranging from 1 bit to 12 bits and in both directions.  But these seem to occur only after high-error regions, which may have damaged the framing information that was used in decoding the signal.  They affect entire "sub-blocks" and garbage bits are shifted in at one end.)

Then (hopefully) by correlating the raw.ts with the  raw_final_fixed.ts I could derive bit positions in raw_final_fixed.ts for all of the "25-byte and 31-byte sub-blocks".  Then for a given frame, for each mmb I could see if the bit flipped was part of a "triple flip" and manually try flipping all three of the triple flip bits, to see if that improves the result.

In theory this could eventually be added to the online tool to make it easy to test "triple flips" at appropriate bit positions.  But baby steps first.

Have I understood the issues correctly?  Princess, could you get me a copy of your fixed .ts file?

(And if anyone really understands what ajmartin was talking about, I'd appreciate some more detail.  Are the triple flips aligned to specific positions in the subblock?  And when he says "combinations of triple flips" it is possible for the triple flips to overlap and flip certain bits "twice"?  I'm assuming I can figure this out by retracing his steps starting from princess' fixed .ts file.)

Offline ajmartin

  • Member
  • Posts: 4
  • Liked: 25
  • Likes Given: 179
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1442 on: 06/07/2014 02:17 am »
I suspect the ship has already sailed and no-ones eager to go back to raw.ts.  But I bet it *would* be helpful if someone would compile a list of the adjusted start/end positions of the FEC coding blocks referenced to the current .ts and including the discovered bit shifts, etc, like princess did:

That's a good idea.  It's actually a bit easier than that, because the frame-shift errors do not change the coding-block boundaries.  (Bits are not shifted from one block to another, instead "garbage" bits from the framing of each block are shifted into the block - I have confirmed this by observation in the "boilerplate" regions.  Even if the shift were corrected in raw_final_fixed.ts, there would be no need to move the block boundaries, as the only difference it would make is to change which end of the blocks has the "garbage" bits.)

I did the mapping, and for frames 1-254 the 25-byte blocks start at offsets of the form 56n + 13 (zero-based) and the 31-byte blocks start at offsets 56n + 38 in raw_final_fixed.ts.  For frames 255-284, the 25-byte blocks start at offsets 56n + 5 and the 31-byte blocks start at offsets 56n + 30.  (The reason for the discontinuity was explained by Shanuson here.)

As for the issue of fixes to TS headers interfering with finding "triple flips", the simplest thing to do is to treat the coding blocks as if they did not include the TS headers, splitting them in two as needed.  (That is, do not look for triple flips that overlap TS-headers, but instead look for single bit-flips in the 15 bits on either side of them.)  This loses a bit of "free" information about the errors provided by the damaged TS-headers, but it allows the structure of the errors to be used without referring back to raw.ts.

Offline cscott

  • Senior Member
  • *****
  • Posts: 3471
  • Liked: 2867
  • Likes Given: 726
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1443 on: 06/07/2014 02:30 am »
I suspect the ship has already sailed and no-ones eager to go back to raw.ts.  But I bet it *would* be helpful if someone would compile a list of the adjusted start/end positions of the FEC coding blocks referenced to the current .ts and including the discovered bit shifts, etc, like princess did:

That's a good idea.  It's actually a bit easier than that, because the frame-shift errors do not change the coding-block boundaries.

OK.  I'm still coming to speed here, bear with me.  Could you give me an example of a triple flip -- maybe the first one in the transport stream, just to pick one arbitrarily.  It would help me a bunch if you could give me a short hex dump of a sequence in raw.ts, then the equivalent sequence in the fixed .ts showing the triple flip.  If you gave me the offsets of the various features, as you label them, it would also sanity-check my understanding of how offsets are counted, etc.

Offline Tea Party Space Czar

  • President, Tea Party in Space
  • Full Member
  • ***
  • Posts: 382
  • TEA Party in Space Czar
  • Washington DC
  • Liked: 294
  • Likes Given: 284
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1444 on: 06/07/2014 04:56 am »
This just popped up in my Facebook feed.  You guys kick ass.  The post was sponsored by SpaceX.

Good Work.

Respectfully,
Andrew Gasser

Offline ajmartin

  • Member
  • Posts: 4
  • Liked: 25
  • Likes Given: 179
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1445 on: 06/07/2014 04:57 am »
OK.  I'm still coming to speed here, bear with me.  Could you give me an example of a triple flip -- maybe the first one in the transport stream, just to pick one arbitrarily.  It would help me a bunch if you could give me a short hex dump of a sequence in raw.ts, then the equivalent sequence in the fixed .ts showing the triple flip.  If you gave me the offsets of the various features, as you label them, it would also sanity-check my understanding of how offsets are counted, etc.

Sorry, I should have given examples earlier.  The easiest way to see "triple flips" is to look at a hex dump of damaged null packets in raw.ts.  That way there is no need to cross-reference with the fixed .ts, since we know all the bytes should be ff.  For instance:

00001ac0  ff ff ff ff ff ff 7f fc  ff ff ff ff ff ff ff ff  |................|

Here we are looking at 16 bytes at offset 0x1ac0 = 6848.  This is in the middle of a null packet, and we see two incorrect bytes.  At the bit level:

Transmitted: 11111111 11111111
Received:    01111111 11111100
Flips:       *              **
XOR:         10000000 00000011


That's a "triple flip".  The pattern of bit-flips can be represented as a binary number, by XORing the transmitted and received values.  Written more compactly in hex, it is 0x8003.

The relative positions of the three flipped bits are always the same, but the pattern need not be byte-aligned.  Here's another example:

00001980  ff ff ff fe ff f9 ff ff  ff ff ff ff ff ff ff ff  |................|

At the bit level, we see the same pattern of three flips:

Transmitted: 11111111 11111111 11111111
Received:    11111110 11111111 11111001
Flips:              *               **
XOR:         00000001 00000000 00000110


The error pattern in hex is 0x10006; which is just 0x8003 shifted left by 1 bit.  (The other two shifts that look different in hex are 0x2000c and 0x40018.)  Moving on to a more complicated case:

00001a60  ff ff ff ff ff fc ff f5  ff ff ff ff ff ff ff ff  |................|

Transmitted:          11111111 11111111 11111111
Received:             11111100 11111111 11111010
Error pattern (XOR):  00000011 00000000 00000101


At first glance this is a "quadruple flip".  But it can be written as a combination (XOR) of two triple flips:

    Triple Flip 1: 00000010 00000000 00000110
XOR Triple Flip 2: 00000001 00000000 00000011
 =  Error Pattern: 00000011 00000000 00000101


As you suspected, a bit can be "flipped twice" and end up unchanged; one such bit is highlighted in red.  (In binary linear coding, two wrongs make a right!)

Then there are the errors that are not triple flips.  Here's one:

00001a20  ff ff ff ff ff|3f ff ff  ff ff ff ff ff ff ff ff  |.....?..........|

That's where the coding blocks come in.  This line starts at offset 0x1a20 = 6688, and the 3f is at offset 6693; dividing by 56, we get a quotient of 119 and a remainder of 29.  So it is the first byte of a 25-byte block, whose boundary is marked in blue, and we expect single flips rather than triple flips there.

(I had a hypothesis that these cases were actually "truncated triple flips", with some of the flipped bits affecting the framing of the coding block, and being removed during decoding.  But there were too many places where that did not fit the data - although it does fit this example.)

These patterns still apply where the data isn't all ff's.  Here's an example from the headers of an I-frame (number 241) showing five triple flips:

Received:  00 30 81 20 07 21 01 b1 76 bd ff fe 50 07 e1 b0
Flip1:        20 00 c0
After:     00 10 81 e0 07 21 01 b1 76 bd ff fe 50 07 e1 b0
Flip2:        10 00 60
After:     00 00 81 80 07 21 01 b1 76 bd ff fe 50 07 e1 b0
Flip3:                                      01 00 06
After:     00 00 81 80 07 21 01 b1 76 bd ff ff 50 01 e1 b0
Flip4:                                         40 01 80
After:     00 00 81 80 07 21 01 b1 76 bd ff ff 10 00 61 b0
Flip5:                                         10 00 60
Corrected: 00 00 81 80 07 21 01 b1 76 bd ff ff 00 00 01 b0

 
You can find this last example at offset 3840068 (0x3a9844) of raw.ts and offset 3585364 (0x36b554) of raw_final_fixed.ts.  (It has been corrected there but not quite fully.)

I hope this helps to make things less mysterious.  I have lots of other examples, if there's something specific that you would like to see.

(edit: typo fixes)
« Last Edit: 06/07/2014 05:11 am by ajmartin »

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1446 on: 06/07/2014 07:28 am »
Princess, could you get me a copy of your fixed .ts file?

Sure, here's my best effort so far. This is a fixed version of faw_final_fixed.ts so it doesn't correspond bit-for-bit to raw.ts. The problem is that raw.ts loses its alignment from time to time and has to be realigned by removing 56 bytes each time (this may be significant).

My best guess at the realignments are:

Remove 56 bytes after packet 1224,
and then remove 56 bytes after packet 4688,
and then remove 56 bytes after packet 11637,
and then remove 56 bytes after packet 18633,
and then remove 56 bytes after packet 21551.

Re-generate the file after each single removal for the next packet number to make sense. Each packet is 188 bytes long. Please note that these positions may not be exactly correct but it will give you the places to look for the right ones.

Once you've done this you need to remove everything before the start of the first I-frame, because the raw_final_fixed files start there.

I'm busy with other things today but I'll be back in about 12 hours to help out.
« Last Edit: 06/07/2014 07:29 am by princess »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1447 on: 06/07/2014 07:35 am »
Hi guys,

I'm experimenting with making a "repair video" of sorts. Just for fun and a little bit for education 8)

Here is a very simple gif that shows the repairing of iframe 3 "in progress"...

Be careful: since its a gif it's big!

Regards,

arnezami

PS. Maybe its cooler/nicer to first show the positioning, and then show the luma/chroma fixes. Now I show them both at the same time. What do you think? And maybe showing the repairing of all iframes in sequence in a video. Maybe even include all P-frames... That could be cool too. :)

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1448 on: 06/07/2014 08:10 am »
Here is a very simple gif that shows the repairing of iframe 3 "in progress"...

The concept is very cool and educational, but this version looks like you've taken the final mmb and just apply commands as they come in the sequence. Not quite representative of the actual process. I have saved most of my intermediate mmbs for the frames I worked with. For example for iframe 121 it should show the initial good data search and later alignment. Then there was dc correction done by Quialiss and then final touches by SwissCheese.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1449 on: 06/07/2014 08:26 am »
Here is a very simple gif that shows the repairing of iframe 3 "in progress"...

The concept is very cool and educational, but this version looks like you've taken the final mmb and just apply commands as they come in the sequence. Not quite representative of the actual process. I have saved most of my intermediate mmbs for the frames I worked with. For example for iframe 121 it should show the initial good data search and later alignment. Then there was dc correction done by Quialiss and then final touches by SwissCheese.
Correct. This version is adding a mmb-command each time (sometimes two each time: a -1 command and a new position).

So it's not a "chronological progress" of what we did. It's more to demonstrate that there are many small adjustments to a single frame in order to fix it. So "progress" is probably not the right word for this. It's more like: showing incremental fixes to the frame up to (full) restoration. Above all it visually demonstrates how correcting MPEG-4 works.

I think a chronological progress can best be shown by releasing multiple videos from certain dates.
« Last Edit: 06/07/2014 08:29 am by arnezami »

Offline Shanuson

  • Full Member
  • ***
  • Posts: 395
  • Liked: 327
  • Likes Given: 2542
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1450 on: 06/07/2014 08:56 am »
Princess, could you get me a copy of your fixed .ts file?

Sure, here's my best effort so far. This is a fixed version of faw_final_fixed.ts so it doesn't correspond bit-for-bit to raw.ts. The problem is that raw.ts loses its alignment from time to time and has to be realigned by removing 56 bytes each time (this may be significant).

My best guess at the realignments are:

Remove 56 bytes after packet 1224,
and then remove 56 bytes after packet 4688,
and then remove 56 bytes after packet 11637,
and then remove 56 bytes after packet 18633,
and then remove 56 bytes after packet 21551.

Re-generate the file after each single removal for the next packet number to make sense. Each packet is 188 bytes long. Please note that these positions may not be exactly correct but it will give you the places to look for the right ones.

Once you've done this you need to remove everything before the start of the first I-frame, because the raw_final_fixed files start there.

I'm busy with other things today but I'll be back in about 12 hours to help out.

Actually when i realigned raw.ts to get to the editX,ts files from which the final.ts file was produced, I added bytes but i think I never removed some. At least never when there was could have been some lost data.
To bad I was to lazy to write down what I really did.

Cheers
Shanuson

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1451 on: 06/07/2014 09:38 am »
I made a gif from the mmbs I saved while working on frame 121. I hope it's a bit more illuminating of the process as it happened. Unfortunately I don't have intermediate mmbs for the geat work done by Quialiss and SwissCheese so this is only represented by the last frame. Maybe they have these steps, or they can be recreated.

Edit: And I don't know why it's not animating. It works fine when I open it locally :(
« Last Edit: 06/07/2014 10:10 am by saliva_sweet »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1452 on: 06/07/2014 10:16 am »
Edit: And I don't know why it's not animating. It works fine when I open it locally :(
Maybe zip it and then upload. It seems the forum is doing something with the gif.

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1453 on: 06/07/2014 10:26 am »
Apparently the Wikispaces API doesn't allow file uploads.  >:(

The auto-generated MMBs are uploaded here, in case you need to track down a bug:

http://adama.nocdirect.com/~wronkiew/spx_crs3/mmbs/

IainCole, can you change the youtube uploader to grab http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_clockfix_3hr.mp4 ? I can then move the trigger to the 3hr script.

Parts 3 and 4 are auto-generated correctly, but I think the video is still using the old fix8 files for those two parts, part 4 is currently cleaner than what's in the video.

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1454 on: 06/07/2014 10:34 am »
Maybe zip it and then upload. It seems the forum is doing something with the gif.

Here's the zip.

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1455 on: 06/07/2014 10:42 am »
PS. Maybe its cooler/nicer to first show the positioning, and then show the luma/chroma fixes. Now I show them both at the same time. What do you think? And maybe showing the repairing of all iframes in sequence in a video. Maybe even include all P-frames... That could be cool too. :)

I think you could do this approximately by separating out all mmb's that contain DC information.. that are not after a -1 or -2 block?  Just trying to think of search terms that could work.  Then you'd have a 'base' and an 'additional modifications' file.  If you wanted to go further you could take the base and remove the DC information from them, apply the raw positioning data first, and then the DC corrections on the positioning, and then apply the additional modifications.... or, thinking along those lines...

A simpler solution may be to strip all the DC information from the MMB, apply that one step at a time, which should give all the positioning(with a bunch of redundant steps.. hrrm), and then add back the DC information a step at a time. 


Reconstructing the reconstruction.  :D  I can help out with making said split MMBs if needed, but I don't have the setup to make the actual images. 

Offline deruch

  • Senior Member
  • *****
  • Posts: 2422
  • California
  • Liked: 2006
  • Likes Given: 5634
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1456 on: 06/07/2014 10:56 am »
Maybe zip it and then upload. It seems the forum is doing something with the gif.

Here's the zip.

Wow that's great!  If you change this in the future can you add some frames to the end?  Ideally, repeats of the last frame, so that you get a chance to really see the end product would be awesome.
Shouldn't reality posts be in "Advanced concepts"?  --Nomadd

Offline Jakusb

  • Full Member
  • ****
  • Posts: 1207
  • NL
  • Liked: 1215
  • Likes Given: 637
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1457 on: 06/07/2014 11:39 am »

Pretty good list. :)

I personally like to see Jakusb (the "dirt-master") on the list too. Because he gave us the list of dirt spots on the camera which allowed others to align blocks in the top part of the frames. But considering having only 15 spots its a good list.

Haha, the dirt-master. Love it!
Thanks a lot for the appreciation!
However I am sure plenty of others have made much bigger contributions. That is the trouble with a list like this in a group effort like ours. There will always be people that should be on the list, but somehow are forgotten or not properly acknowledged.

I am just happy and very proud to be (a tiny) part of this amazing group effort on the best space forum that I know of. :)
Although I would never refuse a SpaceX t-shirt if I ever got offered one. ;) I would wear it proudly. :)

Keep up the good work everyone! Maybe some more detail on the end frames? I would love to see the stage really topple over as many suggest to see in the few frame parts sofar.

Offline mhenderson

  • Member
  • Posts: 71
  • USA
  • Liked: 101
  • Likes Given: 18
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1458 on: 06/07/2014 12:12 pm »
Since 281 is the final iFrame and is currently washed out, it would be best to enhance the contrast so the video ends on a nicer image.

I see the online editor now has a "suggest improvement to MMB" button.  I like that a lot, submissions should be controlled and referreed by a benevolent dictator.

This is a step in the right direction, but I know my limits ... perhaps someone more skilled at this can take it over the finish line.

Frame 15(281)
X:3545:01,X:2003:A0,0:0:559,40:1:-1,0:2:-2:25:25:25:25:0:0,0:10:-2:60:60:60:60:0:0:40,
1:10:53276,32:10:-1::40,33:10:57352,0:13:69419:0:0:0:1:0:0:63,
28:15:-2:-70:-70:-70:-70:0:0:63,29:15:83102,8:29:-1

This change was entered in the wiki page and the spreadsheet yesterday, but does not appear in the YouTube channel. Am I missing a step?

Offline CraigLieb

  • Full Member
  • ****
  • Posts: 1193
  • Dallas Fort Worth
  • Liked: 1349
  • Likes Given: 2394
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1459 on: 06/07/2014 12:23 pm »
We need more T-shirts!!  ;D

Clearly the solution is to cut the t-shirts in half.
I suggest taking all the tshirts, running them through a shredder, and putting all the scraps in
A box in a public park. Give The 15 people on the list the address.   ;D
On the ground floor of the National Space Foundation... Colonize Mars!

Tags:
 

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