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

Offline SwissCheese

  • Full Member
  • *
  • Posts: 164
  • Liked: 249
  • Likes Given: 90
I-Frame 6

Looks like the RHS Leg is being deployed with the LHS leg already locked in position.

Needs a lot more work to be more certain.

0:0:583,43:0:5530,
00:01:6129,02:01:6129,21:1:8584,22:1:8796,
4:3:12577,14:3:19199,15:03:-1,18:03:19433,20:3:14083,23:3:14220,42:3:21474,
0:04:-1,31:04:24629,32:4:15280,
6:5:17702,7:5:-1,13:05:27662,14:05:-1,42:0:5530,17:05:28599,18:5:13888,24:05:-1,25:05:29375,
28:7:40520,29:7:40520,32:07:-1,37:07:41235,
1:8:37105,
1:9:37105,
26:10:61670,27:10:40399,
17:11:64694,
0:13:56967'
0:16:71551,1:10:11678,
1:11:11678,
5:12:12185,18:12:58656,
07:13:-1,13:13:60221,14:13:13373,15:13:60221,
19:14:59308,
12:15:72126,
0:17:71551,2:17:71610,
0:18:71551,7:18:72226,
0:19:121762,
1:28:202509

Please note the solution from Gnonthgol in http://spacexlanding.wikispaces.com/ (did not find his post):

0:0:583,
39:0:5496,43:0:-1,
02:01:6129,
21:1:8584,
22:1:8796,6:3:-1,
02:06:29800,2:8:-1,
12:10:46767,00:11:-1,
3:12:56455,18:12:-1,
26:12:61670,27:12:-1,
17:13:64694,28:12:-1,
32:13:71022,4:14:-1,
27:14:78837,5:15:-1,
19:15:92898,23:15:-1,
27:17:107825,27:18:-1,
0:19:121762,04:21:-1,
31:22:159772,0:24:-1,
30:25:184570,07:27:-1,
35:27:200466

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1953
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 546
  • Likes Given: 226
Here's the new try1-fixed.ts Iframe3 has been converted to a b-frame.

Edit: It apparently doesn't decode at all now though. It obviously wasn't an I-frame though. We should probably remove I-frame 3 from the wiki.
« Last Edit: 05/09/2014 09:18 PM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline mvpel

  • Full Member
  • ****
  • Posts: 1124
  • New Hampshire
  • Liked: 1295
  • Likes Given: 1686
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline James (Lockheed)

  • Veteran
  • Full Member
  • ****
  • Posts: 595
  • Huntsville
  • Liked: 37
  • Likes Given: 2
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/

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1953
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 546
  • Likes Given: 226
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/

Wasn't that analog? Analog = black magic.

Edit: Yeah. Analog NTSC over FM radio. If you don't have an SDR recording of it there's nothing better you'll be able to process it into AFAIK.
« Last Edit: 05/09/2014 11:01 PM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Online Shanuson

  • Full Member
  • **
  • Posts: 282
  • Liked: 197
  • Likes Given: 499
Ok, I looked into try1.ts

found the postion of an I-Frame around 0x23bdd6 in try1.ts.
most bit patterns are there, but somehow set of by 4bit (half a byte, so one does not find it easily in a hex editor) and also that is probably the reason why it is not found by the decoder. The decoder wants stuff to start at the beginning of a byte not in the middle.

A typical header part, Coloured bits are similar in I-Frame headers 2,3,4,5,6,8,9,10,11,12,13,14 (numbered not as in the wiki, but by appearance in try1.ts)
This could be due to some manual editing by someone else, have not checked how the look in other .ts files.
The position mentioned is the start of sequence 00 00 01 B6 1

IF02:  0x0CEEE9;
00 00 00 01 E0 00 00 81 80 07 21 01 67 CE 5D FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 F2 46 9A FC
7C 2E EE 2C 08 78 28 C7 00 00 01 B2 65 6D 34 76 20 34 2E 33 2E 30 2E 30 00 C3 FF 00 00 01 B6 1
4

Now Frame1 (frame0 of wiki), red are the bytes that are different to every other I-Frame
IF01:  0x03E429; 
00 00 00 01 E0 00 00 81 80 07 21 01 59 79 7D FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 A1 62 9A FC
7C 2E EE 2C 08 78 28 C7 00 00 01 B
4 7B 6D 75 76 32 34 02 27 26 5C 4E 5B 82 2A F8 00 31 30 B8 3A

Same for the frame between frame 6 and 7 of the wiki:
Also bits are shifted here by 4, compared to the ts file, therefore the .5 at the position:
IF07:  0x23BDEC.5;
40 C2 82 13 B0 01 81 8B 50 07 21 01 8D 22 8D FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 85 C0 00 46 54 80 13 40 09 EF DE 9A FE
7C 22 EE 2C 08 78 68 C2 BC 10 49 80 6C 8D 34 76 20 34 2E 33 2E 30 2E 30 00 C3 FF 00 00 01 B6 1
0

You will find those parts for all 14 I-Frames in the file attached.
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.

Edit: I should really go to bed, but found also one at the start: to tired to colour it now compared to IF2.

IF1.5: 0x085c51;
00 00 00 01 E0 00 00 81 80 07 21 01 61 23 ED FF FF 15 38 13 20 03 00 00 41 A8 8C C7 05 06 01 14 00 00 80 80 06 C4 8D C0 40 C7 D5 C0 1E D0 01 93 1D 9A FC
7C 2E EE 2D 08 7E 28 C7 C0 00 A9 B1 7D 6D 64 76 20 34 4A 32 76 30 2E 30 00 C3 7F 03 08 01 86 28
« Last Edit: 05/10/2014 12:45 AM by Shanuson »

Offline Swatch

  • Full Member
  • **
  • Posts: 273
  • Official Aerospace Engineer as of June 13th, 2009
  • Cincinnati
    • ProjectApollo/NASSP: Virtual Systems and Flight Simulation of the Apollo Program
  • Liked: 28
  • Likes Given: 16
Attempted to color them for Shanuson... not sure if I got it right, but it does show the differences...
I realize there are some 'half-hex' pairs that are identical, but I chose to color the complete hex pair if there's any discrepancy.


Shanuson's Note: Now Frame1 (frame0 of wiki), red are the bytes that are different to every other I-Frame
IF01:  0x03E429;  (POS: 255017)
00 00 00 01 E0 00 00 81 80 07 21 01 59 79 7D FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 A1 62 9A FC
7C 2E EE 2C 08 78 28 C7 00 00 01 B
4 7B 6D 75 76 32 34 02 27 26 5C 4E 5B 82 2A F8 00 31 30 B8 3A

IF1.5: 0x085c51;  (POS: 547921)
00 00 00 01 E0 00 00 81 80 07 21 01 61 23 ED FF FF 15 38 13 20 03 00 00 41 A8 8C C7 05 06 01 14 00 00 80 80 06 C4 8D C0 40 C7 D5 C0 1E D0 01 93 1D 9A FC
7C 2E EE 2D 08 7E 28 C7 C0 00 A9 B1 7D 6D 64 76 20 34 4A 32 76 30 2E 30 00 C3 7F 03 08 01 86 28

IF02:  0x0CEEE9;  (POS: 847593)
00 00 00 01 E0 00 00 81 80 07 21 01 67 CE 5D FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 F2 46 9A FC
7C 2E EE 2C 08 78 28 C7 00 00 01 B2 65 6D 34 76 20 34 2E 33 2E 30 2E 30 00 C3 FF 00 00 01 B6 14


Shanuson's Note: Also bits are shifted here by 4, compared to the ts file, therefore the .5 at the position:
IF07:  0x23BDEC.5;  (POS:  ~2342380)
40 C2 82 13 B0 01 81 8B 50 07 21 01 8D 22 8D FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 85 C0 00 46 54 80 13 40 09 EF DE 9A FE
7C 22 EE 2C 08 78 68 C2 BC 10 49 80 6C 8D 34 76 20 34 2E 33 2E 30 2E 30 00 C3 FF 00 00 01 B6 10
« Last Edit: 05/10/2014 01:32 AM by Swatch »
Ex-Rocket Scientist in Training, now Rocket Scientist!
M-F trying to make the world of the future a smaller place through expanding horizons...

Offline mvpel

  • Full Member
  • ****
  • Posts: 1124
  • New Hampshire
  • Liked: 1295
  • Likes Given: 1686
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.

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.

Edit: Ok, look taken.

Here's what I did:

1. Padded out my try1.ts to get it lined up with the offsets in header.txt, which may or may not match what I'm seeing in my hex editor, as it's late.
2. Cut out everything up to the 040 C2 82 13 B0 01 81 shifted region, and then searched for the next 00000001E000008180 marker. This marker turned out to be properly byte-aligned, as it happens. I then cut that out as well, leaving only the bit-shifted frame at 299297 bytes.
3. Quick and dirty Perl:
#!/usr/bin/perl
open(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));


This produced a byte-aligned version of 0x23BDEC.5. I attached it here as an mp4, but it's not an MP4 file - it's a straight excerpt of the bytes of interest from the try1.ts transport stream file - the TS extension is not allowed for attachments here.

Edit: removed the bitshifted ts file because the packet headers were mangled by the operation.
« Last Edit: 05/10/2014 02:01 PM by mvpel »
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1953
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 546
  • Likes Given: 226
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.

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.

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.
« Last Edit: 05/10/2014 03:25 AM by mlindner »
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline John_L

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". :(

Offline mlindner

  • Software Engineer
  • Full Member
  • ****
  • Posts: 1953
  • Space Capitalist
  • Silicon Valley, CA -- previously in Ann Arbor, MI
  • Liked: 546
  • Likes Given: 226
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". :(

More motivation for us to get the video done even better. :P
Internal combustion engine in space. It's just a Bad Idea.TM - Robotbeat

Offline Guspaz

If it does come down to needing to do automated A/B testing, and humans are needed for that evaluation, I'd like to point out that there is always Amazon's Mechanical Turk. It basically allows you to farm out this sort of effort to large numbers of people fairly cheaply. I don't think you guys are at that point yet, but there's been discussions in this thread about trying to do the testing algorithmically, so I thought I'd mention it.
« Last Edit: 05/10/2014 04:11 AM by Guspaz »

Offline mvpel

  • Full Member
  • ****
  • Posts: 1124
  • New Hampshire
  • Liked: 1295
  • Likes Given: 1686
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.
Good point - odds are that's what happened since I shifted the entire file four bits to the right. I've been heart-attack busy lately so I've resisted the temptation to learn how MPEG encoding works. I'll take a look at the resulting bitshifted file and the video coding documentation, and if you wouldn't mind doing so as well and letting me know if you're inclined. As you can see the shifting operation is straightforward in Perl so it won't be difficult to cope with the TS headers. And also perhaps set up command line arguments to shift arbitrary ranges of nybbles.

Edit: yep, there it is, right at the end: ...FF F4 71 FF F1 6F FF...  Looking at raw.ts now.

Edit: The four-bit offset is present in raw.ts as well at 0x23BD07. Coercing the TS headers in the raw.ts may have mangled things... it's extremely difficult to discern where the missing or added four bits came from, too. Hmmm... it looks like the 00-00-01-b0-03 bytes always appear exactly 28 bytes after a ts header, let's see...

In a good packet formatted to 20 columns, we see the 47 to mark the beginning of the packet, and here "D" is the sequence number (the "3" before it means "adaptation field & payload") and 28 bytes later we see the 00-00-01-B0 pattern:

00316CE4  47 43 E8 3D 07 10 00 34 5B FF 7E 00 00 00 01 E0 00 00 81 80
00316CF8  07 21 01 A3 21 DD FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00
00316D0C  00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 FD 30


In the bit-shifted one, counting 28 octets back from the "0-00-00-1B-0" we land in the middle of the marked 4D, meaning that we have four extra bits between the header and the sequence:

0023BCE8  FA A9 FF 4D BE 66 AF 8C EC B9 A7 CD C3 5C 74 0C 28 21 3B 00
0023BCFC  18 18 B5 00 72 10 18 D2 28 DF FF F0 00 00 1B 00 30 00 00 1B
0023BD10  50 D0 F0 00 00 10 00 00 00 12 00 0C 48 5C 00 04 65 48 01 34


Based on what appears to be a clean packet header above this region at showing "47-1F-FF-18," at 0x23bb74 in raw.ts, the sequence number at the marked packet header above should be "A", since it's about 2x188 bytes away from the clean header.

This reveals some interesting information as well - in raw.ts, 188 bytes after this clean header is "C0-D8-61-01" which was coerced in try1.ts to "47 83 E8 11" so the sequence number there is incorrect (1 instead of 9) due to a bit flip - "0001" instead of "1001."  This apparently means that the try1.ts file is stuffed full of continuity count errors - the coerced header just after this one has a sequence number of C when it should be A, for example. And if that was ignored, then no-increment-if-no-payload was probably also ignored.

Setting that aside... let's say that the 4D is supposed to be a 47 (0111 instead of 1110, and the sequence number is supposed to be A, and look what we have here...

0023BCE8  FA A9 FF 47 BE 66 AF 8C EC B9 A7 CD C3 5C 74 0C 28 21 3B 00
0023BCFC  18 18 B5 00 72 10 18 D2 28 DF FF F0 00 00 1B 00 30 00 00 1B
0023BD10  50 D0 F0 00 00 10 00 00 00 12 00 0C 48 5C 00 04 65 48 01 34


So thanks to Shanuson we know we're looking for something along the lines of: 00 00 00 01 E0 00 00 81 80 07 21 01 59 79 7D FF FF...

0023BCE8  FA A9 FF 47 BE 66 AF 8 CE CB 9A 7C DC 35 C7 40 C2 82 13 B0 01
0023BCFC  81 8B 50 07 21 01 8D 22 8D FF FF 00 00 01 B0 03 00 00 01 B5
0023BD10  0D 0F 00 00 01 00 00 00 01 20 00 C4 85 C0 00 46 54 80 13


Taking out that one "8" nybble, for example, puts the sequence back to 28 bytes after the packet header's 0x47. So basically we know that the "AF" at the end of the packet header needs to be "1A" or "3A," and that it would be reasonable to conclude that the four extra bits fall somewhere between the 0x47 and 0xFF00. I have that dangling "8" in there, but it could be something else. Someone more familiar with the encoding may be able to recognize it. Maybe it's where the 07-21-01 match breaks.

Edit: It needs to be 3A, because the "0x02" bit is the payload-unit-start indicator which should be set at the beginning of an iframe.
« Last Edit: 05/11/2014 02:38 PM by mvpel »
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline arnezami

  • Full Member
  • **
  • Posts: 282
  • Liked: 262
  • Likes Given: 345
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 :)
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

Online grythumn

  • Full Member
  • **
  • Posts: 211
  • Liked: 124
  • Likes Given: 140
Teasing away at the top of iframe 9. 23:04 starts at 15950. Best correction I got for 19:04 was X:15522:80,X:15518:80, but there were several similar solutions, and didn't try an exhaustive 2-bit search[0], much less 3-bit.

Trying to figure out 20, 21, 22... first attempt didn't end up with the correct number of bits. :/ More tomorrow, brute force search in progress.

-Bob
[0] Ran through single bit permutations to remove the largest artifact, noted the bit locations that helped, ran a second set of permutations against for each of the first list.

Offline mikes

  • Full Member
  • ***
  • Posts: 332
  • Norwich, UK
  • Liked: 68
  • Likes Given: 43
I 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.

I think this is equivalent to flipping each of the bits of the search string, then doing a search for each of those 72 strings. I've tried that, but it didn't turn anything up.

#!/usr/bin/python
import os,sys
def binsearch(foo,ninebytes):
    want=hex(ninebytes)[2:-1].zfill(18)
    print want
    os.system("./bgrep "+want+" "+foo)
foo=sys.argv[1]
orig=0x000001b003000001b5
mask=0x800000000000000000
binsearch(foo,orig)
while mask :
    binsearch(foo,orig^mask)
    mask >>= 1


https://raw.githubusercontent.com/tmbinc/bgrep/master/bgrep.c

Online Chris Bergin

Now past the 100,000 read mark for this thread. Worth noting! :)

Online Shanuson

  • Full Member
  • **
  • Posts: 282
  • Liked: 197
  • Likes Given: 499
Ok here is a new file containing a comparison of raw.ts and try1.ts

Containing:
15 I-Frames, the start position of the '47' byte and the following 94 Bytes
Only clearly sees that all those parts are I-Frames.

Most of them are quite similar:
But IF0 and IF1 have some errors

And there is IF7 which is the by 4bit shifted one.  (In the File I manually shifted if so one can compared the bytes better)

The following is how it should look like IMHO.
There are 3 blocks of XXs which are different for each frame. The first one seems to contain a counter. The rest i dont know. But it should be mentioned in that ISO*.pdf how they should look like/what they should contain.

47 43 E8 37 07 10 00 xx xx xx 7E 00 00 00 01 E0 00 00 81 80 07 21 01 xx xx xx FF FF 00 00 01 B0 03 00 00 01 B5 0D 0F 00 00 01 00 00 00 01 20 00 C4 8D C0 00 46 56 C0 1E C0 01 xx xx 9A FC 7C 2E EE 2C 08 78 28 C7 00 00 01 B2 65 6D 34 76 20 34 2E 33 2E 30 4E 31 40 C3 FF 00 00 01 B6 1x

About the problem where the shift occurred: Frames are framed by large blocks of FFs with 47 1F FF 1X in them if they are large enough and X counting up. On Both sides of that IF7 they are already align. So the shift and reshift should have occurred between those. Maybe it is just enough to add a F at the end of the block before IF7 and remove one at the start of the block after IF7 (0x23cde9).

Cheers
Shanuson
« Last Edit: 05/10/2014 12:25 PM by Shanuson »

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
My I7 MBP spent the night in the freezer (literally) running brute force bit flipping (X flags), and was still chugging like a champ when I killed the process this morning. It had run ffmpeg 2,452,480 times in 14:41:50 (8 threads). Computational feasibility demonstrated.

It came up with a few decent improvements, but no where close to what SwissCheese did by hand (on try1). The best is probably

00:10:-1,00:14:-1,00:17:71044,00:24:-1,00:27:114198,08:15:61126,
19:05:20944,21:13:50333,25:14:57756,35:05:-1,36:15:-1,43:06:27582,
X:15868:3

but I haven't looked through all 1024 yet.

Reading through the latest, it seems like I need to rework the code to run through raw.ts instead. This will probably be faster anyway, since I can manipulate bits directly in the data and skip the -mbm flags argument. Just need to catch up on what has been done.

Great work Shanuson


edit: I updated my java code to include the multithreaded ffmpeg stuff http://pastebin.com/bKgzCRqD

edit2: Just a bit of warning, this will peg your CPU at 100% for a long time, make sure it has plenty of cooling and you don't have any unsaved windows open just in case ;)
« Last Edit: 05/10/2014 01:04 PM by theshadow27 »

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
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 :)
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

Hmm 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?

Edit: By "first bad block" I'm indexing blocks index= (x + y*width) i.e. left-to-right, top-to-bottom. Or is it in the order that they are encoded (which isn't always that)?

That's actually not so bad, really makes the problem easier. Basically the chess problem. Maybe we can ask IBM to borrow Deep Blue (or Watson :D
« Last Edit: 05/10/2014 01:14 PM by theshadow27 »

Tags: