I cleaned the transport stream headers on part 131, attached below. My notes during the cleaning:Packet 163 at offset 30644 is a VOP start frame, but it needs a bit of attention. Unlike the other start packets, it has an 11-byte adaptation field and the 000001e0 starts 4 bytes later in the ts packet at offset 0x7708. I adjusted the AF length to allow the 0x000001e0 to line up as needed, but I'm not sure why this one is different and what the extra four bytes are for.The four bytes in question, 0x181803c0, register as padding based on the adaptation field's bitmap, so theoretically should be 0xff, but I'm not sure if it might be something else that's supposed to fall in those four bytes. But it does appear that a reasonable-looking pframe came out.
At offset 0x12d18, this appears to be a null packet, but the continuity counter is off, the count goes from 0x1 to 0x2 across this gap in raw.ts as well: null packet at 0x24a7ec and at 0x251324 However in raw.ts, this packet at 0x24ea04 reads 0x2e3ffe2f - much closer to 0x471fff1x than a 0x3e8 packet. Setting it to 0x471fff1f at 0x12d18 in fixed_edit8_part_131.ts - looks like it turned out okay.
Offset 0x21004 - a clear null packet with an incorrect CC - 0xd to 0x0 and later 0xe - perhaps an alignment packet inserted by Shanuson?
Offset 0x401ec - the adapation field length 0x77 (119) may be wrong here, but can't tell due to corruption. The last ff is at 0x4021A, which is 42 length, 0x2a, but we then have 0x7F (1 bit) 0xfc (1 bit) then a few more ff's. Leaving it at 0x77 since it doesn't exceed the packet length. The data at this AF length starts with 0x95591f6b.The pframes look promising, I've attached one of the better ones for your enjoyment - it's flames lapping out to the left side, and you can see the outline of the legs as the lighting changed from the previous frame.This still needs work in the MPEG headers, but we should have a solid transport stream.Edit: (Depressingly, the pframes that emerge from ffmpeg checksum as identical to the pframes out of the original ts file, but I guess you have to actually do the cleaning in order to find that out.)
Thanks for pointing it out again and more clearly than I did before. It could be that the last few MB's of a frame are part of that last packet. So identifying this is important for the last row of a file.
The missing P-frame header is:47 43 E8 3x 07 10 00 36 d5 71 7E 00 00 00 01 E0 00 00 81 80 07 21 01 B7 07 A5 FF FF 00 00 01 B6 5x
97 frames (some of them only very partially recovered) out of ~270 were used.
Quote from: SwissCheese on 05/27/2014 12:36 am97 frames (some of them only very partially recovered) out of ~270 were used.Wow, fantastic!Since SpaceX actually designed and built the rocket, I'm thinking they should get top billing, right?
Quote from: Shanuson on 05/26/2014 10:09 pmThe missing P-frame header is:47 43 E8 3x 07 10 00 36 d5 71 7E 00 00 00 01 E0 00 00 81 80 07 21 01 B7 07 A5 FF FF 00 00 01 B6 5xI've looked, but can't seem to find it either. Though I think PTS should be B6 07 A5.
Here is my cleanup of part 10 of the split TS file. If Shanuson, mvpel and the others can have a look and let me know if I've missed anything, that would be great.
Here is rawsplit_part_2_fixed.ts again this time with all TS-data packets headers and stuff fixed.I will now check all those parts that are submitted by others, Done is part: 1,2,7,8,15