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

Online Chris Bergin

  • NSF Managing Editor
  • Administrator
  • Senior Member
  • *****
  • Posts: 96405
  • Liked: 5952
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
http://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
http://www.nasaspaceflight.com/2014/02/spacex-crs-3-landing-legs-plan-first-stage-recovery-ambitions/

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

Rockets that return home SpaceX pushing the boundaries
http://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!

http://www.nasaspaceflight.com/2014/06/recovering-falcon-9-ocean-landing-video-done/
« Last Edit: 06/26/2014 07:03 PM by Chris Bergin »

Online Chris Bergin

  • NSF Managing Editor
  • Administrator
  • Senior Member
  • *****
  • Posts: 96405
  • Liked: 5952
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

Offline Lars_J

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

 

Online StephenB

  • Full Member
  • **
  • Posts: 276
  • Liked: 16
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: 368
  • Liked: 93
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: 3
  • Liked: 5
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: 6163
  • Liked: 660
  • California
No, it is the *data* that has been recovered. (although they did find some pieces)

Offline billh

  • Full Member
  • *
  • Posts: 190
  • Liked: 29
  • Houston
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: 635
  • Liked: 50
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
  • Senior Member
  • *****
  • Posts: 5653
  • Liked: 140
My recommendation for cleaning this up is to repeat the test.  :)

Offline MTom

  • Full Member
  • **
  • Posts: 298
  • Liked: 82
  • EU / Hungary
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: 3613
  • Liked: 1078
Which means, IMO, they should rotate the image 90 degrees between successive key frames, as far as the compression is concerned.

Offline Lars_J

  • Senior Member
  • *****
  • Posts: 6163
  • Liked: 660
  • California
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?

Online arnezami

  • Full Member
  • **
  • Posts: 275
  • Liked: 258
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 »

Online Chris Bergin

  • NSF Managing Editor
  • Administrator
  • Senior Member
  • *****
  • Posts: 96405
  • Liked: 5952
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).

Tags: