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

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1520 on: 06/10/2014 07:10 AM »
The clockfix script now tracks changes, so the YouTubifier will be notified when landing_clockfix_3hr.mp4 is updated, whether by mmb or by clock. We currently have 73 frames of clock fixes.

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1521 on: 06/10/2014 07:22 AM »
Sorry, there was a message between 1520 and 1521 that I deleted before I saw mhenderson's response.

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1522 on: 06/10/2014 07:31 AM »
Is it valid to cut / paste data from adjacent frames to allow the codec to continue?

IMHO, absolutely yes. That is a necessary part of the restoration. Let the brave little booster sing.

Yes, I agree. For raw_final_fixed.ts we were making the file to attempt a visual recovery of the video, so getting the right number of frames is important, meaning that copy/paste of frame starts is fine.

For rocket.ts the aim is slightly different in that we're attempting to recover the raw bitstream, not the video - this means that copy/paste like that is absolutely not allowed, which is why it took me so long to get the files created and posted up here. Hopefully now people can start working on error analysis which should have some interesting results!

My best guess at what will happen is this: the TS file seems to have areas where the corruption is light, and then burst corruption that mangles a couple of packets completely. In the light corruption areas, triple bitflips seem to dominate. So we can use the error analysis firstly to determine which areas of the file have "light" corruption, and then we can search in those areas for triple bitflips that restore more data.

We'll end up with a TS file that has heavy burst errors, but in between these bursts the file will be pretty much bit-perfect and the video data from those regions should be totally smooth. If we're lucky to hit an I-frame with the triple bitflips then the whole of the P-frame sequence will look a lot better too.

Offline Shanuson

  • Full Member
  • **
  • Posts: 292
  • Liked: 197
  • Likes Given: 595
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1523 on: 06/10/2014 07:55 AM »
IIRC, SwissCheese and I worked on those frames.. from our notes on the wiki, 269 and 270 were completely unrecoverable in fix8 version, and some data became recoverable in the raw_final_fixed.ts, though they're still missing large chunks of data.  But they don't appear to pause(outside of what's caused by missing a third of a frame) and the timestamps all look correctly recovered.

The TS timestamps for 270 were altered to make the frame look correct, but I don't know what happened with the MPEG4 stream.

Basically at that point in the data the stream was all fine with no errors, and then suddenly from around offset 0x003dbb04 to offset 0x003dd284 there was a huge burst of corruption that knocked out 32 TS packets. If you look at it with a TS analyser it's very bad, just totally mangled.

Anyway, the boundary between 269 and 270 occurred in the middle of this. Usually the corruption is light enough that you can kind of eyeball the closest packet, or break out the Hamming-distance analysis, but in this case it's useless. Whoever did the byte duplicate in raw_final_fixed.ts was basically just pasting the start of 271 into this and resetting the timestamp to be correct. It's the TS equivalent of saying "this macroblock is shot to pieces, use one that looks similar".

So yes, this will allow extra data to be recovered - the good macroblocks in 270 after the corruption burst finished. But be aware that the end of 269 and the start of 270 are mangled beyond recovery.

I think i wrote what I did when i published raw_final_fixed.ts. The problem was not only that one could not identify the exact Ts-Packet where the new frame started, it was also one of these 56 byte missing parts in there too. My best idea to "repair" this was to duplicate the whole part, and cut away some packets at the end of the first duplicate to make the CC continuous, and change the P-frame header of the 2nd duplicate to the one of the second frame. In that way the first frame has data from the 2nd at the end that should be pushed out by MMBs and the 2nd frame has the right data at the end but one has to find where its good data really starts. So one has to work from the end backwards when mmb-ing it.
But it should be frames 254 and 255 where this happened.

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1524 on: 06/10/2014 08:22 AM »
But it should be frames 254 and 255 where this happened.

Ah yes, good point! When I was working out which frames it occurred in, I forgot that raw_final_fixed.ts hasn't got the first 15 P-frames before the I-frame. The corruption is in 269/270 in rocket.ts and 254/255 in raw_final_fixed.ts.

Thank you for the correction Shanuson!

Offline SwissCheese

  • Full Member
  • *
  • Posts: 165
  • Liked: 250
  • Likes Given: 94
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1525 on: 06/10/2014 10:25 AM »
But it should be frames 254 and 255 where this happened.

Ah yes, good point! When I was working out which frames it occurred in, I forgot that raw_final_fixed.ts hasn't got the first 15 P-frames before the I-frame. The corruption is in 269/270 in rocket.ts and 254/255 in raw_final_fixed.ts.

Thank you for the correction Shanuson!

Yep, frames 254 and 255 are the same, contain both the 2 p-frames, and are quite a big mess ;)

Offline SwissCheese

  • Full Member
  • *
  • Posts: 165
  • Liked: 250
  • Likes Given: 94
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1526 on: 06/10/2014 10:46 AM »
I had to correct a little bit i frame 121 to align it to the p-frames. The problem is that the colors are wrong now and I'm not good at correcting them... Could someone recover nicer colors?

The new mmb is in attachment, I haven't posted it to the wiki yet.

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 557
  • Liked: 431
  • Likes Given: 1357
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1527 on: 06/10/2014 11:16 AM »
I had to correct a little bit i frame 121 to align it to the p-frames. The problem is that the colors are wrong now and I'm not good at correcting them... Could someone recover nicer colors?

The new mmb is in attachment, I haven't posted it to the wiki yet.

If dcs need to be redone may I suggest including the changes I posted here:
http://forum.nasaspaceflight.com/index.php?topic=34597.msg1209819#msg1209819
It's a couple of xors to 0:0 macroblock (ajmartins triple flip) that I think restores it to the original, it might give a better foundation to the overall color of the frame and make it fit better into the sequence. but it looks like it breaks the dcs much more than Swisscheeses change so might not be worth the effort.

Offline Shanuson

  • Full Member
  • **
  • Posts: 292
  • Liked: 197
  • Likes Given: 595
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1528 on: 06/10/2014 11:37 AM »
But it should be frames 254 and 255 where this happened.

Ah yes, good point! When I was working out which frames it occurred in, I forgot that raw_final_fixed.ts hasn't got the first 15 P-frames before the I-frame. The corruption is in 269/270 in rocket.ts and 254/255 in raw_final_fixed.ts.

Thank you for the correction Shanuson!

Yep, frames 254 and 255 are the same, contain both the 2 p-frames, and are quite a big mess ;)

Yes to disentangle them will be really hard. Good luck with that ;) The best way would be to identify the part where the first timestamp is. if we know this the next frame should start in the next few ts-packets. Everything after this should then be part of the second frame.
« Last Edit: 06/10/2014 11:59 AM by Shanuson »

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1529 on: 06/10/2014 02:18 PM »
I had to correct a little bit i frame 121 to align it to the p-frames. The problem is that the colors are wrong now and I'm not good at correcting them... Could someone recover nicer colors?

The new mmb is in attachment, I haven't posted it to the wiki yet.

If dcs need to be redone may I suggest including the changes I posted here:
http://forum.nasaspaceflight.com/index.php?topic=34597.msg1209819#msg1209819
It's a couple of xors to 0:0 macroblock (ajmartins triple flip) that I think restores it to the original, it might give a better foundation to the overall color of the frame and make it fit better into the sequence. but it looks like it breaks the dcs much more than Swisscheeses change so might not be worth the effort.

Curiously, combined, the changes do less 'damage' to the frame than they do apart.  I'll see what I can whip up this afternoon. 

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1530 on: 06/10/2014 05:03 PM »
I've been playing with the error analysis a bit and I have a few mildly interesting new ways to visualise the bitflips.

The first is a file that is the XOR of raw_aligned.ts and rocket.ts - a 1 bit represents a bitflip, and a zero bit represents an uncorrupted bit. The game is to try to find if there's any predictability in the 1s. The file is attached to this message.

The second is that I've made a series of images representing the bitflips. Each pixel represents a bit, and each image line represents 56 bytes of the data file. A black pixel means there's no error, a red pixel means a transmission error set a bit to 1 when it should be 0, and a green pixel means a transmission error cleared a bit to 0 when it should be 1. I've attached the first few images directly here so you can see what it looks like, then I've also included a ZIP file with all of the images in.

Let's see if we can determine any patterns...

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 557
  • Liked: 431
  • Likes Given: 1357
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1531 on: 06/10/2014 05:23 PM »
I've been playing with the error analysis a bit and I have a few mildly interesting new ways to visualise the bitflips.
Most interesting. Do I understand correctly that the green areas are padding that should be xFFs and the diagonal lines of flips are TS packet headers (that you have data for)? Most of these regions look to be in absolutely abysmal condition (except maybe the last picture). Surely this can't be representative of the whole file. Or is it?

Edit: Also, would it be possible to make separate pics for every frame?
« Last Edit: 06/10/2014 05:32 PM by saliva_sweet »

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1532 on: 06/10/2014 06:44 PM »
I've been playing with the error analysis a bit and I have a few mildly interesting new ways to visualise the bitflips.

The first is a file that is the XOR of raw_aligned.ts and rocket.ts - a 1 bit represents a bitflip, and a zero bit represents an uncorrupted bit. The game is to try to find if there's any predictability in the 1s. The file is attached to this message.

The second is that I've made a series of images representing the bitflips. Each pixel represents a bit, and each image line represents 56 bytes of the data file. A black pixel means there's no error, a red pixel means a transmission error set a bit to 1 when it should be 0, and a green pixel means a transmission error cleared a bit to 0 when it should be 1. I've attached the first few images directly here so you can see what it looks like, then I've also included a ZIP file with all of the images in.

Let's see if we can determine any patterns...

Well, there's the one pattern that screams out, the periodic short runs of bitflips in otherwise okay data.  Strong peak at ~184 bits between these corrections, with 5 resonant peaks due to occasional gaps in the pattern. 

The length and content of those short corrections also probably has a pattern, which might be valuable for filling in those predictable gaps. 

Data's a csv, but the forum doesn't appreciate those.  txt it is. 

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1533 on: 06/10/2014 07:35 PM »
Most interesting. Do I understand correctly that the green areas are padding that should be xFFs and the diagonal lines of flips are TS packet headers (that you have data for)?

Yes that's right in both cases. You'll see the TS headers as a diagonal pattern as they occur every 188 bytes, whereas the picture is sized to be 56 bytes wide.

Most of these regions look to be in absolutely abysmal condition (except maybe the last picture). Surely this can't be representative of the whole file. Or is it?

The example pictures (except the last one) are from the start of the file, which is indeed in abysmal condition. I included the last picture to indicate a calmer area of the file. It's very informative to browse through all of the pics in the ZIP file, to see what a clean area looks like.

Edit: Also, would it be possible to make separate pics for every frame?

If you feel that would help I can do it, but the frame starts don't always align with 56-byte offsets. I could do pictures that are 188 bytes wide if you like?

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1534 on: 06/10/2014 07:38 PM »
Well, there's the one pattern that screams out, the periodic short runs of bitflips in otherwise okay data.  Strong peak at ~184 bits between these corrections, with 5 resonant peaks due to occasional gaps in the pattern. 

My guess is that you're using a byte offset and not a bit offset, and these are the TS packets at 188 bytes long. Most of the TS file is MPEG4 data packets - we can repair the headers of these packets but not the data, so you see a burst of errors representing the TS header bytes separated by 188 bytes. As we start applying MMBs to the data, you'll see pixels appearing in between these bursts.

If that truly is BIT error lengths and not bytes, then we have something to work on...
« Last Edit: 06/10/2014 07:40 PM by princess »

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 557
  • Liked: 431
  • Likes Given: 1357
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1535 on: 06/10/2014 07:54 PM »
Edit: Also, would it be possible to make separate pics for every frame?

If you feel that would help I can do it, but the frame starts don't always align with 56-byte offsets. I could do pictures that are 188 bytes wide if you like?
That's OK, I think a rough guide to tell which parts of frames are totally shot and not worth bothering with would be helpful. Although a bitposition scale at the left would be cool ;) It might be also informative to highlight somehow the subpackets (25 + 31 bytes) ajmartin identified (http://forum.nasaspaceflight.com/index.php?topic=34597.msg1209887#msg1209887) and the 15 bit single flip regions, perhaps with vertical lines through the image or a horizontal bar at the top.

But what we have so far is already wonderful. Superb work.

Edit: Maybe my wording wasn't super clear here. It's OK that 56 bype packets don't align perfectly with frames. No need to switch to 188 byte width. I think 56 bytes makes more sense in this context.
« Last Edit: 06/10/2014 07:58 PM by saliva_sweet »

Offline cscott

  • Senior Member
  • *****
  • Posts: 2949
  • Liked: 2054
  • Likes Given: 664
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1536 on: 06/10/2014 08:39 PM »
Edit: Also, would it be possible to make separate pics for every frame?

It would indeed be nice to see frame-by-frame pictures; that would guide those working on MMBs to give them a rough heads up of where the frame damage lies.

Also -- could I ask for a graph or other visualization of correlations between bit flips?  I'm thinking of a simple bar graph (or just a table) that says what's the probability of a flip at n+1, n+2, n+3, n+4, etc given the existence of a flip at n.  That would be a nice quantitative sanity-check on the "triple flip" pattern (which should leap out) as well as maybe see if the triple flip patterns are indeed consistent across all frames, or maybe are useful only in frames with "low corruption".

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1537 on: 06/10/2014 09:01 PM »
OK, here are the pictures resized so that they're 188 bytes wide, i.e. each line is 1 TS packet. I've included an example of a corrupted area and a clean area, the whole set of images are in the ZIP file.

The TS headers all line up down the left hand edge of the images, and you can see intriguing multiple bit flip patterns in the clearer areas. Can anyone see any more patterns?

Offline morningdew76

  • Member
  • Posts: 11
  • McLean, VA
  • Liked: 12
  • Likes Given: 7
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1538 on: 06/10/2014 09:29 PM »
princess, would it be possible to generate the 448px images with some guides in them?

I'm just looking for a visual marker to show the regions of single flips vs triple flips.

Here's an example that I worked up with mspaint that shows the first and last 15 bits with a blue line.. I didn't attempt to mark the inner region.  It is 450px wide, but would be 452px if it had the other two blue lines.

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1539 on: 06/10/2014 09:51 PM »
Well, there's the one pattern that screams out, the periodic short runs of bitflips in otherwise okay data.  Strong peak at ~184 bits between these corrections, with 5 resonant peaks due to occasional gaps in the pattern. 

My guess is that you're using a byte offset and not a bit offset, and these are the TS packets at 188 bytes long. Most of the TS file is MPEG4 data packets - we can repair the headers of these packets but not the data, so you see a burst of errors representing the TS header bytes separated by 188 bytes. As we start applying MMBs to the data, you'll see pixels appearing in between these bursts.

If that truly is BIT error lengths and not bytes, then we have something to work on...

Ack, you're right on the byte vs bit error.  Actually it was a silly mistake on my part in how I was processing the data, so it's not just bits swapped for bytes... but the general gist of what I said holds true and the corrected graph looks nearly identical except for the scale.

Now that I've fixed that...

Also -- could I ask for a graph or other visualization of correlations between bit flips?  I'm thinking of a simple bar graph (or just a table) that says what's the probability of a flip at n+1, n+2, n+3, n+4, etc given the existence of a flip at n.  That would be a nice quantitative sanity-check on the "triple flip" pattern (which should leap out) as well as maybe see if the triple flip patterns are indeed consistent across all frames, or maybe are useful only in frames with "low corruption".

These are the percentages for the distance in bits between all the bitflips between princess's two files.  The big jump up at 13 good bits between errors is a strong indicator that these are triple flips in otherwise good data, the jump at 12 could be a triple flip overlapping another flip. 

It does look like we should be trying more consecutive flips.  As to how many in a row there should be, I'll have to try some heavier pattern analysis, as this is only looking at the pattern error--some optional length of good data--error.

0 41.88
1 19.61
2 9.79
3 5.59
4 3.57
5 2.56
6 1.9
7 1.5
8 1.23
9 1.04
10 0.95
11 0.96
12 1.39
13 2.34
14 0.28
15 0.19
16 0.15
17 0.13
18 0.12
19 0.12
20 0.11
« Last Edit: 06/10/2014 09:52 PM by Quialiss »

Tags: