I have seen in some forums that people is trying to improve the video by fixing the TSHs.This doesn’t hurt, but it will not improve the video, because while TSHs are easy to fix, a bad TSH indicates that probably several bits in the neighborhood are also bad. And those are the critical ones, and video won’t improve until you fix them all.As mentioned previously, an error rate higher than 1/50,000 is impossible to fix. And if you have bad TSHs you probably have an order of magnitude more errors than that in the neighborhood.
Also, for completeness, this guy commented on the wiki page but has not posted in this thread:http://aeroquartet.com/wordpress/2014/05/08/spacex-falcon-first-stage-landing-part-ii/Seems to know his stuff. From his page, QuoteI have seen in some forums that people is trying to improve the video by fixing the TSHs.This doesn’t hurt, but it will not improve the video, because while TSHs are easy to fix, a bad TSH indicates that probably several bits in the neighborhood are also bad. And those are the critical ones, and video won’t improve until you fix them all.As mentioned previously, an error rate higher than 1/50,000 is impossible to fix. And if you have bad TSHs you probably have an order of magnitude more errors than that in the neighborhood.Sound's pretty pessimistic to me :/
I’ve been repairing videos full time for the last 7 years, so I immediately knew that the bitstream was corrupt and that at best we could hope to partially fix some frames. Maybe a 50% chance of recovering one or two frames.
Here's what I have so far. It's about 2-3 seconds of video almost up to splashdown:[youtube]<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/CxheyOUAlG8"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/CxheyOUAlG8" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>[/youtube]
My meager contribution for iframe 100:3:8818,0:4:11564This reveals another two rows of blocks showing sea spray, but corrupts the rest of the image in a way that I haven't figured out how to fix. Help me SwissCheese, you're my only hope!Fantastic effort everyone.
Here is a give comparing IF5 and IF8,legs lookl like they are not yet in their final position.Created with via Imgflip GIF Maker
My 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.
I think he's referring to restoring it to 100% working video. If he wasn't, we already vastly beat his predictions. Not sure whether to trust his posts or not. Either that or his experience isn't as much as he claims it is as I'm apparently doing better than him with 1 week of experience and possibly superior tools.
More work on iframe8. Will post the mmb later.
Quote from: mlindner on 05/09/2014 01:31 pmMy 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.
Quote from: mlindner on 05/09/2014 02:55 pmQuote from: mlindner on 05/09/2014 01:31 pmMy 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.Also the Postion in the Video suggest that interpretation:iFrame2 at 1146612iFrame3 (which probably is no iFrame) at 1207712iFrame 4 at 1446284all other iFrames are also separeted by around 300000 bits.Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3. Cheers,Shanuson
Quote from: mlindner on 05/08/2014 03:44 pmMore work on iframe8. Will post the mmb later.Did you ever post the mmb for this?
Quote from: Shanuson on 05/09/2014 03:45 pmQuote from: mlindner on 05/09/2014 02:55 pmQuote from: mlindner on 05/09/2014 01:31 pmMy 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.Also the Postion in the Video suggest that interpretation:iFrame2 at 1146612iFrame3 (which probably is no iFrame) at 1207712iFrame 4 at 1446284all other iFrames are also separeted by around 300000 bits.Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3. Cheers,ShanusonI do not know for the beginning, but for iframe 6 the blocks are "heavier" (more bits) than in the other iframes. The file is roughly twice larger than the other ones.
I am approaching it from a post-processing standpoint, so use ffmpeg to create a PNG, then consume the PNG with a separate application. My biggest limitation here is that the output has to go to file (due to image2 spec), so I have it writing to a ramdisk. Is there any way to have to write PNG data to stdout instead?
The first thing that went though my head when I read about the ORBCOMM launch delay was "this means the video folks will get a few extra days to get their clean version of a landing done before SpaceX has new video."
Quote from: SwissCheese on 05/09/2014 04:07 pmQuote from: Shanuson on 05/09/2014 03:45 pmQuote from: mlindner on 05/09/2014 02:55 pmQuote from: mlindner on 05/09/2014 01:31 pmMy 2 cents on frame 3. Because of how garbled it is, its possible that the corruption is not in the data itself but in the frame header. The iframe header has lots of specifications that define how even numbers are defined (whether to use reversible or non-reversible codings). That would cause the entire frame to be decoded wrong.Edit: Just checked, yeah the frame header is corrupted. If we fix it, large parts of the image may pop out. Other frames may also have corrupted headers but not bad enough to block header decoding. This would result in odd settings for the image still though.I've been doing some inspection of the transport stream and iframe3 in a hex editor. iframe3 bears no resemblance to any other iframe in its data content. I don't think its actually an iframe or even a fame. I think the decoder got confused and tried to extract the data as an iframe. There are indeed 13 iframes though, we're just not extracting the first one for whatever reason.Also the Postion in the Video suggest that interpretation:iFrame2 at 1146612iFrame3 (which probably is no iFrame) at 1207712iFrame 4 at 1446284all other iFrames are also separeted by around 300000 bits.Exceptions: between IF 6 and 7 it is twice as much, Are we sure there is no Iframe between these 2?Also IF1 is at 847880. Could this mean there are 3 more iframes before that? 85/30 is ~ 3. Cheers,ShanusonI do not know for the beginning, but for iframe 6 the blocks are "heavier" (more bits) than in the other iframes. The file is roughly twice larger than the other ones.I have the feeling that there is at least two additional iframes before IF1. In the original video there is a section of the rocket surrounded by clouds, with no sea visible.
0x000001B0 = visual_object_sequence_start_code0x03 = profile and level indication0x000001B5 = visual_object_start_code
Further investigation.I think there is only a single iframe not being decoded. I found all the relevant frame headers and everything at 0x03E3EC position in the file.0x000001B0 = visual_object_sequence_start_code0x03 = profile and level indication0x000001B5 = visual_object_start_codeThere are exactly 13 of these patterns in this sequence in the transport stream. I did some copy and paste searching of the starts of the various iframe file dumps and each one lines up to one of these code sets. Importantly, we entirely skip the first set of these codes. The first iframe is the second set of these. I'm trying to figure out why its not decoding, but not there yet.We also need to somehow disable iframe3 from being used as that will screw up any video that could possibly be correct that would otherwise reference iframe2.
1 33 19:35:03.6 2 53 19:35:04.? 3 57 ? 4 73 19:35:??.? 5 93 19:35:07.6 6 113 19:35:08.9 7 150 ? 8 169 19:35:12.9 9 188 19:35:14.310 207 19:35:??.?11 227 19:35:1?.?12 246 19:35:18.2
1 33 19:35:03.6 2 53 19:35:04.9 3 57 ? 4 73 19:35:06.3 5 93 19:35:07.6 6 113 19:35:08.9 7 150 ? 8 169 19:35:12.9 9 188 19:35:14.310 207 19:35:15.611 227 19:35:16.912 246 19:35:18.2
2 53 19:35:04.9-3 ?? 19:35:05.1 4 73 19:35:06.3 5 93 19:35:07.6 6 113 19:35:08.9-7a 13? 19:35:10.2-7b 150 19:35:11.5 8 169 19:35:12.9
So I could align better iframe 5 (coerced.ts) with the other ones and add a few sequences, still room for improvement.We clearly see that the legs are not completely deployed!0:0:550,14:0:-1,0:5:9736,26:7:-1,4:10:22722,25:12:32001,28:12:-1,16:13:-1:0:-25:0:0,17:13:-1:-15:0:0:0,19:13:34518,10:14:-1,17:14:39053,24:14:-1,21:15:-1:-25:-10,22:15:-1,34:15:42349,24:16:-1,27:16:47754,42:19:-1,43:19:69441,43:20:-1,01:21:76873,11:22:-1,12:22:85489,26:22:-1,17:23:91682,22:24:-1,23:24:97869,00:27:-1,16:27:109631,24:27:-1,25:27:110437,28:28:-1,3:29:124970
Here's the current iframe frame numbers and timestamps as best as I can make them out: 1 33 19:35:03.6 2 53 19:35:04.? 3 57 ? 4 73 19:35:??.? 5 93 19:35:07.6 6 113 19:35:08.9 7 150 ? 8 169 19:35:12.9 9 188 19:35:14.310 207 19:35:??.?11 227 19:35:1?.?12 246 19:35:18.2Assuming a few of the sequences are contiguous, we can reconstruct some timestamps. 1 33 19:35:03.6 2 53 19:35:04.9 3 57 ? 4 73 19:35:06.3 5 93 19:35:07.6 6 113 19:35:08.9 7 150 ? 8 169 19:35:12.9 9 188 19:35:14.310 207 19:35:15.611 227 19:35:16.912 246 19:35:18.2So, here are the gaps: 2 53 19:35:04.9-3 ?? 19:35:05.1 4 73 19:35:06.3 5 93 19:35:07.6 6 113 19:35:08.9-7a 13? 19:35:10.2-7b 150 19:35:11.5 8 169 19:35:12.9It's possible the data for iframe 3 isn't even in the stream. We are clearly missing some p and b frames too.
I am not a video specialist but looking at these timestamps there is ~1.3 seconds difference between each I frame so most likely there should be no I frame between frame 2 and 4.
2 53 19:35:04.9-3 does not exist 4 73 19:35:06.3 5 93 19:35:07.6 6 113 19:35:08.9-7a 13? 19:35:10.2-7b 150 19:35:11.5 8 169 19:35:12.9