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

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 572
  • Liked: 446
  • Likes Given: 1428
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1640 on: 06/17/2014 11:59 PM »
mmb autoconversion works now for i frames that have been converted to p frames. Conversion can introduce problems occasionally e.g. in iframe 81 a string of blocks looked good in the original, but bad after conversion, my guess is they may contain an imperceptible error and therefore don't convert correctly, this in turn caused dc issues. As proof of concept I submit iframe 281 converted to p frame. The method worked well with little effort for this one because the blank region was already set to -2. Blocks set to -3 will behave like -2 blocks for the subsequent mbs i.e. they provide no inheritance which is both good and bad - they shouldn't cause propagating errors, but the dc's for subsequent blocks would need to be added manually. This would be much easier in the online editor.

IainCole, would it be possible to put these frames into the online editor so others could take a crack at setting blocks to -3 and filling the blanks in iframes? Lot of dc work is needed for this.

Edit: gif not animating, so zip it must be.
Edit2: I'll also add a png of the actual frame 281.

Could you explain what you did with more details? Did you modify the program (h263dec.c)? I don't really understand...

No, I'm not skilled enough to touch the ffmpeg source. Frames can contain intra and inter macroblocks. I frames contain only inrtras, but p frames have both. I changed the header of the I frame into a p frame header and converted all I frame macroblocks to p frame intra macroblocks so that the new p frame contains only intra mbs. This turned out to be surprisingly easy because all that needed to be done was adding the not_coded bit (with zero value) to each macroblock and the mcbpc had to be changed to pframe equivalent (there are only 4 valid ones in this vid).

And what about the frames following the one you converted? Do they also inherit the data?

Yes, data (and errors for that matter, but this could be easily mitigated) can potentially propagate from the first frame to the last in the video with this method.

Meanwhile, here's another piece of low hanging fruit. Parts 12+13 from the video with iframe 241 in the middle. This time in mp4 format.
« Last Edit: 06/18/2014 12:00 AM 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 #1641 on: 06/18/2014 06:50 AM »
Meanwhile, here's another piece of low hanging fruit. Parts 12+13 from the video with iframe 241 in the middle. This time in mp4 format.

Nice to see part 13 with the top half of the frame as more than just an accumulation of the p frames!  Other than the chroma mismatch that's looking pretty seamless.  :D


I finished corrected part 3, that was difficult and I'm not completely sure of the alignment for the first frames. Now only part 4 remains (also quite difficult...)

Parts 3 and 4 are certainly nightmare material, lots of corruption, lots of data to fix up in each p frame because of how much the frames change as the rocket drops through the clouds... I've done a first pass over them now to fix all the major issues, lots of medium-minor ones left. 

Online pippin

  • Regular
  • Senior Member
  • *****
  • Posts: 2566
  • Liked: 292
  • Likes Given: 39
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1642 on: 06/18/2014 10:10 AM »
@Chris

could you maybe add the link to the YouTube channel (and maybe the Wiki, too) to the first post of the thread.
Makes it easier to find; I just realized that a search on YouTube finds all kind of old versions first.

I'm talking about this one:
https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww
« Last Edit: 06/18/2014 10:13 AM by pippin »

Online Chris Bergin

@Chris

could you maybe add the link to the YouTube channel (and maybe the Wiki, too) to the first post of the thread.
Makes it easier to find; I just realized that a search on YouTube finds all kind of old versions first.

I'm talking about this one:
https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww

Copy that. Done. :)

Offline SwissCheese

  • Full Member
  • *
  • Posts: 165
  • Liked: 250
  • Likes Given: 97
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1644 on: 06/18/2014 01:08 PM »
Perhaps a few seconds of credits could be added to the end of the video so that everyone involved has their member name (or real name) noted?

I added 3 frames to the video. Nothing very artistic, so if someone makes something nicer it would be very cool. Also tell me if I forgot to mention someone, or if we should put the real names, or if something should be changed (colors, add pictures, ...)

(P.S.: my video does not have the clock corrections since I generate it locally)

edit: additional_frames.zip contains the logos, adobe illustrator files and png images
edit2: added Swatch to the list
« Last Edit: 06/18/2014 02:44 PM by SwissCheese »

Online pippin

  • Regular
  • Senior Member
  • *****
  • Posts: 2566
  • Liked: 292
  • Likes Given: 39

Offline catdlr

  • Member
  • Senior Member
  • *****
  • Posts: 5633
  • Viewed launches since the Redstones
  • Marina del Rey, California, USA
  • Liked: 2197
  • Likes Given: 1546
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1646 on: 06/18/2014 03:57 PM »
Perhaps a few seconds of credits could be added to the end of the video so that everyone involved has their member name (or real name) noted?

I added 3 frames to the video. Nothing very artistic, so if someone makes something nicer it would be very cool. Also tell me if I forgot to mention someone, or if we should put the real names, or if something should be changed (colors, add pictures, ...)

(P.S.: my video does not have the clock corrections since I generate it locally)

edit: additional_frames.zip contains the logos, adobe illustrator files and png images
edit2: added Swatch to the list

excellent SwissCheese and more.
Tony De La Rosa

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1647 on: 06/18/2014 04:49 PM »
I did some experimenting with interlaced output. We've been taking interlaced source material and outputting it as 15p. We should be able to output partial frames at a higher rate. Indeed, the clock difference between partial frames is ~0.04s. However, the motion of the rest of the video does not seem to match the clock spacing, so while the video is smoother it is not the slam dunk I had hoped it would be. I attached both formats for comparison. _clockfix.mp4 is 15p, _clockfix_30.mp4 is 30i.

The p-frame editor was build to handle only 1 TS set, but I can add alternative frames into the frameset

Would it be possible to clone it and put it to a different url altogether? Alternatively maybe it's possible to add sections to the dropdown menu (like P-15(281))? Are you using mpg4-imgs or ts as the ffmpeg input? Because to converted frames are mpg4-imgs and can't be (easily) put back into the ts container.

It uses TS files, 1 TS file per Iframe and subsequent p frames, no idea if / how it would work with mp4-img files

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 572
  • Liked: 446
  • Likes Given: 1428
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1649 on: 06/18/2014 06:02 PM »
It uses TS files, 1 TS file per Iframe and subsequent p frames, no idea if / how it would work with mp4-img files

It should work identically I believe. ffmpeg -i part_x.ts behaves exactly the same as ffmpeg -i part_x_frame_%2d.mpg4-img. At least in my experience.

It uses TS files, 1 TS file per Iframe and subsequent p frames, no idea if / how it would work with mp4-img files

It should work identically I believe. ffmpeg -i part_x.ts behaves exactly the same as ffmpeg -i part_x_frame_%2d.mpg4-img. At least in my experience.

OK cool, you gonna send me the stuff?

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 572
  • Liked: 446
  • Likes Given: 1428
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1651 on: 06/18/2014 06:09 PM »
I'll put it together in a zip and post here maybe? It might take a little time, all frames aren't converted yet.

Offline moralec

I did some experimenting with interlaced output. We've been taking interlaced source material and outputting it as 15p. We should be able to output partial frames at a higher rate. Indeed, the clock difference between partial frames is ~0.04s. However, the motion of the rest of the video does not seem to match the clock spacing, so while the video is smoother it is not the slam dunk I had hoped it would be. I attached both formats for comparison. _clockfix.mp4 is 15p, _clockfix_30.mp4 is 30i.

I think it looks better! Any idea on how to treat these partial frames? what they contain exactly?

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1295
  • Likes Given: 1686
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1653 on: 06/18/2014 06:14 PM »
I did some experimenting with interlaced output. We've been taking interlaced source material and outputting it as 15p. We should be able to output partial frames at a higher rate. Indeed, the clock difference between partial frames is ~0.04s. However, the motion of the rest of the video does not seem to match the clock spacing, so while the video is smoother it is not the slam dunk I had hoped it would be. I attached both formats for comparison. _clockfix.mp4 is 15p, _clockfix_30.mp4 is 30i.

I think what we were able to determine with Princess' analysis of the settings of the video is that the MPEG is encoded as ~15fps progressive, and the interlacing artifacts we're seeing in the clock and elsewhere likely arise from the encoder being fed by a ~30fps NTSC interlaced video camera, which was interlacing two ~30fps frames into a single frame which was then encoded as progressive at ~15fps for transmission.
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1654 on: 06/18/2014 07:33 PM »
I think what we were able to determine with Princess' analysis of the settings of the video is that the MPEG is encoded as ~15fps progressive, and the interlacing artifacts we're seeing in the clock and elsewhere likely arise from the encoder being fed by a ~30fps NTSC interlaced video camera, which was interlacing two ~30fps frames into a single frame which was then encoded as progressive at ~15fps for transmission.

When talking about interlaced source material it helps to distinguish fields from frames. A "field" in this case is a half-height image consisting of alternate lines from the video camera. Two fields make a frame, where a frame is a full-height image. I'm used to PAL video where a camera captures 50 fields per second and interlaces them into 25 frames per second; for NTSC this is ~60 fields per second, interlaced to ~30 frames per second.

Without knowing SpaceX's transmission setup it's hard to know what's happening, but it could be that the camera is capturing at ~60 fields per second (standard NTSC). The timestamp might be overlaid onto each field separately, before they get combined into frames. Then the MPEG4 encoder may just ignore every second frame. This would mean that each frame might consist of two fields that are only ~1/60th of a second apart, not ~1/30th.

To me this seems at least plausible, as the only reason you'd use interlaced video is if you were using an off-the-shelf analogue NTSC camera to capture the video. Anything digital like a webcam would use progressive video.

If I was to hazard a guess, I would say SpaceX found some space-rated analogue NTSC camera that outputs composite video. This is then run into an off-the-shelf board that has two main components: a capture chip outputting BT656 uncompressed digital video into some form of small ARM SoC with a DSP-assisted MPEG4 encoder. They'd do some software work in the ARM core to overlay a timestamp onto the incoming stream, which at this point is still at ~60 fields per second. Then they'd need to reduce the amount of data being output, so they'd tweak the MPEG4 encoder to only encode at half the framerate. This could give you ~15 frames per second, where each individual frame is made of two fields that are only 1/60th apart.

Or I may be totally wrong ;)

Online ugordan

  • Senior Member
  • *****
  • Posts: 7617
    • My mainly Cassini image gallery
  • Liked: 1840
  • Likes Given: 406
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1655 on: 06/18/2014 07:39 PM »
Without knowing SpaceX's transmission setup it's hard to know what's happening, but it could be that the camera is capturing at ~60 fields per second (standard NTSC). The timestamp might be overlaid onto each field separately, before they get combined into frames. Then the MPEG4 encoder may just ignore every second frame. This would mean that each frame might consist of two fields that are only ~1/60th of a second apart, not ~1/30th.

It looks to me they're really transmitting fields taken 1/30th of a second apart. If you look closely at the SES-8 highlights video, they seem to have converted certain portions of the onboard video into 30 fps, albeit at noticeably lower vertical resolution. It looks smooth so it leads me to believe they're capturing video at 30 fields per second, strange as that seems. I think two consecutive, 1/60th-second frames would end up looking more jerky.

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 572
  • Liked: 446
  • Likes Given: 1428
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1656 on: 06/18/2014 08:35 PM »
I attach a zip conatining folders each containing 40 mpg4-img files. They start with iframe and are followed by the 19 pframes of the section followed by P frame converted iframe of the next section and its subsequent p frames. Each folder also contains a txt file with the mmb for the converted frame (frame_21.mpg4-img in the folders). There is an issue with conversion for iframe 121 (in part5_6) I still have to investigate, might be bad vop_quant.

I have modified some mmbs already with -3 commands for the blank regions (part3_4, part12_13 and part14_15). Others remain to be done, but probably require more dc tweaking.

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1657 on: 06/18/2014 09:38 PM »
Is there an easy way to figure out what bits a DC correction changes?

Example, i frame 4, these are effectively 3 single bitflips that fix the luma down in the clock region.  The clock itself is still damaged, which might be fixable if these flips aren't single flips, but triple flips that just happen to have one part in a luma sub block...

6:29:86644:64:0:0:0:0:0, 7:29:87881:0:-32:0:-64:0:0

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 #1658 on: 06/18/2014 09:49 PM »
Ours is better.  8)



Onboard hi-def camera of F9R test at McGregor yesterday (17-Jun). Now with steerable fins.
« Last Edit: 06/18/2014 09:53 PM by mhenderson »

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 572
  • Liked: 446
  • Likes Given: 1428
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1659 on: 06/18/2014 10:06 PM »
Is there an easy way to figure out what bits a DC correction changes?

Example, i frame 4, these are effectively 3 single bitflips that fix the luma down in the clock region.  The clock itself is still damaged, which might be fixable if these flips aren't single flips, but triple flips that just happen to have one part in a luma sub block...

6:29:86644:64:0:0:0:0:0, 7:29:87881:0:-32:0:-64:0:0

If dcs are off by that much (32 and 64) there are probably errors in dc size vlc codes, but I fear there is no easy way to figure out anything about that ;) Is it a flip in dc size vlc or there's a flip before, which causes it to be read wrong? Go figure.

edit: But if the clock itself is wrong the errors are obviously aready in the luma blocks so no wonder chromas are broken too. Sorry, you were already talking about luma. Still the error could be in the previous block, but dc_size luminance would be my best guess. I would just xor through the whole block if it hasn't been done already.

edit2: flipped through the end of 5:29 and the first block of 6:29 (singles, triples and quads) - nothing. This macroblock is huge and covers most of a ts packet. I think the whole ts packet is bad, too many errors for me.
« Last Edit: 06/18/2014 11:30 PM by saliva_sweet »

Tags: