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

Offline arnezami

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

I've also been thinking about the frame numbers. If we are going to find more P-frame (we almost surely are) then all these frame numbers we use now are going to be wrong.

I suggest doing the following to prevent this: take the byte-position of the frame in the .ts file (you can for example use ffprobe for that) and remove the last 4 digits of the postion (eg 3552521 becomes 355). That way we will not be bothered by new frames. And these numbers will at most be 3 digits long. Not too bad.

Good idea?

Regards,

arnezami

PS. While it is theoretically possible to get collisions this way this is currently not the case: I checked it. And if if that happens once or twice we can come up with a simple solution like 355.2 and 355.8.
« Last Edit: 05/20/2014 03:28 pm by arnezami »

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107

Offline moralec

Excellent edits! and I agree with both having the stand-alone frame instead of the combined one, and including the byte-position (I just added a new column in the table for that).

I'm going to make the rest of the 14 pages using this template.

And SwissCheese, that latest gif looks terrific! Great work.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I updated http://spacexlanding.wikispaces.com/Frames+169-188 :)
Impressive! :)

You just more than doubled the amount of decoded frames!
« Last Edit: 05/20/2014 06:39 pm by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I have two questions for the rocket experts8)

When looking at the latest result from SwissCheese:



1. Does the widening of the "bright circle" mean the rocket is going downwards and therefore the flame widens because the flame hits the water earlier and earlier and therefore it spends more time over the water (instead of going down towards the water) to die out going to the sides? Or does it mean the rocket is almost hovering and the fire/flames are simply accumulating at one spot and has no more room so it widens?

2. Can you deduce something from the movement from the waves in the water (see for example the waves on the left) about either the height or the speed the rocket is going down? Of maybe deduce a change in velocity? Keep in mind this should actually be run at 15 frames per second.

Regards,

arnezami

[edit] Maybe it is wise that we are going to have a separate thread on the interpretation of the video besides this thread about the repair of the video.
« Last Edit: 05/20/2014 08:13 pm by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I know we are trying to replace bad mmb with good mmb. So would it be useful to document the XY and POS of good mmb's? I am thinking if we can map out what we know to be good, figuring out what to replace the bad with may be easier.
Welcome to the forum PaulNY!

From what I understand your idea is to catalog good macro blocks in all the frames. Good as in decided by human beings not by some algorithm I assume.

This may be of some use. I'm not sure. We sort of implicitly rely on our vision to detect good vs bad blocks. We also have a nice feature in the online tool that highlights all error-macroblocks in a frame. There are still plenty of non-error-blocks left that look "bad", but we don't know if they are easily repairable or are really bad. We usually judge their "badness" by the destruction they cause to other blocks.

So depending on what you think 1. what the criteria of "bad" is, or even multiple classes of bad and 2. how you think we can deal with those kinds of "badness", your idea might have some value.

Maybe you can try to "fertilize" your ideas a little bit so it becomes more clear if we can use it. :)

Regards,

arnezami

PS. We refer to mmb as "modify macro block". I believe when you say mmb you actually ment to say "macro block".
« Last Edit: 05/20/2014 08:44 pm by arnezami »

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0

However there is one thing that I find difficult to do myself. And I think you might be able to help us. Instead of using this kind of setting:

15:14:-1:0:-40:0:0:0:20

where I replace the current macroblock with a blank one and change the DC values.

But what I really want to do is this:

15:14:57217:0:-40:0:0:0:20

In other words: I want to keep the macroblock with its (structured) data as much as I can (at the very least the blocks in it which are set to 0 above) but change only the DC "starting" values. So not blanken it, but modifying it so these DC-values make sure propogation to other blocks works the same as now with -1 (therefore fixing the color and intensity of following blocks) but I also keep the current blocks inside the current macroblock.

Is something like that possible?

yes but i am not sure i understand what you are trying to correct.
That is if the "current" MB is ending up with a bad dc value, that would either be caused by one of its 6 dc coefficients being damaged in the bitstream/decoded incorrectly due to surrounding damage or one of the surrounding 11 (left/topleft/top) dc values being wrong. Whatever is wrong, should be corrected ideally.
OTOH, if some dc value is overridden on top of the decoded MB then for example the bitstream might store a dc delta in 5 bits while the overridden value could need 6. If it actually was 6 in the undamaged file, ideally the damaged bit(s) should be flipped to make things match or if instead some previous block had a wrong dc value then it should be corrected so the 5bit vlc works out to the correct result.
What iam trying to say is, iam a bit concerned that by editing dc values after decoding MBs or by editing the dc prediction direction in a way that contradicts the surrounding DC values, errors are more covered up than corrected. But maybe thats the best that can be done, i dont know. but Ill look into implementing this as it should give more options/flexibility

Offline moralec


2. Can you deduce something from the movement from the waves in the water (see for example the waves on the left) about either the height or the speed the rocket is going down? Of maybe deduce a change in velocity? Keep in mind this should actually be run at 15 frames per second.


Considering this sequence of frames corresponds to less than one second in the video, the waves seem to me moving fast. This could be however explained by different factors. The rocket may be  still coming down at a fast speed. Also, the thruster may be generating a huge movement in the surface water (if even a small boat generates disturbances, think of the supersonic exhaust stream from the rocket.). We also need to consider that the sea was very agitated that day.....

Questions, questions questions....

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
yes but i am not sure i understand what you are trying to correct.
That is if the "current" MB is ending up with a bad dc value, that would either be caused by one of its 6 dc coefficients being damaged in the bitstream/decoded incorrectly due to surrounding damage or one of the surrounding 11 (left/topleft/top) dc values being wrong. Whatever is wrong, should be corrected ideally.
OTOH, if some dc value is overridden on top of the decoded MB then for example the bitstream might store a dc delta in 5 bits while the overridden value could need 6. If it actually was 6 in the undamaged file, ideally the damaged bit(s) should be flipped to make things match or if instead some previous block had a wrong dc value then it should be corrected so the 5bit vlc works out to the correct result.
What iam trying to say is, iam a bit concerned that by editing dc values after decoding MBs or by editing the dc prediction direction in a way that contradicts the surrounding DC values, errors are more covered up than corrected. But maybe thats the best that can be done, i dont know. but Ill look into implementing this as it should give more options/flexibility

I have already implemented this since then. And it works.

Maybe you want to look at what I did in the code (I think you already commited that). Maybe I am doing something that would be unwise. Essentially I use the forced DC code you already implemented earlier but do it in a relative way (instead of absolute).

From what I understand if you change a dc value to effectively its original value (which you hope you guess right of course) then blocks after that will correctly choose from which block (left or top) they should take their prediction. In other words: changing these values *should* have a good impact on correct propagation.
« Last Edit: 05/20/2014 09:09 pm by arnezami »

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
I found the missing p-frame between i-frames 150 and 169, it is just following the i-frame. Here the debug log at the end of the i-frame, the next frame is a p-frame but keeps the number 000 when it should have 001. Should we try to find the position in the ts file and hand-edit the "ghost" p-frame header?

[mpeg4 @ 03d9f020] MB pos/size: 0 000:38:29:0 22 dc: 83 84 83 84 - 129 108
[mpeg4 @ 03d9f020] MB pos/size: 0 000:39:29:0 22 dc: 81 78 81 78 - 129 108
[mpeg4 @ 03d9f020] MB pos/size: 0 000:40:29:0 22 dc: 68 65 68 65 - 129 109
[mpeg4 @ 03d9f020] MB pos/size: 0 000:41:29:0 22 dc: 54 55 54 55 - 130 107
[mpeg4 @ 03d9f020] MB pos/size: 0 000:42:29:0 22 dc: 58 73 58 73 - 131 104
[mpeg4 @ 03d9f020] MB pos/size: 0 000:43:29:0 22 dc: 79 72 79 72 - 130 104
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 10 got 9
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 10 got 11
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 6 got 12
(20 such lines in total)
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 5 got 6
[mpeg4 @ 03d9f020] MB pos/size: 0 000:00:00:66 96 dc: -15 0 0 0 - -9 -9, MB_type: 12296, MV: 1 -1
[mpeg4 @ 03d9f020] MB pos/size: 0 000:01:00:162 151 dc: 0 39 0 0 - 0 0, MB_type: 12296, MV: 0 0
[mpeg4 @ 03d9f020] MB pos/size: 0 000:02:00:313 109 dc: 27 0 -9 0 - 0 0, MB_type: 12296, MV: 16 5
[mpeg4 @ 03d9f020] MB pos/size: 0 000:03:00:422 159 dc: 0 33 -9 -21 - 0 0, MB_type: 12296, MV: -6 2
[mpeg4 @ 03d9f020] MB pos/size: 0 000:04:00:581 239 dc: 123 116 111 112 - 144 122, MB_type: 1, MV: 0 0
[mpeg4 @ 03d9f020] MB pos/size: 0 000:05:00:820 47 dc: 0 0 0 0 - 0 0, MB_type: 12296, MV: 22 9

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107

2. Can you deduce something from the movement from the waves in the water (see for example the waves on the left) about either the height or the speed the rocket is going down? Of maybe deduce a change in velocity? Keep in mind this should actually be run at 15 frames per second.


Considering this sequence of frames corresponds to less than one second in the video, the waves seem to me moving fast. This could be however explained by different factors. The rocket may be  still coming down at a fast speed. Also, the thruster may be generating a huge movement in the surface water (if even a small boat generates disturbances, think of the supersonic exhaust stream from the rocket.). We also need to consider that the sea was very agitated that day.....

Questions, questions questions....

I don't think they are waves, but vapour. There are still 4 unused (and more difficult to correct, especially one) p-frames which could fill that in white.

Offline meadows.st

  • Full Member
  • *
  • Posts: 158
  • Toronto ON, Canada
  • Liked: 90
  • Likes Given: 5422
I updated http://spacexlanding.wikispaces.com/Frames+169-188 :)

Looks fantastic!

I also noted that the impinged plume in the final frame looks to be about the same size as the plume from the one picture of the Cassiope water "landing". (and after the servers came back up, I saw that Arnezami is thinking along the same lines...)

I have two questions for the rocket experts8)

When looking at the latest result from SwissCheese:



1. Does the widening of the "bright circle" mean the rocket is going downwards and therefore the flame widens because the flame hits the water earlier and earlier and therefore it spends more time over the water (instead of going down towards the water) to die out going to the sides? Or does it mean the rocket is almost hovering and the fire/flames are simply accumulating at one spot and has no more room so it widens?

2. Can you deduce something from the movement from the waves in the water (see for example the waves on the left) about either the height or the speed the rocket is going down? Of maybe deduce a change in velocity? Keep in mind this should actually be run at 15 frames per second.

Regards,

arnezami

[edit] Maybe it is wise that we are going to have a separate thread on the interpretation of the video besides this thread about the repair of the video.

The first picture is a marked up version of the only picture from the "alightment" of the F9S1 for the Cassiope mission.  We know that this attempt resulted in the engines failing at some point so I do not yet have any concrete understanding of how significantly the plume/water surface interaction differs from the CRS-3 return.

The second picture is (I believe) frame 188 from SwissCheese's latest Gif.  As Arnezami indicates above, the plume appears to expand from ~5 to 10m diameter at frame 169 to almost the entire width of the image at frame 188 (about 1.3s) but I don't want to hazzard a guess about the relationship to the Cassiope plume until I simulate the height of the craft at the time, the rate of descent and the throttle position.

I am sure there are many, many more people on this site that can run the fluid flow sims faster than I can (and much faster than I will have time to even attempt it)
« Last Edit: 05/20/2014 09:20 pm by meadows.st »
“A little rudder far from the rocks is a lot better than a lot of rudder close to the rocks.” L. David Marquet

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Ok let me ask the simpler question.

Does anybody know (and can explain why) what these white things are?

Because in this picture we should be quite close to the water right?

I am just curious  :)
« Last Edit: 05/20/2014 09:18 pm by arnezami »

Offline AncientU

  • Senior Member
  • *****
  • Posts: 6257
  • Liked: 4164
  • Likes Given: 6078

2. Can you deduce something from the movement from the waves in the water (see for example the waves on the left) about either the height or the speed the rocket is going down? Of maybe deduce a change in velocity? Keep in mind this should actually be run at 15 frames per second.


Considering this sequence of frames corresponds to less than one second in the video, the waves seem to me moving fast. This could be however explained by different factors. The rocket may be  still coming down at a fast speed. Also, the thruster may be generating a huge movement in the surface water (if even a small boat generates disturbances, think of the supersonic exhaust stream from the rocket.). We also need to consider that the sea was very agitated that day.....

Questions, questions questions....
Moving downward quickly and the surface of the water viewed by camera is 'shrinking' -- waves/white caps in upper right of the frame are moving radially outward as are the ones on the left.  The spreading flames are same as in videos of Grasshopper of F9R Dev 1 as it approaches the pad.
"If we shared everything [we are working on] people would think we are insane!"
-- SpaceX friend of mlindner

Offline AncientU

  • Senior Member
  • *****
  • Posts: 6257
  • Liked: 4164
  • Likes Given: 6078
Ok let me ask the simpler question.

Does anybody know (and can explain why) what these white things are?

Because in this picture we should be quite close to the water right?

I am just curious  :)
whitecaps
"If we shared everything [we are working on] people would think we are insane!"
-- SpaceX friend of mlindner

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Ok let me ask the simpler question.

Does anybody know (and can explain why) what these white things are?

Because in this picture we should be quite close to the water right?

I am just curious  :)

oo I did not think about those  ::)

Online saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
A couple more mbs from the top of frame 72. This is a rather painstaking process, but I intend to keep at it because I want this frame.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
whitecaps
Exactly. Thats what I thought. We must be very close to the water here already.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I updated http://spacexlanding.wikispaces.com/Frames+169-188 :)

Looks fantastic!

I also noted that the impinged plume in the final frame looks to be about the same size as the plume from the one picture of the Cassiope water "landing". (and after the servers came back up, I saw that Arnezami is thinking along the same lines...)

I have two questions for the rocket experts8)

When looking at the latest result from SwissCheese:



1. Does the widening of the "bright circle" mean the rocket is going downwards and therefore the flame widens because the flame hits the water earlier and earlier and therefore it spends more time over the water (instead of going down towards the water) to die out going to the sides? Or does it mean the rocket is almost hovering and the fire/flames are simply accumulating at one spot and has no more room so it widens?

2. Can you deduce something from the movement from the waves in the water (see for example the waves on the left) about either the height or the speed the rocket is going down? Of maybe deduce a change in velocity? Keep in mind this should actually be run at 15 frames per second.

Regards,

arnezami

[edit] Maybe it is wise that we are going to have a separate thread on the interpretation of the video besides this thread about the repair of the video.

The first picture is a marked up version of the only picture from the "alightment" of the F9S1 for the Cassiope mission.  We know that this attempt resulted in the engines failing at some point so I do not yet have any concrete understanding of how significantly the plume/water surface interaction differs from the CRS-3 return.

The second picture is (I believe) frame 188 from SwissCheese's latest Gif.  As Arnezami indicates above, the plume appears to expand from ~5 to 10m diameter at frame 169 to almost the entire width of the image at frame 188 (about 1.3s) but I don't want to hazzard a guess about the relationship to the Cassiope plume until I simulate the height of the craft at the time, the rate of descent and the throttle position.

I am sure there are many, many more people on this site that can run the fluid flow sims faster than I can (and much faster than I will have time to even attempt it)
Love your post. And your encouragement through PM's ;). That really makes it all worth it. Because all this is truly hard to do.

I think we think along the same lines here then. We'll have to see what the final verdict is after more analysis. But it's soo cool we have this video now!

Thank you SwissCheese for that!! :)

Have a nice day,

arnezami

« Last Edit: 05/20/2014 10:05 pm by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I found the missing p-frame between i-frames 150 and 169, it is just following the i-frame. Here the debug log at the end of the i-frame, the next frame is a p-frame but keeps the number 000 when it should have 001. Should we try to find the position in the ts file and hand-edit the "ghost" p-frame header?

[mpeg4 @ 03d9f020] MB pos/size: 0 000:38:29:0 22 dc: 83 84 83 84 - 129 108
[mpeg4 @ 03d9f020] MB pos/size: 0 000:39:29:0 22 dc: 81 78 81 78 - 129 108
[mpeg4 @ 03d9f020] MB pos/size: 0 000:40:29:0 22 dc: 68 65 68 65 - 129 109
[mpeg4 @ 03d9f020] MB pos/size: 0 000:41:29:0 22 dc: 54 55 54 55 - 130 107
[mpeg4 @ 03d9f020] MB pos/size: 0 000:42:29:0 22 dc: 58 73 58 73 - 131 104
[mpeg4 @ 03d9f020] MB pos/size: 0 000:43:29:0 22 dc: 79 72 79 72 - 130 104
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 10 got 9
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 10 got 11
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 6 got 12
(20 such lines in total)
[mpegts @ 0178f6a0] Continuity check failed for pid 1000 expected 5 got 6
[mpeg4 @ 03d9f020] MB pos/size: 0 000:00:00:66 96 dc: -15 0 0 0 - -9 -9, MB_type: 12296, MV: 1 -1
[mpeg4 @ 03d9f020] MB pos/size: 0 000:01:00:162 151 dc: 0 39 0 0 - 0 0, MB_type: 12296, MV: 0 0
[mpeg4 @ 03d9f020] MB pos/size: 0 000:02:00:313 109 dc: 27 0 -9 0 - 0 0, MB_type: 12296, MV: 16 5
[mpeg4 @ 03d9f020] MB pos/size: 0 000:03:00:422 159 dc: 0 33 -9 -21 - 0 0, MB_type: 12296, MV: -6 2
[mpeg4 @ 03d9f020] MB pos/size: 0 000:04:00:581 239 dc: 123 116 111 112 - 144 122, MB_type: 1, MV: 0 0
[mpeg4 @ 03d9f020] MB pos/size: 0 000:05:00:820 47 dc: 0 0 0 0 - 0 0, MB_type: 12296, MV: 22 9
Very interesting.

Maybe somebody can take a look at this. And/or maybe fix it.

Since it is the first P-frame after the I-frame it's quite important ;)

Tags:
 

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