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

Offline CraigLieb

  • Full Member
  • ****
  • Posts: 790
  • Dallas Fort Worth
  • Liked: 696
  • Likes Given: 799
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1460 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
Colonize Mars!

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 #1461 on: 06/07/2014 01:58 PM »
Enhancing the contrast in P-frames with X:59:C0 / X:59:80 / X:59:60 / X:59:40 works great.

Is there a way to do this for the I-frames too?

Offline cscott

  • Senior Member
  • *****
  • Posts: 2638
  • Liked: 1843
  • Likes Given: 658
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1462 on: 06/07/2014 01:58 PM »
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 working theory is that these 56 byte chunks are part of the telemetry stream, and that packet corruption means they weren't filtered out properly.

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.

Well, another equally-plausible theory is that 56-byte chunks of "real data" were removed because they were mistakenly thought to be part of the telemetry stream. ;)

I guess a close examination of these regions might be able to distinguish the two theories -- do there seem to be macroblocks missing?

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 508
  • Liked: 380
  • Likes Given: 1252
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1463 on: 06/07/2014 05:01 PM »
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.

Made a new gif that I think more accurately represents the evolution of this frame from total garbage to what we have now. I split the dc corrections into luma and chroma passes and applied them sequentially (I think this is Qualiss's method). Jumped over a lot of minute changes to reduce the size (it's still large) and some important changes (mostly in aligment) due to lack of data. Quialiss and Swisscheese, would you consider this a faithful representation of what you saw while working on this frame? I'm fairly happy with my part. Also, I extended the showing time of the final result.

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1464 on: 06/07/2014 05:44 PM »
Made a new gif that I think more accurately represents the evolution of this frame from total garbage to what we have now. I split the dc corrections into luma and chroma passes and applied them sequentially (I think this is Qualiss's method). Jumped over a lot of minute changes to reduce the size (it's still large) and some important changes (mostly in aligment) due to lack of data. Quialiss and Swisscheese, would you consider this a faithful representation of what you saw while working on this frame? I'm fairly happy with my part. Also, I extended the showing time of the final result.

Correct on my method, though there are always tweaks that aren't strictly sequential.  It's pretty close to what actually happened.  It does look like you've put some of the luma changes at the end, starting at frame 113 in the animation.  I'm guessing that these are blocks that have both luma and chroma changes?  I'd put the 'hybrid' DC adjustments in with the rest of the luma pass so they fit in.  I'd fix chroma issues whenever they were making it hard to see if I had luma right, so a few chroma changes before the final pass isn't inaccurate. 

SwissCheese may have an intermediary MMB for some data on the alignment.  I realigned the one leg tip and found a bit more data in the bottom, the work on the ocean was not mine. 


..And it case it hasn't been said enough:  WOW. 

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 116
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1465 on: 06/07/2014 05:50 PM »
Alternatively you can just grab the CSV from https://docs.google.com/spreadsheets/d/1xEtLQy3tvjv3cyz_wMQssuSFwHYVbMQ5-FdSz-uCsKA/export?gid=0&format=csv - this CSV is being autopublished by Google with something like 10 minute delay of the actual edit of the any of the parts' spreadseets.

I can take another stab at pulling the data from the spreadsheets, probably tomorrow.

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 116
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1466 on: 06/07/2014 05:52 PM »
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.

It is using sh_rawsplit_part_03_fixed_.ts and sh_rawsplit_part_04_fixed_.ts. I'm pretty sure that is the most recent segmented ts file. Does anyone know of a newer version?

Offline SwissCheese

  • Full Member
  • *
  • Posts: 164
  • Liked: 249
  • Likes Given: 80
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1467 on: 06/07/2014 06:18 PM »
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.

Made a new gif that I think more accurately represents the evolution of this frame from total garbage to what we have now. I split the dc corrections into luma and chroma passes and applied them sequentially (I think this is Qualiss's method). Jumped over a lot of minute changes to reduce the size (it's still large) and some important changes (mostly in aligment) due to lack of data. Quialiss and Swisscheese, would you consider this a faithful representation of what you saw while working on this frame? I'm fairly happy with my part. Also, I extended the showing time of the final result.

For me it shows nicely the reconstruction process, even if it was probably more chaotic in reality ;)

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 508
  • Liked: 380
  • Likes Given: 1252
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1468 on: 06/07/2014 06:35 PM »
Correct on my method, though there are always tweaks that aren't strictly sequential.  It's pretty close to what actually happened.  It does look like you've put some of the luma changes at the end, starting at frame 113 in the animation.  I'm guessing that these are blocks that have both luma and chroma changes?  I'd put the 'hybrid' DC adjustments in with the rest of the luma pass so they fit in.  I'd fix chroma issues whenever they were making it hard to see if I had luma right, so a few chroma changes before the final pass isn't inaccurate. 
It's probably not due to blocks with both changes. More likely the dc inherit direction command is confusing my algorithm (the mmb is way too big to parse manually at this point). This mysterious (for me) command appears to be used on some occasions, at least some mmb commands contain 10 fields. I didn't know what to do with them so I mostly ignored their presence. When I saw my result was close to your style based on what you've shown of your work I was pretty happy.

The original result containing all mmb changes was 315 frames this is without counting the changes made by Swisscheese, I left out the tiny changes to leave 129 frames. I think this illustrates the magnitude of the work done, because (at least for me) each change was a result of lots of deliberation, trial and error and scanning through hundreds of bitpositions. But I was smiling every time I got a few macroblocks out so It was all worth it. And that's just one frame out of the 300 odd frames that we got to work with.
« Last Edit: 06/07/2014 06:39 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 #1469 on: 06/07/2014 07:20 PM »
Correct on my method, though there are always tweaks that aren't strictly sequential.  It's pretty close to what actually happened.  It does look like you've put some of the luma changes at the end, starting at frame 113 in the animation.  I'm guessing that these are blocks that have both luma and chroma changes?  I'd put the 'hybrid' DC adjustments in with the rest of the luma pass so they fit in.  I'd fix chroma issues whenever they were making it hard to see if I had luma right, so a few chroma changes before the final pass isn't inaccurate. 
It's probably not due to blocks with both changes. More likely the dc inherit direction command is confusing my algorithm (the mmb is way too big to parse manually at this point). This mysterious (for me) command appears to be used on some occasions, at least some mmb commands contain 10 fields. I didn't know what to do with them so I mostly ignored their presence. When I saw my result was close to your style based on what you've shown of your work I was pretty happy.

The original result containing all mmb changes was 315 frames this is without incorporating the changes made by Swisscheese, I left out the tiny changes to leave 129 frames. I think this illustrates the magnitude of the work done, because (at least for me) each change was a result of lots of deliberation, trial and error and scanning through hundreds of bitpositions. But I was smiling every time I got a few macroblocks out so It was all worth it. And that's just one frame out of the 300 odd frames that we got to work with.

Ah, that makes sense. You can treat the 10 field commands that have direction to be part of the luma correction part and order them accordingly if you end up doing another pass.  Not a big concern, it's a tiny fraction of the frames, I normally just use it around gaps in the data. 

I agree about it being a wonderful illustration of how much work went into each frame.  It's incredible to watch the i frame come together from the jumbled mess of data... and for me puts into context why so many luma fixes were required.  I remember thinking when I started trying to fix up the luma issues that I must be introducing new errors with not bit-perfect corrections* that I had to correct later in the frame, but when you lay out all the work required to get the macroblock structure correct, having so many errors in the subblocks starts seeming a little more reasonable.


*Still likely, but I believe that there should statistically be as many errors resulting in 1 or 2 off errors as there are 4 and 8 off errors, bitflips being impartial about where in the subblock they're located, and I can't visually see the 1-2 errors, so they're bound to build up at least as much as my mistakes.  So I tell myself.    ;)

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1470 on: 06/07/2014 10:06 PM »
I'm going to have a very busy week starting Sunday and won't be able to work on this as much as I'd like to, so I figure I'd leave my notes here to give people ideas on what could still use some love still.  :) 

I've also got a work in progress MMB for part 3 that I'm attaching that has a few alignment fixes from the version currently on the wiki, and increased contrast on all the p frames to help in alignment. 



Notes!



Part 3 and 4 need to be double checked for alignment issues
Part 5  83-88 not done yet

faulty luma/chroma in p frames
46, 47, 49, 52, 55, 56, 59 (needs alignment checks first)
65, 71, 72 (needs alignment checks first)
95, 96
104, 108
139
163, 167, 173, 175, 176
186, 192, 194
224

Verify alignment around these points
Two waves doing sharp turns at the start of a new p frame set at 102 and 122. top left, and between legs.

201 - Rocket body at the bottom of the frame is too light in the i frame given all the p frames that agree on the luma?
241 - this i frame could still use some attention
281 - this i frame could still use some attention

Match i frames in luma/chroma -- the rocket frequently changes colour between i frames.  Match to frames 10-11-12. 

Offline arnezami

  • Full Member
  • **
  • Posts: 282
  • Liked: 262
  • Likes Given: 341
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1471 on: 06/08/2014 04:40 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.
When looking at the latest videos there seems to be something wrong with the automated video creation.

For example. The frames 42-60 have been repaired lately. But they don't show up in the video. However I do see the mmb's in wronkiew's link to the mmbs.

Also frame 281 has been improved lately but the old one still show up in the video, but it does show up in wronkiew's link to the mmbs. I haven't checked further. But there is clearly something not working quite right.

I also don't understand this: the video does sometimes get updated now and then, yet it somehow still uses old mmb's. How can it use older AND newer mmbs? Does it keep it's own database of previous mmb's or something? I don't understand.

Regards,

arnezami

Offline PaulNY

  • Member
  • Posts: 3
  • NY
  • Liked: 1
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1472 on: 06/08/2014 05:13 AM »
Not 100% sure I did this right but I may of found 2 bit flips in I frame 7 (121) in the P frame editor.

X:583:01,X:5386:01

They seam to clear up the top row quite well and replace 4 MB edits. There does appear to still be errors in the top row though, less then the original frame but more then the current fix.
« Last Edit: 06/08/2014 05:15 AM by PaulNY »

Offline mhenderson

  • Member
  • Posts: 69
  • USA
  • Liked: 101
  • Likes Given: 18
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1473 on: 06/08/2014 08:00 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.
When looking at the latest videos there seems to be something wrong with the automated video creation.

For example. The frames 42-60 have been repaired lately. But they don't show up in the video. However I do see the mmb's in wronkiew's link to the mmbs.

Also frame 281 has been improved lately but the old one still show up in the video, but it does show up in wronkiew's link to the mmbs. I haven't checked further. But there is clearly something not working quite right.

I also don't understand this: the video does sometimes get updated now and then, yet it somehow still uses old mmb's. How can it use older AND newer mmbs? Does it keep it's own database of previous mmb's or something? I don't understand.

Regards,

arnezami

I concur.

The latest changes are not in the .mp4 video that IainCole's process is picking up (at http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_clockfix_3hr.mp4).

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 #1474 on: 06/08/2014 02:20 PM »
Enhancing the contrast in P-frames with X:59:C0 / X:59:80 / X:59:60 / X:59:40 works great.

Is there a way to do this for the I-frames too?

It looks like this works for I-frames with X:545:C0 / X:545:80 / X:545:60 / X:545:40

Offline cscott

  • Senior Member
  • *****
  • Posts: 2638
  • Liked: 1843
  • Likes Given: 658
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1475 on: 06/08/2014 03:40 PM »
*Still likely, but I believe that there should statistically be as many errors resulting in 1 or 2 off errors as there are 4 and 8 off errors, bitflips being impartial about where in the subblock they're located, and I can't visually see the 1-2 errors, so they're bound to build up at least as much as my mistakes.  So I tell myself.    ;)

This is what I'm hoping the "triple bit flip" investigation helps with: it might allow us to insert "invisible but correct" lsb flips based on how the obvious msb flips fit into the triple flip pattern.

Offline Klawd

  • Member
  • Posts: 2
  • Milan, Italy
  • Liked: 0
  • Likes Given: 6
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1476 on: 06/08/2014 06:32 PM »
Made a new gif that I think more accurately represents the evolution of this frame from total garbage to what we have now. ...

The patience you guys must have is enviable.

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 116
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1477 on: 06/08/2014 07:47 PM »
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.
When looking at the latest videos there seems to be something wrong with the automated video creation.

For example. The frames 42-60 have been repaired lately. But they don't show up in the video. However I do see the mmb's in wronkiew's link to the mmbs.

Also frame 281 has been improved lately but the old one still show up in the video, but it does show up in wronkiew's link to the mmbs. I haven't checked further. But there is clearly something not working quite right.

I also don't understand this: the video does sometimes get updated now and then, yet it somehow still uses old mmb's. How can it use older AND newer mmbs? Does it keep it's own database of previous mmb's or something? I don't understand.

Frame 42 had some creative formatting that was confusing the scraper. I improved the scraper and it is fixed now.

The generated mmbs always match the video here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

landing_clockfix_3hr.mp4 is updated on a different schedule from the previously generated files.

I do not see any problems with frame 281, and it is being scraped correctly.

Offline arnezami

  • Full Member
  • **
  • Posts: 282
  • Liked: 262
  • Likes Given: 341
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1478 on: 06/08/2014 08:17 PM »
Frame 42 had some creative formatting that was confusing the scraper. I improved the scraper and it is fixed now.

The generated mmbs always match the video here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

landing_clockfix_3hr.mp4 is updated on a different schedule from the previously generated files.

I do not see any problems with frame 281, and it is being scraped correctly.
Ok. Great! That video now seems to be correct and up-to-date.

I was looking at the youtube videos which are not in sync with your latest video. I thought they were somehow synced.

Should we change the link/widget on the wiki page?

Frame 42 had some creative formatting that was confusing the scraper. I improved the scraper and it is fixed now.

The generated mmbs always match the video here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

landing_clockfix_3hr.mp4 is updated on a different schedule from the previously generated files.

I do not see any problems with frame 281, and it is being scraped correctly.
Ok. Great! That video now seems to be correct and up-to-date.

I was looking at the youtube videos which are not in sync with your latest video. I thought they were somehow synced.

Should we change the link/widget on the wiki page?

The youtube videos are now on the 3hr schedule to prevent so much spam :)

Tags: