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

Offline djellison

  • Member
  • Posts: 26
  • Liked: 23
  • Likes Given: 0
I asked Doug Ellison, the JPL guy who did the MSL descent video, if he had any tips

While I did some MSL MARDI vid stuff - I was never involved in any of the gorgeous interpolated and rotoscoped versions that some really creative people came up with. 

Impressed people are making some progress with the F9 1.1 feed - that's some seriously junky data!

Offline lgjy98d

  • Member
  • Posts: 10
  • Liked: 6
  • Likes Given: 0
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.

Offline apollolanding

  • Veteran
  • Full Member
  • ***
  • Posts: 362
  • Member Since 2006-04-10
  • New Jersey
  • Liked: 192
  • Likes Given: 91
Just when I thought I'd seen it all from the NSF crowd, this thread shows up.  Amazing, amazing work!  I don't understand 99% of what you guys are sharing, but I find the labor and results fascinating nonetheless!  Bravo Zulu to you all!
Proud Member of NSF Since 2006-04-10.

Online mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
mlindner was asking for a non-corrupted image, so this one comes from the reentry burn of Cassiope launch

That's a different camera unfortunately.
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Online mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
I updated my Transport stream tool.  It's probably not going to help much at this point but it does have a hex editor and powerful search feature with a bit level wildcard filter, ability to return results with a specified tolerated number of single bit errors and the results are easy to visualize and locate. 

To do:
Disable controls until a ts file is opened.
Make the search capable of finding results that are not byte aligned. 
Add a replace feature with a wildcard filter.
Enable bit level insertion and deletion ability. (would bit shift everything after that point in the file)


I think its a good companion tool for this transport stream editor. 
http://www.videohelp.com/tools/TS-Packet-Editor

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.
« Last Edit: 05/06/2014 01:01 am by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
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

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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.
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Online mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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 »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Online mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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 »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
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: 160
  • Liked: 40
  • Likes Given: 38
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: 52
  • Liked: 3
  • Likes Given: 2
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

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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.
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
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

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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 »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
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

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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 »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Online mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
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

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
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 »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Tags:
 

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