I asked Doug Ellison, the JPL guy who did the MSL descent video, if he had any tips
Just a question: Is anybody collecting/monitoring the progress on this task? As several of you are working on parallel, I believe a monitoring tool would be useful in order to lower the risk of having several individuals doing the same thing. To start, may I suggest on keeping a table like the one originally describing the I-Frames (http://forum.nasaspaceflight.com/index.php?topic=34597.msg1193316#msg1193316) in order for everyone to know who is working on each one?
mlindner was asking for a non-corrupted image, so this one comes from the reentry burn of Cassiope launch
I updated my Transport stream tool. It's probably not going to help much at this point but it does have a hex editor and powerful search feature with a bit level wildcard filter, ability to return results with a specified tolerated number of single bit errors and the results are easy to visualize and locate. To do:Disable controls until a ts file is opened. Make the search capable of finding results that are not byte aligned. Add a replace feature with a wildcard filter.Enable bit level insertion and deletion ability. (would bit shift everything after that point in the file)I think its a good companion tool for this transport stream editor. http://www.videohelp.com/tools/TS-Packet-Editor
I feel like we're missing an important piece of this puzzle. Was the video data stream was on it's own channel, or there was other data being transmitted on the same channel with some other controls in place to keep the data segregated? If it was on it's own channel, having an analogue(time domain) copy of the original transmission, perhaps even with time code synced to the video file provided, there might be a lot more that could be done to extract the information. Having the the time domain data stream it would also be much easier to tell where and when data was dropping out.
Ive added 2 features to https://github.com/michaelni/FFmpeg/tree/spacexdebug1first, you can now use syntax like -mmb 40:03:-1to fill the image with "blank" blocks starting from 40:03 and until the next specified commandand-mmb X:20009:1Bto xor 0x1B at bit position 20009 of the frame, that is this allows to flip some bits without the need to edit the file(atm this is limited to max 8bit per command)
Quote from: moralec on 05/05/2014 05:56 pmJust a question: Is anybody collecting/monitoring the progress on this task? As several of you are working on parallel, I believe a monitoring tool would be useful in order to lower the risk of having several individuals doing the same thing. To start, may I suggest on keeping a table like the one originally describing the I-Frames (http://forum.nasaspaceflight.com/index.php?topic=34597.msg1193316#msg1193316) in order for everyone to know who is working on each one? There is wiki at http://spacexlanding.wikispaces.com/ with current state of affairs.
Do you have something that's not for windows?Also, a tool that could search by bits rather than hex would be even more helpful. Hardly anything in these video blocks appears to be byte aligned so hex searching doesn't help much.
The video seems simple profile level 3 mpeg4 video in mpeg TS.It seems none of the error resilience features of mpeg4 have been used when encoding it. Which is a pitty, had slices been used then the decoder could resume decoding of a frame at the next slice start, had data partitioning been used then the more important low resolution information and motion vectors would have been coded first in each slice making errors less likely to damage them. And had rvlcs been used then slices could have been decoded from both the start and end again, limiting the impact of bit errors.I know nothing about how the video was generated or how it was transmitted, but if there was some FEC in there then then it should be possible in principle to re-run FEC decoding after manual fixing up all mpeg-TS and mpeg4-ES headers. And as such manual fixing would decrease the errors, FEC would then have fewer errors to deal with and might in a few rare cases be able to fix a few more errors.Also if some kind of CRCs have been used, CRCs can also be used to correct bit errors as long as the number of errors is sufficiently small, which each CRC would need to correct, the exact number that could be corrected that way depends on the packet size and crc polynomial being used.
Quote from: michaelni on 05/06/2014 01:01 amIve added 2 features to https://github.com/michaelni/FFmpeg/tree/spacexdebug1first, you can now use syntax like -mmb 40:03:-1to fill the image with "blank" blocks starting from 40:03 and until the next specified commandand-mmb X:20009:1Bto xor 0x1B at bit position 20009 of the frame, that is this allows to flip some bits without the need to edit the file(atm this is limited to max 8bit per command)Added another feature, now you can adjust DC values of the blank blockseach MB has 6 blocks 4 luma and 2 chromaexample to adjust the 4th luma DC of (blank) MB 40:3 by +100-mmb 40:03:-1:0:0:0:100:0:0
Quote from: michaelni on 05/06/2014 02:03 amAdded another feature, now you can adjust DC values of the blank blockseach MB has 6 blocks 4 luma and 2 chromaexample to adjust the 4th luma DC of (blank) MB 40:3 by +100-mmb 40:03:-1:0:0:0:100:0:0Can you explain more how to use this feature and what it does and why its useful? We're getting really far down in the trenches here.
Added another feature, now you can adjust DC values of the blank blockseach MB has 6 blocks 4 luma and 2 chromaexample to adjust the 4th luma DC of (blank) MB 40:3 by +100-mmb 40:03:-1:0:0:0:100:0:0
I think I got a bit more of iframe 8, hard to tell what the correct alignment is.ffmpeg -mmb 07:14:17233,14:14:57111,08:15:17233,09:15:63546,19:16:17233,21:16:73568,08:21:17233,00:22:111664 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_8.mpg4-img -f image2 img-%03d.png
In order to fix this you could try to restore the bitstream itself. But this is very hard to do and extremely time consuming (fixing compressed data is no joke!). The worse is: you don't know when the bad bits stop.
Quote from: arnezami on 05/05/2014 04:53 amIn order to fix this you could try to restore the bitstream itself. But this is very hard to do and extremely time consuming (fixing compressed data is no joke!). The worse is: you don't know when the bad bits stop.If data errors are random, if garbled bits are not occurring in bursts, but randomly, then fixing garbled block entails inverting one bit and looking whether image got better in the block and after it. If it got worse, you inverted a "good" bit. If it got better, you inverted a corrupted one.Thankfully, there aren't than many bits in, say, 32 bytes - only 256.