If the data is just not there (like those ffff's), then no recovery is possible, right?
No, it is the *data* that has been recovered. (although they did find some pieces)
Quote from: StephenB on 04/30/2014 07:59 pmIf the data is just not there (like those ffff's), then no recovery is possible, right?Well, some data could be transferred from known good images from the same camera as far as the fixed part of the image (rocket body) goes. Beyond that, it would require some imagination and frame-by-frame touching up. It would be partially fiction at that point...If there only were some additional fully intact frames, a bunch of damaged ones between them could be interpolated but that just isn't there I think.
Which means, IMO, they should rotate the image 90 degrees between successive key frames, as far as the compression is concerned.
4703e8: 15,014 times471fff: 4,966 times4743e8: 263 times474000: 81 times474020: 74 times
Hi guys,Today I have done a low-level analysis of the raw.ts file. Most notably the "Transport Stream Headers" (see http://en.wikipedia.org/wiki/MPEG_transport_stream )While it is bad, its not as bad as is being suggested above. The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:4703e8: 15,014 times471fff: 4,966 times4743e8: 263 times474000: 81 times474020: 74 timesThe actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data. The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".The other correct packets are basicly overhead. I will not go into them. But they are essential for the video working. There are a lot more than shown above btw.The problem lies in the remaining bad headers (still several thousand): they get ignored by the video-player which causes it to act strangely. Also: a lot of bits (not just in the header but also in the content) are flipped. But my hope is that this is not the biggest issue: mpeg-4 is quite resilient.I'm trying to figure out if I can "repair" most of the headers so the video player can at least decide what to do with the data in it (now it will just ignore it because they have the wrong PID, invalidating valid packets in the meantime). This however is no simple task. Fingers crossed.Regards,arnezami
While it is bad, its not as bad as is being suggested above. The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:4703e8: 15,014 times471fff: 4,966 times4743e8: 263 times474000: 81 times474020: 74 timesThe actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data. The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".