Amazing work guys. We could have used you when we tried to get some footage down from the ET "Death Cam"!http://www.nasaspaceflight.com/2011/07/sts-135-et-camera-ascent-no-usable-video-reentry/
I dont know how one could extract that shifted frame, hexeditors do not allow to insert only 4 bits, always wants to add a byte.
#!/usr/bin/perlopen(IN, "< bitshiftframe") or die; binmode(IN); $/=undef;$iframe = <IN>;$hex = substr(unpack('H*', $iframe), 1);open(OUT, "> shanusons-bitshifted.ts") or die; binmode(OUT);print(OUT pack('H*', $hex));
Quote from: Shanuson on 05/10/2014 12:17 amI dont know how one could extract that shifted frame, hexeditors do not allow to insert only 4 bits, always wants to add a byte.It should be pretty straightforward in Perl with unpack/pack. Just unpack with H*, then pack substr($str, 1) back to H. I'll take a look.PS: where did you get your try1.ts file? The one I pulled from the very bottom of the wikspaces.com page has IF01 which you list at 0x3E429 showing up in my bvi session starting at 0x3E3DB, a 30-byte offset to the left. I'll pad it out at the beginning to make it line up with your numbers, but I want to make sure we're on the same page.
Well, looks like we're not getting any new video anytime soon. SpaceX has scrubbed the launch for tomorrow, and pushed it back to "later this month".
There's a bigger issue is that when edited.ts and try1.ts were created they had "fixed" the transport stream headers by adding the 4 byte headers to them every 188 bytes throughout the stream. If you simply shift the bytes at the moment then all the transport stream headers will become unaligned again not to mention effectively being corruption every 188 bytes. It might be better to re-apply the processes that were done on raw.ts again and produce a new transport stream. Preferably in script form this time so that if something else is found they can quickly be re-applied.
Ok, first try at auto-marking bad MBs based on ffmpeg log output and primitive analysis....Edit: Here's the Java source if anyone else wants to play. http://pastebin.com/bKgzCRqD The mammoth inner class at the bottom is for writing the animated gif
Quote from: cscott on 05/09/2014 08:11 pmQuote from: mlindner on 05/09/2014 07:48 pmI think the first iframe is a lost cause.Perhaps you could turn your attention to the missing iframe "7a"? Maybe there's a bit flipped somewhere which is causing your search for 0x000001B0 / 0x03 / 0x000001B5 not to turn it up? (I'm assuming the existing iframe 7 is "7b" based on the timestamp image, someone correct me if i'm wrong.)Not sure how long it would take to brute-force through the file in the area of concern (from pos 2054276 to 2940884), performing a bit-flip at each bit along the way and performing a search for 0x000001B0 / 0x03 / 0x000001B5 within the bits +/- the total message length. If you don't see anything, flip the bit back and move onto the next bit. When you see a new hit for 0x000001B0 / 0x03 / 0x000001B5, record the file location and then go back later to see if maybe a new iframe materializes.Frustrating because I know I used to be able to do all I said above, but I've been away from coding for too long to do it in any expedient manner.
Quote from: mlindner on 05/09/2014 07:48 pmI think the first iframe is a lost cause.Perhaps you could turn your attention to the missing iframe "7a"? Maybe there's a bit flipped somewhere which is causing your search for 0x000001B0 / 0x03 / 0x000001B5 not to turn it up? (I'm assuming the existing iframe 7 is "7b" based on the timestamp image, someone correct me if i'm wrong.)
I think the first iframe is a lost cause.
Quote from: theshadow27 on 05/09/2014 06:13 pmOk, first try at auto-marking bad MBs based on ffmpeg log output and primitive analysis....Edit: Here's the Java source if anyone else wants to play. http://pastebin.com/bKgzCRqD The mammoth inner class at the bottom is for writing the animated gif Great stuff!!One suggestion: when comparing a block with other block its best to only compare it with the one above and the one to the left. This is because of how mpeg-4 works: the current block will directly affect the one below and the one to the right. So you are really comparing to yourself in a way. Also: if the current block is defect (or one until the one below is reached) it is very likely the block below is bit-shifted so you're not comparing the current block to what is supposed to be below it. Keep that in mind.Regards,arnezami
Quote from: arnezami on 05/10/2014 04:55 amQuote from: theshadow27 on 05/09/2014 06:13 pmOk, first try at auto-marking bad MBs based on ffmpeg log output and primitive analysis....Edit: Here's the Java source if anyone else wants to play. http://pastebin.com/bKgzCRqD The mammoth inner class at the bottom is for writing the animated gif Great stuff!!One suggestion: when comparing a block with other block its best to only compare it with the one above and the one to the left. This is because of how mpeg-4 works: the current block will directly affect the one below and the one to the right. So you are really comparing to yourself in a way. Also: if the current block is defect (or one until the one below is reached) it is very likely the block below is bit-shifted so you're not comparing the current block to what is supposed to be below it. Keep that in mind.Regards,arnezamiHmm ok so it is pointless to try manipulation in blocks past the first bad block? Basically we need to completely fix one bad block at a time?