I updated http://spacexlanding.wikispaces.com/Frames+169-188
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.
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:20where 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:20In 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?
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.
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
Quote from: arnezami on 05/20/2014 07:08 pm2. 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 have two questions for the rocket experts! 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.
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
Quote from: SwissCheese on 05/20/2014 04:09 pmI 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...)Quote from: arnezami on 05/20/2014 07:08 pmI have two questions for the rocket experts! 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)
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