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

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
Ive added 2 features to https://github.com/michaelni/FFmpeg/tree/spacexdebug1
first, you can now use syntax like
-mmb 40:03:-1
to fill the image with "blank" blocks starting from 40:03 and until the next specified command
and
-mmb X:20009:1B
to xor 0x1B at bit position 20009 of the frame, that is this allows to flip some bits without the need to edit the file
(atm this is limited to max 8bit per command)

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
I feel like we're missing an important piece of this puzzle.

Was the video data stream was on it's own channel, or there was other data being transmitted on the same channel with some other controls in place to keep the data segregated?

If it was on it's own channel, having an analogue(time domain) copy of the original transmission, perhaps even with time code synced to the video file provided, there might be a lot more that could be done to extract the information.  Having the the time domain data stream it would also be much easier to tell where and when data was dropping out.

Someone was mentioning over on reddit they wish they had gotten an SDR (software defined radio) recording of the signal then we could dive into the signal processing layer to recover the signal.

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
Ive added 2 features to https://github.com/michaelni/FFmpeg/tree/spacexdebug1
first, you can now use syntax like
-mmb 40:03:-1
to fill the image with "blank" blocks starting from 40:03 and until the next specified command
and
-mmb X:20009:1B
to xor 0x1B at bit position 20009 of the frame, that is this allows to flip some bits without the need to edit the file
(atm this is limited to max 8bit per command)

Oh awesome that helps a lot. I was trying to edit things via a hexeditor but was making little progress because I couldn't find the alignments of the data.

Quick question. When you say "xor 0x1B at bit position" does that mean it takes the next 8 bits starting at 20009 and xor's them with the 0x1B value?
Edit: He said "yes."
« Last Edit: 05/06/2014 01:10 AM by mlindner »

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
Just a question: Is anybody collecting/monitoring the progress on this task? As several of you are working on parallel, I believe a monitoring tool would be useful in order to lower the risk of having several individuals doing the same thing. 

To start, may I suggest on keeping a table like the one originally describing the I-Frames (http://forum.nasaspaceflight.com/index.php?topic=34597.msg1193316#msg1193316) in order for everyone to know who is working on each one?

There is wiki at http://spacexlanding.wikispaces.com/ with current state of affairs.

Thanks for setting that up.

Just set up an IRC channel here on freenode for us. Use your favorite IRC client or use https://webchat.freenode.net/

Channel is #nsf-spacex-video
« Last Edit: 05/06/2014 01:24 AM by mlindner »

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
Ive added 2 features to https://github.com/michaelni/FFmpeg/tree/spacexdebug1
first, you can now use syntax like
-mmb 40:03:-1
to fill the image with "blank" blocks starting from 40:03 and until the next specified command
and
-mmb X:20009:1B
to xor 0x1B at bit position 20009 of the frame, that is this allows to flip some bits without the need to edit the file
(atm this is limited to max 8bit per command)

Added another feature, now you can adjust DC values of the blank blocks
each MB has 6 blocks 4 luma and 2 chroma
example to adjust the 4th luma DC of (blank) MB 40:3 by +100
-mmb 40:03:-1:0:0:0:100:0:0

Offline Adaptation

  • Full Member
  • *
  • Posts: 139
  • Liked: 34
Do you have something that's not for windows?

Also, a tool that could search by bits rather than hex would be even more helpful. Hardly anything in these video blocks appears to be byte aligned so hex searching doesn't help much.

Pretty sure mine would work in wine, if it dosent let me know and I can fix it.  Not certain about the other one. 

My tool does have a bit shift, with auto search selected you just press the bit shift button 7 times and it will make the result pop out at their respective offset. 

React OS in a vm is a good alternative should wine fail you.

Offline knotnic

  • Member
  • Posts: 49
  • Liked: 0
The video seems simple profile level 3 mpeg4 video in mpeg TS.
It seems none of the error resilience features of mpeg4 have been used when encoding it. Which is a pitty, had slices been used then the decoder could resume decoding of a frame at the next slice start, had data partitioning been used then the more important low resolution information and motion vectors would have been coded first in each slice making errors less likely to damage them. And had rvlcs been used then slices could have been decoded from both the start and end again, limiting the impact of bit errors.

I know nothing about how the video was generated or how it was transmitted, but if there was some FEC in there then then it should be possible in principle to re-run FEC decoding after manual fixing up all mpeg-TS and mpeg4-ES headers. And as such manual fixing would decrease the errors, FEC would then have fewer errors to deal with and might in a few rare cases be able to fix a few more errors.

Also if some kind of CRCs have been used, CRCs can also be used to correct bit errors as long as the number of errors is sufficiently small, which each CRC would need to correct, the exact number that could be corrected that way depends on the packet size and  crc polynomial being used.

My [outside the industry, and not a video expert either] guess is that the the reason they didn't enable them here is that the mpeg data has been extracted from a telemetry stream, and what we are seeing is after their own decryption/forward error correction/CRC was performed.  For minimizing data rate or other reasons perhaps they decided not to double up error-correction, since it was already being done.  I suspect they are probably required to encrypt the data stream for ITAR reasons and therefore couldn't release pre-error-corrected raw telemetry even if they wanted to.


And by the way-- amazing effort so far, by all involved. 
« Last Edit: 05/06/2014 03:13 AM by knotnic »

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
Ive added 2 features to https://github.com/michaelni/FFmpeg/tree/spacexdebug1
first, you can now use syntax like
-mmb 40:03:-1
to fill the image with "blank" blocks starting from 40:03 and until the next specified command
and
-mmb X:20009:1B
to xor 0x1B at bit position 20009 of the frame, that is this allows to flip some bits without the need to edit the file
(atm this is limited to max 8bit per command)

Added another feature, now you can adjust DC values of the blank blocks
each MB has 6 blocks 4 luma and 2 chroma
example to adjust the 4th luma DC of (blank) MB 40:3 by +100
-mmb 40:03:-1:0:0:0:100:0:0

Can you explain more how to use this feature and what it does and why its useful? We're getting really far down in the trenches here.

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
Added another feature, now you can adjust DC values of the blank blocks
each MB has 6 blocks 4 luma and 2 chroma
example to adjust the 4th luma DC of (blank) MB 40:3 by +100
-mmb 40:03:-1:0:0:0:100:0:0

Can you explain more how to use this feature and what it does and why its useful? We're getting really far down in the trenches here.

Some of the decoded pictures show rectangular areas extending to the right and down with wrong color/brightness, adjusting the DC value of the MB in the left top corner of such rectangle would allow to workaround the artifact

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
Using michaelni's changes I have made the best version to date I think of the upper portion of iframe8. Really works amazingly well. Now to start into the mess at the bottom.

-mmb 08:14:-1:15:-15:1:14:-2:1,09:14:56683

Edit: fixed to better version
« Last Edit: 05/06/2014 04:25 AM by mlindner »

Offline arnezami

  • Full Member
  • **
  • Posts: 275
  • Liked: 258
Hi guys,

Great stuff all! Like the wiki and the new "empty"-block commands!

Btw I updated the install.txt so you can download the new version:

http://forum.nasaspaceflight.com/index.php?topic=34597.msg1193442#msg1193442

Regards and have fun, :)

arnezami

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
I think I got a bit more of iframe 8, hard to tell what the correct alignment is.

ffmpeg -mmb 07:14:17233,14:14:57111,08:15:17233,09:15:63546,19:16:17233,21:16:73568,08:21:17233,00:22:111664 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_8.mpg4-img -f image2 img-%03d.png

Working from yours combining with mine I have this so far.

-mmb 08:14:-1:15:-15:1:14:-2:1,09:14:56683,21:16:73568,08:21:17233,00:22:111664,01:28:139511,05:28:143051

I need more information on what's at the bottom so going to work on one of the other iframes now. I'm moving on to working on iframe7.

Edit: I think part of the problem is that we're seeing remnants of that darn dirty water that they splashed all over the rocket... So we have these dark and light splotches.
« Last Edit: 05/06/2014 09:51 AM by mlindner »

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
Hack job on iframe7. I can do better, but probably am calling quits for tonight.

-mmb X:18494:01,19:05:-1,19:06:20616,15:12:-1,17:12:44357

Offline gospacex

  • Senior Member
  • *****
  • Posts: 2203
  • Liked: 54
In order to fix this you could try to restore the bitstream itself. But this is very hard to do and extremely time consuming (fixing compressed data is no joke!). The worse is: you don't know when the bad bits stop.

If data errors are random, if garbled bits are not occurring in bursts, but randomly, then fixing garbled block entails inverting one bit and looking whether image got better in the block and after it. If it got worse, you inverted a "good" bit. If it got better, you inverted a corrupted one.

Thankfully, there aren't than many bits in, say, 32 bytes - only 256.

Online mlindner

  • Full Member
  • ****
  • Posts: 1567
  • Liked: 205
  • Ann Arbor, MI
In order to fix this you could try to restore the bitstream itself. But this is very hard to do and extremely time consuming (fixing compressed data is no joke!). The worse is: you don't know when the bad bits stop.

If data errors are random, if garbled bits are not occurring in bursts, but randomly, then fixing garbled block entails inverting one bit and looking whether image got better in the block and after it. If it got worse, you inverted a "good" bit. If it got better, you inverted a corrupted one.

Thankfully, there aren't than many bits in, say, 32 bytes - only 256.

Nope. Errors tend to come in bursts I've seen, which makes sense. Also, inverting a bad bit can make the entire image worse because a following bad bit could have been partially correcting for the changes the previous change did.

Also, its better to talk about bits here because, to save space, almost nothing is byte aligned. Everything is packed together.
« Last Edit: 05/06/2014 02:30 PM by mlindner »

Tags: