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

Offline Chris Bergin

Certainly needs cleaning up! Video experts around the world requested to help SpaceX with this.



Best repair so far:


Background:

CRS-3 Falcon 9 first stage to sport legs and attempt soft splashdown
https://www.nasaspaceflight.com/2014/02/crs-3-falcon-9-first-stage-sport-legs-attempt-soft-splashdown/

SpaceX outlines CRS-3 landing legs plan toward first stage recovery ambitions
https://www.nasaspaceflight.com/2014/02/spacex-crs-3-landing-legs-plan-first-stage-recovery-ambitions/

SpaceX Falcon 9 successfully launches CRS-3 Dragon
https://www.nasaspaceflight.com/2014/04/spacex-crs-3-dragon-new-milestones/

Rockets that return home – SpaceX pushing the boundaries
https://www.nasaspaceflight.com/2014/04/rockets-return-home-spacex-pushing-boundaries/

--

UPDATE:

The video updates, in order, are available on this channel:
https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww

Here's the post-competition technical feature article - by the team's Lourens Veen!

https://www.nasaspaceflight.com/2014/06/recovering-falcon-9-ocean-landing-video-done/


UPDATE:

Five year anniversary:
https://twitter.com/NASASpaceflight/status/1123300237647519744
« Last Edit: 04/30/2019 07:02 pm by Chris Bergin »
Support NSF via L2 -- Help improve NSF -- Site Rules/Feedback/Updates
**Not a L2 member? Whitelist this forum in your adblocker to support the site and ensure full functionality.**

Offline Chris Bergin

Guy on twitter (not sure if he's on here, but in response to me on twitter....)

Ryan Ziolko ‏@MediumFidelity  6m
@nasaspaceflight It's going to be tricky, the file contains large sections like this: pic.twitter.com/E5Csw1sjXy
Support NSF via L2 -- Help improve NSF -- Site Rules/Feedback/Updates
**Not a L2 member? Whitelist this forum in your adblocker to support the site and ensure full functionality.**

Offline Lars_J

  • Senior Member
  • *****
  • Posts: 6160
  • California
  • Liked: 677
  • Likes Given: 195
The original data files are available for download from SpaceX here:
http://www.spacex.com/news/2014/04/29/first-stage-landing-video

 

Offline StephenB

  • Full Member
  • **
  • Posts: 282
  • Liked: 17
  • Likes Given: 201
If the data is just not there (like those ffff's), then no recovery is possible, right?
« Last Edit: 04/30/2014 08:00 pm by StephenB »

Offline Jarnis

  • Full Member
  • ****
  • Posts: 1313
  • Liked: 830
  • Likes Given: 201
If the data is just not there (like those ffff's), then no recovery is possible, right?

Well, some data could be transferred from known good images from the same camera as far as the fixed part of the image (rocket body) goes. Beyond that, it would require some imagination and frame-by-frame touching up. It would be partially fiction at that point...

If there only were some additional fully intact frames, a bunch of damaged ones between them could be interpolated but that just isn't there I think.


Offline swlee

  • Member
  • Posts: 8
  • Liked: 7
  • Likes Given: 4
On the SpaceX web page, they preface the videos with:
"Below is a look at the original video data from the first stage landing, recovered from the Falcon 9 onboard camera and shot right before splashdown".

Does this imply that the camera itself was recovered (and, by extension, at least some part of the first stage)?

Offline Lars_J

  • Senior Member
  • *****
  • Posts: 6160
  • California
  • Liked: 677
  • Likes Given: 195
No, it is the *data* that has been recovered. (although they did find some pieces)

Offline billh

  • Full Member
  • ****
  • Posts: 777
  • Houston
  • Liked: 1096
  • Likes Given: 790
No, it is the *data* that has been recovered. (although they did find some pieces)

Looks like they only found "some pieces" of the data, too.  :)

Offline adrianwyard

  • Full Member
  • ****
  • Posts: 1140
  • Liked: 322
  • Likes Given: 367
It's interesting to me that this demonstrates the value of using analog rather than digital signal transmission in some circumstances. Even an extremely noisy analog signal would have been easier to reconstruct than this one, with its macroblocking/i-frame image-segment tracking weirdness. It can be done, but would be easiest if you had access to the exact compression code used on the camera. If SpaceX are smart they'll release that info.

Before now I've been disappointed to see the Wireless Video System used for EVAs had quite a lot of static and dropouts (given that we live in an HD digital world) but in retrospect perhaps that is the best signal to send.
« Last Edit: 04/30/2014 08:22 pm by adrianwyard »

Offline Lee Jay

  • Elite Veteran
  • Global Moderator
  • Senior Member
  • *****
  • Posts: 8565
  • Liked: 3603
  • Likes Given: 327
My recommendation for cleaning this up is to repeat the test.  :)

Offline MTom

  • Full Member
  • ****
  • Posts: 573
  • EU / Hungary
  • Liked: 340
  • Likes Given: 993
If the data is just not there (like those ffff's), then no recovery is possible, right?

Well, some data could be transferred from known good images from the same camera as far as the fixed part of the image (rocket body) goes. Beyond that, it would require some imagination and frame-by-frame touching up. It would be partially fiction at that point...

If there only were some additional fully intact frames, a bunch of damaged ones between them could be interpolated but that just isn't there I think.

The top of many frames are more or less intact. Maybe they could be a good starting point.
« Last Edit: 04/30/2014 08:23 pm by MTom »

Offline meekGee

  • Senior Member
  • *****
  • Posts: 14152
  • N. California
  • Liked: 14030
  • Likes Given: 1391
Which means, IMO, they should rotate the image 90 degrees between successive key frames, as far as the compression is concerned.
ABCD - Always Be Counting Down

Offline Lars_J

  • Senior Member
  • *****
  • Posts: 6160
  • California
  • Liked: 677
  • Likes Given: 195
Which means, IMO, they should rotate the image 90 degrees between successive key frames, as far as the compression is concerned.


So... Basically use an completely new codec?

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi guys,

Today I have done a low-level analysis of the raw.ts file. Most notably the "Transport Stream Headers" (see http://en.wikipedia.org/wiki/MPEG_transport_stream )

While it is bad, its not as bad as is being suggested above. The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:

4703e8: 15,014 times
471fff: 4,966 times
4743e8: 263 times
474000: 81 times
474020: 74 times

The actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data.

The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".

The other correct packets are basicly overhead. I will not go into them. But they are essential for the video working. There are a lot more than shown above btw.

The problem lies in the remaining bad headers (still several thousand): they get ignored by the video-player which causes it to act strangely. Also: a lot of bits (not just in the header but also in the content) are flipped. But my hope is that this is not the biggest issue: mpeg-4 is quite resilient.

I'm trying to figure out if I can "repair" most of the headers so the video player can at least decide what to do with the data in it (now it will just ignore it because they have the wrong PID, invalidating valid packets in the meantime).

This however is no simple task. :P

Fingers crossed.

Regards,

arnezami

« Last Edit: 04/30/2014 08:49 pm by arnezami »

Offline Chris Bergin

Good luck Arnezami! If you have any success, also PM me as I'll hook you up with the SpaceX people (the e-mail address they provide is just an "inbox pile" address, I can get you direct).
Support NSF via L2 -- Help improve NSF -- Site Rules/Feedback/Updates
**Not a L2 member? Whitelist this forum in your adblocker to support the site and ensure full functionality.**

Offline meadows.st

  • Full Member
  • *
  • Posts: 158
  • Toronto ON, Canada
  • Liked: 90
  • Likes Given: 5391
Hi guys,

Today I have done a low-level analysis of the raw.ts file. Most notably the "Transport Stream Headers" (see http://en.wikipedia.org/wiki/MPEG_transport_stream )

While it is bad, its not as bad as is being suggested above. The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:

4703e8: 15,014 times
471fff: 4,966 times
4743e8: 263 times
474000: 81 times
474020: 74 times

The actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data.

The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".

The other correct packets are basicly overhead. I will not go into them. But they are essential for the video working. There are a lot more than shown above btw.

The problem lies in the remaining bad headers (still several thousand): they get ignored by the video-player which causes it to act strangely. Also: a lot of bits (not just in the header but also in the content) are flipped. But my hope is that this is not the biggest issue: mpeg-4 is quite resilient.

I'm trying to figure out if I can "repair" most of the headers so the video player can at least decide what to do with the data in it (now it will just ignore it because they have the wrong PID, invalidating valid packets in the meantime).

This however is no simple task. :P

Fingers crossed.

Regards,

arnezami

Great work @arnezami. If there is a way to "crowdsource" the crowdsource (e.g. by breaking the effort into small brute force chunks that the rest of us can do and that you could reassemble), I volunteer.  I don't have the expertise to do the manual parsing but am happy to do some scripting or even manual editing if instructed on what needs to be done.
“A little rudder far from the rocks is a lot better than a lot of rudder close to the rocks.” L. David Marquet

Offline MP99

While it is bad, its not as bad as is being suggested above. The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:

4703e8: 15,014 times
471fff: 4,966 times
4743e8: 263 times
474000: 81 times
474020: 74 times

The actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data.

The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".

It seems a real shame that they didn't use the ~25% of unwanted bandwidth for parity / CRC / redundancy. Ah well, roll on flight #10.

Anyway - best of luck with this.

Cheers, Martin

Offline QuantumG

  • Senior Member
  • *****
  • Posts: 9238
  • Australia
  • Liked: 4477
  • Likes Given: 1108
So.... I did a little digging on that video stream.

Everything I've seen online so far, including what SpaceX put out, just looks like they used ffmpeg to pull out the frames.. which is what I did too. However, I also did ffmpeg -i raw.ts raw.mpg and then compared the bytes in the mpg to the ts.

It skips the first 847k of the ts, but after that it hums along. Mostly the data comes across in 184 byte chunks, with an occasional truncated or dropped chunk. There's some really big gaps though.

If you know how to extract I frames manually from a stream, you could probably easily pull at least one out of those big gaps.

The top 5 are:

8864 bytes at 0x0011d470
11120 bytes at 0x00170664
15952 bytes at 0x000d6260
23716 bytes at 0x000df508
23904 bytes at 0x001502dc

I wrote a little code to attempt it but I only saw one extra I frame and couldn't get it to convert to an image. Now I'm out of time.
Human spaceflight is basically just LARPing now.

Offline IRobot

  • Full Member
  • ****
  • Posts: 1312
  • Portugal & Germany
  • Liked: 310
  • Likes Given: 272
The first thing I would do to improve video quality on future flights would be to encode a monochrome image. Color is useless for this type of image.

Offline SpaceX_MS

  • Full Member
  • ****
  • Posts: 402
  • Liked: 10291
  • Likes Given: 138
Great thread. If one of you guys can help, it will be worth your time and effort. This is an Elon call to arms.

Tags:
 

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