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

Offline Shanuson

  • Full Member
  • ***
  • Posts: 395
  • Liked: 327
  • Likes Given: 2542
<snip>
The next block of XXs is part of the Presentation Time Stamp PTS
how to get the PTS is explained quite well here: http://dvd.sourceforge.net/dvdinfo/pes-hdr.html
PTS: 21 01 xx xx xx.
We can now decode the PTS of the good frames and define the PTS of the messed up ones.

It is late again, my bed is calling.
I will calculate the PTS tomorrow, also will work out that last xx xx.
Here are the raw 5 byte PTS of the frames:

IF00: 99 31 59 14 6C
IF01: 21 01 61 23 ED
IF02: 21 01 67 CE 5D
IF03: 21 01 6F 78 CD
IF04: 21 01 77 23 3D
IF05: 21 01 7D CD AD
IF06: 21 01 85 78 1D
IF07: 21 01 8D 22 8D
IF08: 21 01 93 CC FD
IF09:  21 01 9B 77 6D
IF10: 21 01 A3 21 DD
IF11: 21 01 A9 CC 4D
IF12: 21 01 B1 76 BD
IF13: 21 01 B9 21 2D
IF14: 21 01 BF CB 9D

Cheers
Shanuson

Here is the next part:
PTS values are separated by 120120:
All except the first one are OK:
The first should be:
0x210159797D

Also I missed one byte that changes from IF to IF, namely the 4th in each sequence: 47 43 E8 3x ......
This X is a continuity counter. But it is different from the counter of the 47 1F FF  1Y packets.
In the better part of the file one find that X count continue for packets with 47 03 E8 1X,  47 03 E8 3X and 47 43 E8 3X. so it seems it is a counter for each packet with the same PID (13 bit long), namely 0x13E8 or 0x1FFF
So to find the right value of X for each corrupt frame one has to check the surrounding packets with the same PID, which i did:
Here are the 15 correct continuity counter X values for all IF's: (red ones contained errors in raw.ts
B, D, 7, 0, D, D, 6, 6, F, 4, D, 4, 8, 7, 5

Finally back to that 4bit shifted part:
Thanks to gospaceX work I know now what to look for:

Here the part of the file (4x188 bytes copied out of raw.ts, starting from 0x23bb74):
Black part is the start of  an I-Frame header (What you find in raw-headers.txt)
First red block: Aligned right; some errors at the end where all should be ff.
Last red block: Also aligned right and all following blocks too.
Blue Block: Errors at the start, so no 47 start byte; should look like the one before, all FFs
Green Block, Start of the I-Frame, but shifted by 4 bits to the LEFT as can be seen by comparing that one to a correct one (first 4 bits are the D at the end of the blue block)
So, the Blue block could also be shifted but it does not matter since it should contain only FFs.
Finally to fix this, I think, one only has to move that black-green block by 4 bits to the right (including that last D of the blue block and remove the last green B).


47 1F FF 18 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 7F FC FF FF FF FD 7F F4 FF 7C F6 FF FF FF FF FF FF FF DE 7F 7D 76 FC F4 EB 6D 6F F6 FF 1F FD BF FF FF FF FF FF FF FF FB 03 EE 76 17 E0 1B DA 08 FF EB DF 14

C0 D8 61 01 F7 5F C8 3F FE 7B FF F8 7D 53 57 70 34 EB DC F3 3F 5C 82 FF F3 FE 3E BB 78 7F FF FF FF FF FF BB FE 67 FF FF FF CF FF 5F FF FE FF F9 FF FF E7 FF AE FF F9 FF FF FF FF FF FF FF FF FF DF F3 3F 9F F5 FF FF F3 DF D7 67 FA 37 EF AF CF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FA 7F E7 FF FF FF FD 38 E9 69 AF E7 EC F0 8F FF 2B 30 E5 53 5F FD BF FF FF B7 78 34 FA EE FF FF FF FD FF F3 FF FF FF FF 5F FC 3F EF FD 9F 63 FC 9C 0F F7 40 FC BA 86 2D 65 44 70 BF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FC 12 BA 06 FA A9 FF 4D

BE 66 AF 8C EC B9 A7 CD C3 5C 74 0C 28 21 3B 00 18 18 B5 00 72 10 18 D2 28 DF FF F0 00 00 1B 00 30 00 00 1B 50 D0 F0 00 00 10 00 00 00 12 00 0C 48 5C 00 04 65 48 01 34 00 9E FD E9 AF E7 C2 2E E2 C0 87 86 8C 2B C1 04 98 06 C8 D3 47 62 03 42 E3 32 E3 02 E3 00 0C 3F F0 00 00 1B 61 0C F0 C0 D6 08 65 8D 9F BD C7 A4 B8 18 F1 19 57 32 42 08 44 41 E0 08 B5 27 E4 46 BA 7A ED 28 0A AA 89 BD 3F 60 BA F5 9F 96 07 05 53 CA E7 AE 0B 8A 3D 2E FA 25 D2 79 3E 7F 88 72 DE 8E B1 EC FF C1 3C 88 13 31 E7 79 26 19 C7 E9 AF 33 38 CE 46 3A 56 4F 34 34 A8 9E 73 54 76 C4 D1 76 82 EB

47 03 E8 17 3D DB B8 2A AE 02 77 05 E6 E1 48 38 8F CB 54 AB 3F CD D5 EA 29 75 70 60 A4 B3 5C A8 41 C4 26 13 A4 F3 7F 6B FB 9D AD 22 45 A1 9F B4 5D 5D 5E 39 58 FC C9 F0 77 47 99 FD CF 6E 6B 9E 4C 6C 4D 48 C9 FB 7C FC 9F EA 0F F0 15 21 27 13 F3 FA B8 79 2F D7 4F 73 D2 58 28 A7 B4 F2 90 5D 4B B8 39 00 46 E1 40 4D BA C8 9C 33 25 A0 BA F6 B9 45 E9 E5 05 1D D7 71 D5 E6 73 B9 BD B9 3D 15 73 BD FD E1 A6 75 70 FC 82 47 D2 DE ED 7F 3D E8 F4 A0 0A 94 86 F9 17 D1 17 23 EA 4D BF D5 84 AF A7 EB 6B 1E 1B DB D2 BE 14 D0 60 90 B7 94 B8 AA 86 B0 20 47 18 0E 0A 23 E5 C9 8A 0B



Tomorrow, I will work out that last XX XX of the headers. I will then change the raw.ts file to include the right headers and that shift and upload it.

Cheers
Shanuson

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
How to use:

(-1) download these files into an empty dir, drop raw.ts there too
(0) run cut_188byte_sections.sh (cuts raw.ts into sections)
(1) compile: gcc -Os -Wall fix_tspackets.c -o fix_tspackets
(2) run fix_tspackets_in_sections.sh
    - fixes each section
    - copies fixed sections into fixed_sections/ subdir
    - glues them into "new" fixed_sections/raw.ts
    - runs cut_188byte_sections.sh on it
    - produces raw.hex.diff for you to peruse

With this source, resulting "new" raw.ts plays no worse than original
(maybe even better, it's hard to tell).

There is a catch, though. The most interesting part of this exercise
is to decode more data from packets with damaged headers.
The part of code which fixes packets is here:

        fix_4740001x_packets(pkt);
        fix_4740201x_packets(pkt);
        fix_4743e83x_packets(pkt);
        fix_null_packets(pkt);

and the part which tries to decide which packets are data, follows:

        // Does a bit too much damage by "fixing":
        //fix_data_packets(pkt, 0.3);
        // Fares better:
        //fix_data_packets(pkt, 0.25);

As you see, it is commented out. There are some heuristics in fix_data_packets() which avoid a few cases where damage is done, but apparently not enough.

I encourage interested people to uncomment last line, run the program,
look at raw.hex.diff, and suggest improvements to fix_data_packets() logic.
« Last Edit: 05/12/2014 12:25 am by gospacex »

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
Ah ok. I think that can happen too: when the first macroblock thinks it has seen the 4 blocks but those stop-bits weren't all real stop-bits the next macroblock will pick-up the blocks from the previous macroblock. But then you would also expect some color-trouble because those would also be interpreted wrong I guess. I think Michael Niedermayer knows this better though.

yes, with enough (bad) luck a block could end up in the wrong position, but the next MBs MCBPC & cbpy would then not be where they are expected very likely

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
Parsing raw.ts using info from http://en.wikipedia.org/wiki/MPEG_transport_stream

The file consists of 188-byte ts-packets.

1st byte is always 47.

2 next bytes are 000<packetid13bits>, and apparently
they are always 03e8 for non-null ts-packets and 1fff for null ts-packets.

there are more than 2 PID values in the ts packets/ file

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0

Yes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.

This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.

IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604

Yes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.

This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.

IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)

Aligning is easy, and possibly not that useful.
For one, it changes file offsets of ts-packets, making it harder for us to refer to the packets in speech.
E.g. "packet at offset XYZ needs its header fixed this way" - offset XYZ in *which .ts file*?

The hard part is repairing damaged headers, and subsequently, data.

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
Operating on the ts packet would be easier if you set up the struct to map it all out:

typedef struct {
    unsigned char fourseven;
    unsigned tei:1;
    unsigned pus:1;
    unsigned pri:1;
    unsigned pid:13;
    unsigned scramble:2
    unsigned hasadapt:1;
    unsigned haspayload:1;
    unsigned count:4;
    unsigned char payload[184];
} tspkt;

See http://www.cs.cf.ac.uk/Dave/C/node13.html for more info.
"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 theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7

Yes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.

This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.

IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)

Aligning is easy, and possibly not that useful.
For one, it changes file offsets of ts-packets, making it harder for us to refer to the packets in speech.
E.g. "packet at offset XYZ needs its header fixed this way" - offset XYZ in *which .ts file*?

The hard part is repairing damaged headers, and subsequently, data.

Aligning is easy, but also critical. There is no way to decode misaligned data. Luckily for us, michaelni has already written code to do this automatically (tsalign.c).

Referring to packet header locations is not that useful, as they are easily automatically repaired by the other program michaelni has written (tsfix.c).

It's as simple as

cat raw.ts | tsalign | tsfix > fixed.ts


The only hard part is repairing the data.

P.S. I saw you read all about mpeg on wikipedia, but were I you I'd listen to what he says:

Wooow! I didn't realize this at first. But we have Michael Niedermayer in the house!  8)  One of the creators of ffmpeg itself.

Just saying  ;)

Offline Axiom

  • Member
  • Posts: 8
  • The Netherlands
  • Liked: 0
  • Likes Given: 0
Hi! After following this forum for several years as a silent consumer, I felt compelled today to try and add something to this superb effort (first post, so go easy :)

About the Iframes, i was thinking that manual moving the macroblocks around will be difficult if you don't have a lot of reference (i.e. if there aren't many features on the block). So what about getting some help from statistics. So, would it be helpful to statistically compare all valid macroblocks for the closest matching edges, then automatically reshuffle the macroblocks. Some results may be false, yet if you create several iterations of the image for visual confirmation, those could rapidly be checked. You could even pin correctly placed macroblocks in place, excluding them from the automatic reshuffle. Would that be of help? 

Furthermore, and this may not be feasable but wanted to post the idea anyway, would it be possible to use the last frame before the next iframe, as a reference point. So if you have a very good Iframe upstream, say iframe8, let the video run until just one frame before iframe9, and use that as a reference for reconstructing Iframe9. Just my 50c.

Cheers!

Offline Adaptation

  • Full Member
  • *
  • Posts: 160
  • Liked: 40
  • Likes Given: 38
Alpha 3 of my transport stream search and repair tool is finished.

Seems like michaelni has been doing a good job at making me redundant.   ;)
Really some top notch work here, I'm impressed. 

Hopefully my program can still help with manual searches and bit manipulation needs... for people with windows. 
 

Made the search capable of finding results that are not byte aligned.  (This feature includes a wildcard filter and can return results with a specified tolerated number of bit errors.) 
Enabled bit level insertion and deletion. (will bit shift everything after that point in the file)
Bit deletion at arbitrary point in the byte, bit insertion is after the byte selected, (first bit of next byte) to insert in the middle of a byte you can bit shift the whole file so your desired insertion point is between two bytes or select the byte ahead, insert and twiddle the bits back to how you want them. 

Switched most of the operations out of managed managed memory and most of the math is now 64 bit.

Fixed quite a few bugs but several remain, it will still crash if you operate most of the controls before opening a ts file so make sure to open one first.

Still plan on adding a bit level find/replace feature, adding an autosave/undo and colorizing the background between packet boundaries and search results in the hex editor. 

<edit> removed transport stream program </edit>
« Last Edit: 09/07/2016 01:11 am by Adaptation »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi guys,

I have a bit of a mystery going on and it's holding me back from doing great stuff. ;) Hopefully somebody else has an idea what is going on.

This is essentially about how luminance/chrominance (errors) propagate. From what I understood so far each (macro)block propagates to its right (macro)block and to its bottom (macro)block. Luminance does it on a block (8x8pixel) basis while chrominance does it on a macroblock basis. So if you set macroblock 0,0 to "more red" the entire picture becomes that much "more red". Right?

Now here is my mystery example.

Take iframe 12 (try1) and enter 0:0:-1,13:24:72730 as mmb. It shows the bottom part of the picture and it looks quite nice.

Now enter 0:0:-1,12:24:72687 and suddenly you see a luminosity error appearing far from the block we just changed. How is this possible??

I suspect this has to do with the fact that the lower-right block of 24:26 is getting different input from above or left, but I don't understand why it could be so different from before. Maybe some kind of dc-clipping? (but there is no error log of that I think) Is this block reading the bits differently because it has different input? Because I always thought that the reading/meaning of the bits was not determined by the input.

I'm confused by this.

Regards,

arnezami

« Last Edit: 05/12/2014 08:13 am by arnezami »

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Hi guys,

I have a bit of a mystery going on and it's holding me back from doing great stuff. ;) Hopefully somebody else has an idea what is going on.

This is essentially about how luminance/chrominance (errors) propagate. From what I understood so far each (macro)block propagates to its right (macro)block and to its bottom (macro)block. Luminance does it on a block (8x8pixel) basis while chrominance does it on a macroblock basis. So if you set macroblock 0,0 to "more red" the entire picture because that much "more red". Right?

Now here is my mystery example.

Take iframe 12 (try1) and enter 0:0:-1,13:24:72730 as mmb. It shows the bottom part of the picture and it looks quite nice.

Now enter 0:0:-1,12:24:72687 and suddenly you see a luminosity error appearing far from the block we just changed. How is this possible??

I suspect this has to do with the fact that the lower-right block of 24:26 is getting different input from above or left, but I don't understand why I could be so different from before. Maybe some kind of dc-clipping? (but there is no error log of that I think) Is this block reading the bits differently because it has different input? Because I always thought that the reading/meaning of the bits was not determined by the input.

I'm confused by this.

Regards,

arnezami



I've seen this too. Either the offending block is messed up in some way that propagates the error, or MPEG behaves badly when values are clipped. The problem seems to be worse on frames where the top row is missing. I attached an image that shows the path from the bad block to where it gets noticeably bad.

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604

Yes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.

This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.

IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)

Aligning is easy, and possibly not that useful.
For one, it changes file offsets of ts-packets, making it harder for us to refer to the packets in speech.
E.g. "packet at offset XYZ needs its header fixed this way" - offset XYZ in *which .ts file*?

The hard part is repairing damaged headers, and subsequently, data.

Aligning is easy, but also critical. There is no way to decode misaligned data. Luckily for us, michaelni has already written code to do this automatically (tsalign.c).

Referring to packet header locations is not that useful, as they are easily automatically repaired by the other program michaelni has written (tsfix.c).

It's as simple as

cat raw.ts | tsalign | tsfix > fixed.ts


The only hard part is repairing the data.

Unfortunately, it is not that easy to automatically
fix headers without damaging data even more.

I think it's better to have the corrections explained (so that they can be cross-checked and tuned).
For example, take edited.ts and coerced.ts. edited.ts has this sequence of packets:

00011a0 4703e8171ee887cbdfca43de18b9c2ea1a00c602180987dea67319134
000125c 4703e818ea28a720cc02d4aab0f256ba257cbc142a249ece63371f217
0001318 47be1c520419650d5d53bbcdb599034d0a9671ca97fbe0f475e8a40e0
00013d4 474842d0f2fde345f6dfbfd879228b38560c9b12c310942450f11ef62
0001490 477883798db922308145ac41ec97875bbc361389625238f2a0c8ec2ae
000154c 477c538a240317970fb67007230fca81c10d7055a74983e73efec042c
0001608 47d08588d2899b38c980f24655dd453b0f1fef99c87541c3458f9a9e4
00016c4 477d03c3c0c0da0c5ea8033e10419583170d016759e418bc1003fc9a0
0001780 4703e81fb89610bc12a1b164f81e27fe900e06540e126806979704207
000183c 4703e8301a005ffffffffffd7fffffffffffc7ff6ffffffffffffffff
00018f8 4740001c0000b0110000c100000000e0100001e020d36af0acfffffff
00019b4 471fff12ffffffffffffffffffffffffffffffffffffffff8480e4ffe
0001a70 471fff13fffffffffffffffffffffffffffffffffffffffffffffffff
0001b2c 4703e8149fdbfffffffffffffffffffffffffffffdfff3ffffaffe1fe
0001be8 4703e815dbb77e4e2fffefff9fffcfff5fffe17fb8cfe799def8fe67f

and in coerced.ts, the corresponding packets are

0001318 4703e8171ee887cbdfca43de18b9c2ea1a00c602180987dea67319134
00013d4 4703e818ea28a720cc02d4aab0f256ba257cbc142a249ece63371f217
0001490 471fff12fffffffffffffffffffffffffffffffffffffffffffffffff
000154c 471fff13fffffffffffffffffffffffffffffffffffffffffffffffff
0001608 471fff14fffffffffffffffffffffffffffffffffffffffffffffffff
00016c4 471fff15fffffffffffffffffffffffffffffffffffffffffffffffff
0001780 471fff16fffffffffffffffffffffffffffffffffffffffffffffffff
000183c 471fff17fffffffffffffffffffffffffffffffffffffffffffffffff
00018f8 4703e819b89610bc12a1b164f81e27fe900e06540e126806979704207
00019b4 4703e83a1a005ffffffffffd7fffffffffffc7ff6ffffffffffffffff
0001a70 474000110000b0110000c100000000e0100001e020d36af0acfffffff
0001b2c 471fff18fffffffffffffffffffffffffffffffffffffffffffffffff
0001be8 471fff19fffffffffffffffffffffffffffffffffffffffffffffffff
0001ca4 4703e81b9fdbfffffffffffffffffffffffffffffdfff3ffffaffe1fe
0001d60 4703e81cdbb77e4e2fffefff9fffcfff5fffe17fb8cfe799def8fe67f

As you see, packets 2..8 were marked as "null" and filled with FF's.
Granted, their headers look severely corrupted, but it's wrong
to turn them to "nulls". Check 8'th nibble. First two packets
have 7, 8 there. Continue incrementing it through the corrupted packets.
9,a,b,c,d,e... When you reach F, you get a match again, with the
4703e81fb89610bc12a1b... packet (see? it's awful when packets
have no fixed offsets - I need to refer to them by *contents*...)
Next is 0 - matches next packet.
Next is 1 - corrupted.
Next is 2 - match. 3 - match. 4 - match. 5 - match!

Those six packets with headers has been auto-fixed to "nulls", subsequent packets have their seq fields renumbered. This destroyed some data which was there.

We need to be more careful than that.
« Last Edit: 05/12/2014 08:03 am by gospacex »

Offline Jakusb

  • Full Member
  • ****
  • Posts: 1207
  • NL
  • Liked: 1215
  • Likes Given: 637

Hi guys,

I have a bit of a mystery going on and it's holding me back from doing great stuff. ;) Hopefully somebody else has an idea what is going on.

This is essentially about how luminance/chrominance (errors) propagate. From what I understood so far each (macro)block propagates to its right (macro)block and to its bottom (macro)block. Luminance does it on a block (8x8pixel) basis while chrominance does it on a macroblock basis. So if you set macroblock 0,0 to "more red" the entire picture because that much "more red". Right?

Now here is my mystery example.

Take iframe 12 (try1) and enter 0:0:-1,13:24:72730 as mmb. It shows the bottom part of the picture and it looks quite nice.

Now enter 0:0:-1,12:24:72687 and suddenly you see a luminosity error appearing far from the block we just changed. How is this possible??

I suspect this has to do with the fact that the lower-right block of 24:26 is getting different input from above or left, but I don't understand why I could be so different from before. Maybe some kind of dc-clipping? (but there is no error log of that I think) Is this block reading the bits differently because it has different input? Because I always thought that the reading/meaning of the bits was not determined by the input.

I'm confused by this.

Regards,

arnezami

I had a similar experience a few days back. I cannot remember which frame. I think 4 or 5.
I had to -1 the very last mb to have it mess up the clock. It is very strange to have a block down stream mess up the image up stream. Or isn't it?

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
I've seen this too. Either the offending block is messed up in some way that propagates the error, or MPEG behaves badly when values are clipped. The problem seems to be worse on frames where the top row is missing. I attached an image that shows the path from the bad block to where it gets noticeably bad.
Yeah. I'm starting to realize that it is even harder than I thought it would be.

I wanted to create a "clean enviroment" for checking bad block propagation by starting at the end and working backward therefore avoiding the issue of having propagation from above and left.

But this won't work if block propagation below and to the right is different when adding more blocks to the left and above.

Hmmm. A rethink is required here.

Thanks for that diff!

Regards,

arnezami

Offline hutchel

  • Overzealous Enthusiast
  • Full Member
  • *
  • Posts: 107
  • Washington, DC
  • Liked: 18
  • Likes Given: 38
I've seen this too. Either the offending block is messed up in some way that propagates the error, or MPEG behaves badly when values are clipped. The problem seems to be worse on frames where the top row is missing. I attached an image that shows the path from the bad block to where it gets noticeably bad.
Yeah. I'm starting to realize that it is even harder than I thought it would be.

I wanted to create a "clean enviroment" for checking bad block propagation by starting at the end and working backward therefore avoiding the issue of having propagation from above and left.

But this won't work if block propagation below and to the right is different when adding more blocks to the left and above.

Hmmm. A rethink is required here.

Thanks for that diff!

Regards,

arnezami


Quick thought from a quiet computer Geek in the audience.... Can Space X provide you with a good 30 sec chunk of video from the same setup so you can see what good video is supposed to look like?  That would get you ground truth as to formatting etc.  It would also give you the ability to selectively damage the bit stream to better understand propagation related errors.

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7

Unfortunately, it is not that easy to automatically
fix headers without damaging data even more.

I think it's better to have the corrections explained (so that they can be cross-checked and tuned).
For example, take edited.ts and coerced.ts. edited.ts has this sequence of packets:



Those six packets with headers has been auto-fixed to "nulls", subsequent packets have their seq fields renumbered. This destroyed some data which was there.

We need to be more careful than that.

If you look at tsfix.c, it defaults to assume a packet is video rather than null. And it does not fill null packets with 0xFF, it just fixes the header so they are skipped by ffmpeg. Also, I have been working on statistical analysis of packet contents (rather than just the header) and context (previous and next packets) to increase accuracy.

The problem with your approach is that it assumes the error rate in the header is low enough for a human to be able to recognize the different parts. It isn't, at least in a lot of the data, the error rate is 16-20% everywhere, including the header, not just the data. Humans can't help finding patterns in things, even if they are not there. Especially when you start taking packets out of order/context, it is hard to get the whole picture.

For example, as I posted earlier, there are spikes in noise level where error rate spikes above 30% for a few thousand bytes. If this occurred in a null packet it might look to you like a mildly corrupt data packet, but in reality it is junk.

The goal of cleaning the raw stream is to give the folks here the very best mpg4-img files to tweak visually. There are 23838 packets in raw.ts - IMO It is better to tune the algorithm rather than numbering the data and tuning by hand. I don't understand your concern, for any given code run on any given input, the output will always be the same. It's not like my output will be different than yours, cross referencing is always possible by offset.

Edit: gospacex - look at http://pastebin.com/HmDAzu1q to see my version of null packet identification. Looking again, it seems to be similar to yours. My next iteration will count runs of diffs instead of just the number of diffs.
« Last Edit: 05/12/2014 02:47 pm by theshadow27 »

Offline Shanuson

  • Full Member
  • ***
  • Posts: 395
  • Liked: 327
  • Likes Given: 2542
Ok, I am done with my work on the headers

attached you find a raw_edit1.ts (edit: file contained a bug with frame169(old Iframe8), you find the corrected version here) where only the 15 I-Frame headers are changed (plus a few '47' bytes maybe), Also the one 188 byte block is reshifted by 4 bits to align it.

The last XX XX was part of vbv_occupancy (1 marker bit and the frist 7 of the latter half of vbv_occupancy)
According to michaelni, the actually value is not needed to extrace I-frames.

Cheers
Shanuson
« Last Edit: 05/12/2014 11:09 pm by Shanuson »

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
I encourage interested people to uncomment last line, run the program,
look at raw.hex.diff, and suggest improvements to fix_data_packets() logic.

After wading through this code, I think we have roughly the same idea. Just took me a while to get used to your coding style before I could see what you were doing.

I've started to add your extra header patterns to the paste bin code, and tweaked what michaelni had done for fixing packets. Overall, I think of the three the newest style is the most concise and fastest performing.

The things that still need to be done:
(1) check the rest of your packet types, and adjust the masks as needed.

(2) integrate min(score) over packet number, and use this to allow the probabilities to relax in high-error regions. When p(error) exceeds a certain value, it might be best to "drop" packets all together rather than feed them to the decoder.

(3) rather than use a simple bit-count as the diff, we should really be checking the number of continuous matching bits. In other words, we should compute Poisson rather than binomial probability.

(4) in addition to expected and mask, there should be a third row of bit probability. when the expected is not known (thus, nothing to diff). This would solve the issue of null body matching, since the p(1) should be close to .5 for real data and close to 1 for null data. Note this only matters when (3) has been implemented, otherwise expected = ..0x55 0x55 0x55.. has the same effect for the binomial probability.

Edit (5): evaluate all possibilities, rather than the first best match, then choose the highest.

Edit (6): fix sequence numbers where possible 
« Last Edit: 05/12/2014 04:54 pm by theshadow27 »

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
I think we can also assume that the transport error and the scrambling control bits should never be set in any header, right? That may help constrain the problem a bit. Turning off the transport priority bit in everything may also be helpful, since we're dealing with a file rather than an over-the-air stream and wouldn't expect an overworked decoder to need to choose which packet to deal with first.
"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

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
0