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

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1620 on: 06/17/2014 11:36 am »
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...).

Meanwhile I made a gif animation of the p-frame alignment process (with frame 111) which could maybe be added to the progress report.

Edit: small corrections
« Last Edit: 06/17/2014 04:25 pm by SwissCheese »

Offline Lourens

  • Full Member
  • *
  • Posts: 156
  • The Netherlands
  • Liked: 206
  • Likes Given: 304
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1621 on: 06/17/2014 11:39 am »
I agree, that is really quite incredible! Has anyone looked yet at the motion vectors in the P-frames? It looks like there's some improvement to be had there still.

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1622 on: 06/17/2014 12:31 pm »
I agree, that is really quite incredible! Has anyone looked yet at the motion vectors in the P-frames? It looks like there's some improvement to be had there still.

Yes, but the best we can do now when we find an error with a motion vector is to discard the full macroblock.

Offline moralec

Great progress guys!! Almost all frames have now been fixed...

Just to check: Is anybody working on Parts 1 and 2?  Those are the only ones that remain untouched....

It looks like we are getting closer to the limits of the MMB approach. Any new ideas on how to continue moving forward?  I'm guessing that princess and others are still working on the triple bit flips... any help you guys need with that? Or what other things we should begin consider? Traditional Image correction? Interpolation of frames?

By the way, looking at the latest video I think we are going to need to add the clock fixes for frames 168-180. In the latest you tube version, the clock stays at 19:35:8 for two seconds and then jumps to 19:35:10 (Check from 0:07 to  0:10 in the video)

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1624 on: 06/17/2014 04:11 pm »
Great progress guys!! Almost all frames have now been fixed...

Just to check: Is anybody working on Parts 1 and 2?  Those are the only ones that remain untouched....

It looks like we are getting closer to the limits of the MMB approach. Any new ideas on how to continue moving forward?  I'm guessing that princess and others are still working on the triple bit flips... any help you guys need with that? Or what other things we should begin consider? Traditional Image correction? Interpolation of frames?

By the way, looking at the latest video I think we are going to need to add the clock fixes for frames 168-180. In the latest you tube version, the clock stays at 19:35:8 for two seconds and then jumps to 19:35:10 (Check from 0:07 to  0:10 in the video)

I had a look at parts 1 and 2, there are very few good data sequences until frame 28; from this point on, the data are OK. But it does not make too much sense to spend time on these p-frames when there is no i-frame...

Online Chris Bergin

Great stuff, so are we getting to the point where we call this as best that can be done? I note moralec's post of course, but it seems we're very close.
« Last Edit: 06/17/2014 04:19 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 mhenderson

  • Member
  • Posts: 71
  • USA
  • Liked: 101
  • Likes Given: 18
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1626 on: 06/17/2014 04:59 pm »
Great progress guys!! Almost all frames have now been fixed...

Just to check: Is anybody working on Parts 1 and 2?  Those are the only ones that remain untouched....

It looks like we are getting closer to the limits of the MMB approach. Any new ideas on how to continue moving forward?  I'm guessing that princess and others are still working on the triple bit flips... any help you guys need with that? Or what other things we should begin consider? Traditional Image correction? Interpolation of frames?

By the way, looking at the latest video I think we are going to need to add the clock fixes for frames 168-180. In the latest you tube version, the clock stays at 19:35:8 for two seconds and then jumps to 19:35:10 (Check from 0:07 to  0:10 in the video)

I believe that @Wronkiew is (correctly) applying a "99.9% certainty" rule to clock fixes. This is a 'restore vs enhance' issue. I also believe that the clock MBs are badly corrupted in that region. There is no way to visually tell precisely when :08 becomes :09 so he left it alone.

Another complicating factor - the 15 FPS frame rate does not align cleanly with hundredths of a second. This limits the ability to overlay timestamps with absolute precision, so @Wronkiew is not "enhancing" with a best guess.

An argument could be made for using the clock in the TS header (@princess mentioned it, I think) to map frames to a timestamp. That TS counter is not an extrapolation; it is hard evidence - just not from visual MB information.

Yes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.



Offline cscott

  • Senior Member
  • *****
  • Posts: 3471
  • Liked: 2867
  • Likes Given: 726
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1627 on: 06/17/2014 05:29 pm »
Yes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.

This is another test case for automatic triple flip detection.  I wish I had more time to work on this myself!  But here we have a fairly good idea of exactly what the clock should look like, so it should be possible to turn loose an automatic tool that looked for the best set of triple flips that gives the expected output.

Offline princess

  • Member
  • Posts: 65
  • Liked: 106
  • Likes Given: 25
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1628 on: 06/17/2014 05:54 pm »
An argument could be made for using the clock in the TS header (@princess mentioned it, I think) to map frames to a timestamp. That TS counter is not an extrapolation; it is hard evidence - just not from visual MB information.

If anyone needs the TS timestamps for each frame, I've included them here. First column is frame number, second column is time in seconds after the start of the recording (note that we don't have the start):


1 62.907178
2 62.973911
3 63.040644
4 63.107378
5 63.174111
6 63.240844
7 63.307578
8 63.374311
9 63.441044
10 63.507778
11 63.574511
12 63.641244
13 63.707978
14 63.774711
15 63.841444
16 63.908178
17 63.974911
18 64.041644
19 64.108378
20 64.175111
21 64.241844
22 64.308578
23 64.375311
24 64.442044
25 64.508778
26 64.575511
27 64.642244
28 64.708978
29 64.775711
30 64.842444
31 64.909178
32 64.975911
33 65.042644
34 65.109378
35 65.176111
36 65.242844
37 65.309578
38 65.376311
39 65.443044
40 65.509778
41 65.576511
42 65.643244
43 65.709978
44 65.776711
45 65.843444
46 65.910178
47 65.976911
48 66.043644
49 66.110378
50 66.177111
51 66.243844
52 66.310578
53 66.377311
54 66.444044
55 66.510778
56 66.577511
57 66.644244
58 66.710978
59 66.777711
60 66.844444
61 66.911178
62 66.977911
63 67.044644
64 67.111378
65 67.178111
66 67.244844
67 67.311578
68 67.378311
69 67.445044
70 67.511778
71 67.578511
72 67.645244
73 67.711978
74 67.778711
75 67.845444
76 67.912178
77 67.978911
78 68.045644
79 68.112378
80 68.179111
81 68.245844
82 68.312578
83 68.379311
84 68.446044
85 68.512778
86 68.579511
87 68.646244
88 68.712978
89 68.779711
90 68.846444
91 68.913178
92 68.979911
93 69.046644
94 69.113378
95 69.180111
96 69.246844
97 69.313578
98 69.380311
99 69.447044
100 69.513778
101 69.580511
102 69.647244
103 69.713978
104 69.780711
105 69.847444
106 69.914178
107 69.980911
108 70.047644
109 70.114378
110 70.181111
111 70.247844
112 70.314578
113 70.381311
114 70.448044
115 70.514778
116 70.581511
117 70.648244
118 70.714978
119 70.781711
120 70.848444
121 70.915178
122 70.981911
123 71.048644
124 71.115378
125 71.182111
126 71.248844
127 71.315578
128 71.382311
129 71.449044
130 71.515778
131 71.582511
132 71.649244
133 71.715978
134 71.782711
135 71.849444
136 71.916178
137 71.982911
138 72.049644
139 72.116378
140 72.183111
141 72.249844
142 72.316578
143 72.383311
144 72.450044
145 72.516778
146 72.583511
147 72.650244
148 72.716978
149 72.783711
150 72.850444
151 72.917178
152 72.983911
153 73.050644
154 73.117378
155 73.184111
156 73.250844
157 73.317578
158 73.384311
159 73.451044
160 73.517778
161 73.584511
162 73.651244
163 73.717978
164 73.784711
165 73.851444
166 73.918178
167 73.984911
168 74.051644
169 74.118378
170 74.185111
171 74.251844
172 74.318578
173 74.385311
174 74.452044
175 74.518778
176 74.585511
177 74.652244
178 74.718978
179 74.785711
180 74.852444
181 74.919178
182 74.985911
183 75.052644
184 75.119378
185 75.186111
186 75.252844
187 75.319578
188 75.386311
189 75.453044
190 75.519778
191 75.586511
192 75.653244
193 75.719978
194 75.786711
195 75.853444
196 75.920178
197 75.986911
198 76.053644
199 76.120378
200 76.187111
201 76.253844
202 76.320578
203 76.387311
204 76.454044
205 76.520778
206 76.587511
207 76.654244
208 76.720978
209 76.787711
210 76.854444
211 76.921178
212 76.987911
213 77.054644
214 77.121378
215 77.188111
216 77.254844
217 77.321578
218 77.388311
219 77.455044
220 77.521778
221 77.588511
222 77.655244
223 77.721978
224 77.788711
225 77.855444
226 77.922178
227 77.988911
228 78.055644
229 78.122378
230 78.189111
231 78.255844
232 78.322578
233 78.389311
234 78.456044
235 78.522778
236 78.589511
237 78.656244
238 78.722978
239 78.789711
240 78.856444
241 78.923178
242 78.989911
243 79.056644
244 79.123378
245 79.190111
246 79.256844
247 79.323578
248 79.390311
249 79.457044
250 79.523778
251 79.590511
252 79.657244
253 79.723978
254 79.790711
255 79.857444
256 79.924178
257 79.990911
258 80.057644
259 80.124378
260 80.191111
261 80.257844
262 80.324578
263 80.391311
264 80.458044
265 80.524778
266 80.591511
267 80.658244
268 80.724978
269 80.791711
270 80.858444
271 80.925178
272 80.991911
273 81.058644
274 81.125378
275 81.192111
276 81.258844
277 81.325578
278 81.392311
279 81.459044
280 81.525778
281 81.592511
282 81.659244
283 81.725978

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 #1629 on: 06/17/2014 05:58 pm »
Yes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.

This is another test case for automatic triple flip detection.  I wish I had more time to work on this myself!  But here we have a fairly good idea of exactly what the clock should look like, so it should be possible to turn loose an automatic tool that looked for the best set of triple flips that gives the expected output.

As was pointed out earlier by those more familiar with packet issues, a big problem with the clock is that the data is just not there. We would need to fix the packets and update the .ts files.

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 #1630 on: 06/17/2014 06:09 pm »
Great progress guys!! Almost all frames have now been fixed...

Just to check: Is anybody working on Parts 1 and 2?  Those are the only ones that remain untouched....

It looks like we are getting closer to the limits of the MMB approach. Any new ideas on how to continue moving forward?  I'm guessing that princess and others are still working on the triple bit flips... any help you guys need with that? Or what other things we should begin consider? Traditional Image correction? Interpolation of frames?

By the way, looking at the latest video I think we are going to need to add the clock fixes for frames 168-180. In the latest you tube version, the clock stays at 19:35:8 for two seconds and then jumps to 19:35:10 (Check from 0:07 to  0:10 in the video)

It sounds like you're looking for a project to do! I have clock fixes for 161-167, but I haven't gotten to 168-180 yet.

I recently put together a new script that generates erase commands. This makes fixing the clock a lot easier. You'll need a php interpreter that has the GD functions included to run it. I attached the script and an example mask image. You run "php -f mask_to_erase.php mask-051.png", and it outputs a list of commands that you can copy into the clockfix file.

Offline moralec

An argument could be made for using the clock in the TS header (@princess mentioned it, I think) to map frames to a timestamp. That TS counter is not an extrapolation; it is hard evidence - just not from visual MB information.

Yes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.

I support  the idea of restrincting the modifications to hard evidence. But we don't need to be confided to visual MB information. If we are sure that the TS header info is fine, why not using it? :)
« Last Edit: 06/17/2014 06:56 pm by moralec »

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 #1632 on: 06/17/2014 06:42 pm »
The MPEG timestamps may be useful for recovering some frames. Just keep in mind that each frame displays two different times. You'll also need to synchronize the clocks to millisecond precision at least.

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1633 on: 06/17/2014 08:40 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.
« Last Edit: 06/17/2014 09:00 pm by saliva_sweet »

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.

You want me to do what?

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1635 on: 06/17/2014 08:50 pm »
You want me to do what?
Add iframes converted to pframes to the online editor so mmbs for them could be better edited. They are mpg4-img files, which I would provide. Not sure how your setup works currently.

edit: They should probably be separate from the main final_fixed.ts frames like there used to be several selecable ts versions earlier. Would that be possible?
« Last Edit: 06/17/2014 08:57 pm by saliva_sweet »

You want me to do what?
Add iframes converted to pframes to the online editor so mmbs for them could be better edited. They are mpg4-img files, which I would provide. Not sure how your setup works currently.

edit: They should probably be separate from the main final_fixed.ts frames like there used to be several selecable ts versions earlier. Would that be possible?

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

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1637 on: 06/17/2014 09:31 pm »
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.

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1638 on: 06/17/2014 11:35 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... And what about the frames following the one you converted? Do they also inherit the data?

Offline saliva_sweet

  • Full Member
  • ****
  • Posts: 614
  • Liked: 476
  • Likes Given: 1826
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1639 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 »

Tags:
 

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