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

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
No, I knew that, what I meant to ask was whether blocks from one macroblock can end up inside another in a way that would result in macroblock contents being offset by half of macroblock. It probably isn't. Which would mean that the odd object is not the tip of the leg.
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.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
@Michael Niedermayer:

I've been investigating the possibility of automatically setting all L1,L2,L3,L4,C1,C2 values for all macroblocks for a frame. Basicly inputting an mmb and letting a script detect "bad lines" in the picture. Moving from the right-bottom corner to the upper-top.

I'm starting to believe (using some extra logging and some manual experimentation) that this might actually be possible. If it does this would improve the quality of the frames quite dramatically and would save a lot of manual work!

However there is one thing that I find difficult to do myself. And I think you might be able to help us. Instead of using this kind of setting:

15:14:-1:0:-40:0:0:0:20

where I replace the current macroblock with a blank one and change the DC values.

But what I really want to do is this:

15:14:57217:0:-40:0:0:0:20

In other words: I want to keep the macroblock with its (structured) data as much as I can (at the very least the blocks in it which are set to 0 above) but change only the DC "starting" values. So not blanken it, but modifying it so these DC-values make sure propogation to other blocks works the same as now with -1 (therefore fixing the color and intensity of following blocks) but I also keep the current blocks inside the current macroblock.

Is something like that possible?

Regards,

arnezami
« Last Edit: 05/11/2014 06:04 pm by arnezami »

Offline theshadow27

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

So it seems like it should be practical to write a tool that can walk through the raw.ts and use the rules of the packet header formatting and sequence numbers to reconstruct a more coherent transport stream. Even just getting all the errors out of the null packets by replacing everything with FF might make it easier to discern good patterns.

Edit: For example, in raw.ts there are bytes missing or added between 0x37ACC and 0x371EC - that's the first place where the columns shift in a 47-column hex display.

Working on this, in the meantime, here is a plot of the bit errors per null packet in raw.ts. This was created by finding probable null packet headers (p > 0.85) then counting bits deviating from 1 within the 188 bytes.


Edit: BTW with some quick math, assuming raw.ts is ~30s, those big spikes of 5-8 packets (30-45ms) are almost certainly lightning EMI. Must have been some storm...
« Last Edit: 05/11/2014 03:05 pm by theshadow27 »

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
I found out why iframe 0 didn't extract - the transport stream header for the first packet of the iframe had its "transport error indicator" bit flipped, and so that packet containing the very first piece of the iframe was ignored, resulting in the entire iframe being ignored.

If you take try1.ts and change offset 0x3E3D1 from 0x43 to 0x03, clearing the TEI bit, then iframe 0 should pop out. It may have some issues since the sequence numbers are rather jumbled right there - it looks like 0x3E48F should be 0x5C rather than 0x5F, and that might contain the adaptation field info for the iframe. The sequence doesn't seem to get back on track until you get to 0x3E83B.


Edit: Coffee deficit - the 0x80 bit is the TEI, not the 0x40 bit.  ::)
« Last Edit: 05/11/2014 05:14 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
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
I found out why iframe 0 didn't extract - the transport stream header for the first packet of the iframe had its "transport error indicator" bit flipped, and so that packet containing the very first piece of the iframe was ignored, resulting in the entire iframe being ignored.

If you take try1.ts and change offset 0x3E3D1 from 0x43 to 0x03, clearing the TEI bit, then iframe 0 should pop out. It may have some issues since the sequence numbers are rather jumbled right there - it looks like 0x3E48F should be 0x5C rather than 0x5F, and that might contain the adaptation field info for the iframe. The sequence doesn't seem to get back on track until you get to 0x3E83B.

No its more than that. The headers are wrong so it doesn't decode and by "wrong" i mean complete garbage beyond a certain point. I don't think the TEI bit is related.
« Last Edit: 05/11/2014 03:10 pm by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
I found out why iframe 0 didn't extract - the transport stream header for the first packet of the iframe had its "transport error indicator" bit flipped, and so that packet containing the very first piece of the iframe was ignored, resulting in the entire iframe being ignored.

If you take try1.ts and change offset 0x3E3D1 from 0x43 to 0x03, clearing the TEI bit, then iframe 0 should pop out. It may have some issues since the sequence numbers are rather jumbled right there - it looks like 0x3E48F should be 0x5C rather than 0x5F, and that might contain the adaptation field info for the iframe. The sequence doesn't seem to get back on track until you get to 0x3E83B.

No its more than that. The headers are wrong so it doesn't decode and by "wrong" i mean complete garbage beyond a certain point. I don't think the TEI bit is related.

Not complete garbage, but very close - Based on the null-packet error estimation there is something like a 15% *average* error rate during iframe 0. This is substantially worse than the rest of the data, which hangs between 0.1% and 1.5%.


Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
I found out why iframe 0 didn't extract - the transport stream header for the first packet of the iframe had its "transport error indicator" bit flipped, and so that packet containing the very first piece of the iframe was ignored, resulting in the entire iframe being ignored.

If you take try1.ts and change offset 0x3E3D1 from 0x43 to 0x03, clearing the TEI bit, then iframe 0 should pop out. It may have some issues since the sequence numbers are rather jumbled right there - it looks like 0x3E48F should be 0x5C rather than 0x5F, and that might contain the adaptation field info for the iframe. The sequence doesn't seem to get back on track until you get to 0x3E83B.

No its more than that. The headers are wrong so it doesn't decode and by "wrong" i mean complete garbage beyond a certain point. I don't think the TEI bit is related.

Not complete garbage, but very close - Based on the null-packet error estimation there is something like a 15% *average* error rate during iframe 0. This is substantially worse than the rest of the data, which hangs between 0.1% and 1.5%.

It was very oddly placed, at the EXACT location that the user data header was to start, it was replaced with a different "error" header with random noise in it. All the header data before that location was perfect without a single bit flip. I could not find anything that looked remotely like the standard data (thats the same for every iframe) in it. It almost looked like it was intentional and the encoder decided to not use this iframe.
« Last Edit: 05/11/2014 03:33 pm by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
Thanks for the clarifications!
"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
I found out why iframe 0 didn't extract - the transport stream header for the first packet of the iframe had its "transport error indicator" bit flipped, and so that packet containing the very first piece of the iframe was ignored, resulting in the entire iframe being ignored.

If you take try1.ts and change offset 0x3E3D1 from 0x43 to 0x03, clearing the TEI bit, then iframe 0 should pop out. It may have some issues since the sequence numbers are rather jumbled right there - it looks like 0x3E48F should be 0x5C rather than 0x5F, and that might contain the adaptation field info for the iframe. The sequence doesn't seem to get back on track until you get to 0x3E83B.

No its more than that. The headers are wrong so it doesn't decode and by "wrong" i mean complete garbage beyond a certain point. I don't think the TEI bit is related.

Not complete garbage, but very close - Based on the null-packet error estimation there is something like a 15% *average* error rate during iframe 0. This is substantially worse than the rest of the data, which hangs between 0.1% and 1.5%.

It was very oddly placed, at the EXACT location that the user data header was to start, it was replaced with a different "error" header with random noise in it. All the header data before that location was perfect without a single bit flip. I could not find anything that looked remotely like the standard data (thats the same for every iframe) in it. It almost looked like it was intentional and the encoder decided to not use this iframe.

Maybe internal buffering after the encoder was brought online? I could see this with a primitive ASIC (or FPGA (or  RTOS)) encoder with a "output valid" signal that was ignored, so that with constant bitrate the resulting junk made it to the transmitter.

Offline theshadow27

  • Member
  • Posts: 28
  • Liked: 27
  • Likes Given: 7
Playing more with the raw.ts error data in MATLAB, I estimate 85% of the data has error rate < 1%, and ~3.0% of the data has an error rate above 12%

Edit: BTW with some quick math, assuming raw.ts is ~30s, those big spikes of 5-8 packets (30-45ms) are almost certainly lightning EMI. Must have been some storm...

Thinking out loud: If this is the case, we can reliably match "strike regions" where P(Err) is greatest in raw.ts before frame extraction, then maybe we can have ffmpeg lock C/L values within those regions. Since we can be relatively confident, i.e. P(Err) < 1%, in the packet integrity on either side of the strike, it should be easier to resync once we are "out of the weeds".

Thoughts?


Edit: to clarify my quote above, the strikes are 5-8 null-packet-counts in duration. There are 4-5 data packets between null packets. So that's locking 25-40 total packets per strike, or about 3-5k of real data.
« Last Edit: 05/11/2014 04:12 pm by theshadow27 »

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
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.
High-order bits mean "Transport Error Indicator" (0),
"Payload Unit Start Indicator" (0), "Transport Priority" (0).

4th byte is always 1x in both types of packets, where x cycles from 0 to f.
High-order bits 0001 mean "no scrambling" (00), "no adaptation field" (0), "payload exists" (1).

See below the listing of first few bytes of first few dozens of ts-packets, generated with
   hexdump -e '"%07.7_ax " 188/1 "%02x" "\n"' <raw.ts
command:

0000000 4703e95f81e103e2...
00000bc 4703e8103de99073...
0000178 4703e81176eeba37...
0000234 479779692f580085
00002f0 4703e413669bd0b3
00003ac 4713e8745300b09b
0000468 4703e81541a70f05
0000524 4703e8164aa9f008
00005e0 4703e817b70130e8
000069c 4703e818795c22a1
0000758 4703e8199ac05d5c
0000814 4703439a7a535507
00008d0 4703e81b06633dc1
000098c 4703e81c264b8290
0000a48 4703e81dcc29a6ab
0000b04 4703e81e107e0382
0000bc0 4703e81ff07cd801
0000c7c 4763e810a60791d7
0000d38 4703e8114386cd32
0000df4 4703e812041d1198
0000eb0 4703e813ffb86c32
0000f6c 4703e8144008f650
0001028 4703e815909cfbd4
00010e4 4703e816589e8010
00011a0 470389071ee887cb
000125c 471ac8d8ea28a720
0001318 47be1c520419650d
00013d4 474842d0f2fde345
0001490 477883798db92230
000154c 477c538a24031797
0001608 47d08588d2899b38
00016c4 477d03c3c0c0da0c
0001780 4703d41fb89610bc
000183c 4703e8301a005fff
00018f8 4740001c0000b011
00019b4 471fff12ffffffff
0001a70 471fff13ffffffff
0001b2c 4797ef1a9fdbffff
0001be8 475fff15dbb77e4e
0001ca4 474ebfbf9fffffff
0001d60 471fff17f7ffcfff
0001e1c 471ffb1827357f43
0001ed8 471fff19ffffffff
0001f94 471fd72aff5fffef
0002050 471fff1bff3ffd7f
000210c 471b1f02bfe7ffff
00021c8 478d5fe8e7476eb9
0002284 47fc19a23faa43df
0002340 470f77d412ac2e05
00023fc 47fff10fdfff3fff
00024b8 47bfe3bffffff5fb
0002574 471fff12ffffffff
0002630 471fff13ffffffff
00026ec 4f1fcf14ffffffff
00027a8 47d64ba1bfffffff

cat rawhex | sed 's/4703e81/.START=/g' | sed 's/471fff1/.NULL==/g'

and perusing resulting text file,
it's obvious that last good ts-packet header is at 0037a10:

0037a10 4703e81e0cf8280187ea...

The next +188 byte offset is:

0037acc 4703681dc10b930c9eb5b9fc....

it looks like moderately garbled ts-packet, but after that
there are no longer any recognizable ts-packet headers at +188 offsets.

The next recognizable ts-header is at 00381ec (not a +188 offset),
and from this location 188-byte packets continue from there.

The next discontinuity is at 00d6e20:

00d6bec 4b03e81c929ef0c...
00d6ca8 45abe11d923e21a...
00d6d64 4703e81e66c3272...
00d6e20 4703e81fa2080de... <== last good hdr
00d6edc 14e09aeb3fd7402...
00d6f98 a3582165fad84dd...
00d7054 11f93b7d90446f5...
00d7110 4e6f8b9b0de6ec6...

and the re-sync happens a bit later here:

00d7250 4703e815f4f261
00d730c 4703e816209781
00d73c8 4703e817784253
00d7484 4743e998e38153
00d7540 4703e8190cbc42

Oh... that's strange... I always need to seek by exactly 132 bytes to get
ts-packet headers to realign... can't be a coincidence!

Overall, there seems to be six sections of correctly-sized ts-packets:

1st_ofs - offset_of_last_recognizable_ts_packet_header
0000000 - 0037acc
00381ec - 00d6e20
00d7250 - 0215c58
0215cdc - 0356ae0
0357378 - 03dbe8c
03dd16c - 04460f0
04461aa (eof, last packet is two bytes short)

Between each section is a block of few hundred bytes.
Its size is always N*188 + 132. ???

I can "repair" the file by padding each section so that its size is a multiple of 188,
and then repair ts-packet headers: it's easy te determine whether the packet is
a null packet or payload packet, and then fix headers to be either
4703e81x or 471fff1x.

Will this be useful in any way?
« Last Edit: 05/11/2014 04:52 pm by gospacex »

Offline aero

  • Senior Member
  • *****
  • Posts: 3629
  • 92129
  • Liked: 1146
  • Likes Given: 360
Quote
Oh... that's strange... I always need to seek by exactly 132 bytes to get
ts-packet headers to realign... can't be a coincidence!

hmm
Retired, working interesting problems

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Overall, there seems to be six sections of correctly-sized ts-packets:

1st_ofs - offset_of_last_recognizable_ts_packet_header
0000000 - 0037acc
00381ec - 00d6e20
00d7250 - 0215c58
0215cdc - 0356ae0
0357378 - 03dbe8c
03dd16c - 04460f0
04461aa (eof, last packet is two bytes short)

Between each section is a block of few hundred bytes.
Its size is always N*188 + 132. ???

I can "repair" the file by padding each section so that its size is a multiple of 188,
and then repair ts-packet headers: it's easy te determine whether the packet is
a null packet or payload packet, and then fix headers to be either
4703e81x or 471fff1x.

Will this be useful in any way?
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.

But actually it's good to have a raw_aligned.ts where only this is fixed by padding 5 times 56 bytes with FF.

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
The script to cut up raw.ts into sections with 188-byte ts-packets.
The last two commands prove that concatenation of sections is the same as raw.ts (both have 042433dfc39c70a51203fae581a5461f md5sum).

#!/bin/sh
mk_sect()
{
        local start=$1
        local end=$2
        dd bs=1 skip=$(($start)) count=$(($end - $start)) <raw.ts >$3.ts
        cat section?.ts >z.$$
        hexdump -s $(($start)) -v -e '"%07.7_ax " 188/1 "%02x" "\n"' <z.$$ >$3.hex
        rm z.$$
}
# 1st_ofs - offset_of_last_recognizable_ts_packet_header
# 0000000 - 0037acc
# 00381ec - 00d6e20
# 00d7250 - 0215c58
# 0215cdc - 0356ae0
# 0357378 - 03dbe8c
# 03dd16c - 04460f0
# 04461aa (eof, last packet is two bytes short)
#
# It is not obvious where exactly realignment happens.
# What can be seen is where the last packet with "old" alignment is,
# and where is the first recognizable packet with "new" alignment is.
#
rm section?.ts
mk_sect 0x0000000 0x00381ec section1
mk_sect 0x00381ec 0x00d7250 section2
mk_sect 0x00d7250 0x0215cdc section3
mk_sect 0x0215cdc 0x0357378 section4
mk_sect 0x0357378 0x03dd16c section5
mk_sect 0x03dd16c 0xfffffff section6
cat section?.ts | md5sum
cat raw.ts | md5sum

Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
The script to cut up raw.ts into sections with 188-byte ts-packets.
The last two commands prove that concatenation of sections is the same as raw.ts (both have 042433dfc39c70a51203fae581a5461f md5sum).

#!/bin/sh
mk_sect()
{
        local start=$1
        local end=$2
        dd bs=1 skip=$(($start)) count=$(($end - $start)) <raw.ts >$3.ts
        cat section?.ts >z.$$
        hexdump -s $(($start)) -v -e '"%07.7_ax " 188/1 "%02x" "\n"' <z.$$ >$3.hex
        rm z.$$
}
# 1st_ofs - offset_of_last_recognizable_ts_packet_header
# 0000000 - 0037acc
# 00381ec - 00d6e20
# 00d7250 - 0215c58
# 0215cdc - 0356ae0
# 0357378 - 03dbe8c
# 03dd16c - 04460f0
# 04461aa (eof, last packet is two bytes short)
#
# It is not obvious where exactly realignment happens.
# What can be seen is where the last packet with "old" alignment is,
# and where is the first recognizable packet with "new" alignment is.
#
rm section?.ts
mk_sect 0x0000000 0x00381ec section1
mk_sect 0x00381ec 0x00d7250 section2
mk_sect 0x00d7250 0x0215cdc section3
mk_sect 0x0215cdc 0x0357378 section4
mk_sect 0x0357378 0x03dd16c section5
mk_sect 0x03dd16c 0xfffffff section6
cat section?.ts | md5sum
cat raw.ts | md5sum

Just a note. Dump any code-like text into
[code]
[/code]
blocks
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
And after this, it's instructive to check what kind of packets do we have there?

grep . section?.hex | sort -t' ' -k2

There are lots of data and null packets, of course, but also there are:

474000xx packets:

section3.hex:00e7da0 474000100000b0110000c100000000e0100001e020d36af0acfffffffff...
section3.hex:01c2c98 474000100000b0110000c100000000e0100001e020d36af0acfffffffff...
section4.hex:028cae4 474000100000b0110000c100000000e0100001e020d36af0acfffffffff...
section4.hex:0353f8c 474000100000b0110000c100000000e0100001e020d36af0acfffffffff...
section6.hex:04065a0 474000100000b0110000c100000000e0100001e020d36af0acfffffffff...

474020xx packets:

section3.hex:00eab28 474020100002b01f0001c10000e3e8f00010e3e8f0031b01f580e3e9f00081e3f3f0003f64f115ffff...
section3.hex:01c6468 474020100002b01f0001c10000e3e8f00010e3e8f0031b01f580e3e9f00081e3f3f0003f64f115ffff...
section4.hex:029d868 474020100002b01f0001c10000e3e8f00010e3e8f0031b01f580e3e9f00081e3f3f0003f64f115ffff...
section6.hex:0408768 474020100002b01f0001c10000e3e8f00010e3e8f0031b01f580e3e9f00081e3f3f0003f64f115ffff...

0x40 bit is Payload Unit Start Indicator. I have no idea what's that,
but it has quite easily recognizable bit pattern in the payload.
Meaning: it's easy to detect such packets and fix their headers even
if it's severely corrupted.

And the 474000 + 4703e8 combination also exists:

section2.hex:004817c 4743e8300710002b495d7e00400181e00000818007410019d755ffff000001b6597...
section2.hex:00ae4f0 4743e8300710002c9d8c7e00000001e000008180072101652811ffff000001b658c...
section3.hex:0117d0c 4743e8300710002df1bb7e00000001c000c081800721016f78cdffff000001b0030...
section3.hex:011bdac 4743e8300710002dfd767e00000001e0000081800721016fa7b9ffff000001b658c...

The 30 byte is "Adaptation field exist" bit 0x20 set in addition to the usual "Payload present" 0x10 bit.

Looking for less obvious "unusual" packets, "Adaptation field exist" bit seems to be present
in some payload packets too. They are visible because they have a bunch of FF bytes
in the beginning:

section3.hex:017cbf0 4703e8300b00ffffffffffffffffffff843695a94aad38fbed264a01a2503272de7134078280741e03f93613ff2abc4e935...
section1.hex:000183c 4703e8301a005ffffffffffd7fffffffffffc7ff6ffffffffffffffffffffffffffffffff5ffc3ffffffffffffffff18211...

Note 4703e83x header instead of more typical 4703e81x.
It's not a one-bit corruption because there are a number of these,
they all have ...ffffffffff... at the start of their payload.
"Usual" data packets don't.

Offline mvpel

  • Full Member
  • ****
  • Posts: 1125
  • New Hampshire
  • Liked: 1303
  • Likes Given: 1685
I can "repair" the file by padding each section so that its size is a multiple of 188, and then repair ts-packet headers: it's easy te determine whether the packet is a null packet or payload packet, and then fix headers to be either 4703e81x or 471fff1x.

Will this be useful in any way?

I think you don't want to force all headers to either of those two values - I think we would just want to clear the TEI and the scrambling bits only, and make a 0x471FFFX into a 0x471FFF1. There appear to be instances where the adaptation field and payload unit start bits are significant.
"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 gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
Trivial script to concatenate sections with padding, so that every ts-packet is 188-byte aligned:
{
cat section1.ts; dd bs=56 count=1 </dev/zero
cat section2.ts; dd bs=56 count=1 </dev/zero
cat section3.ts; dd bs=56 count=1 </dev/zero
cat section4.ts; dd bs=56 count=1 </dev/zero
cat section5.ts; dd bs=56 count=1 </dev/zero
cat section6.ts
} >aligned188.ts
hexdump -v -e '"%07.7_ax " 188/1 "%02x" "\n"' <aligned188.ts >aligned188.hex
« Last Edit: 05/11/2014 06:54 pm by gospacex »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
An improved version of the annotated iframe8 with many more common dirt spots I see in several other iframes.
They seem to be very useful for further aligning MB's in other iframes
I truly believe that in the long run this is gonna help us enormously.

Thank you Jakusb. Incredibly good!

Offline gospacex

  • Senior Member
  • *****
  • Posts: 3024
  • Liked: 543
  • Likes Given: 604
First cut at ts-packet fixing tool.
How to use:

(0) compile: gcc -Os -Wall fix_tspackets.c -o fix_tspackets
(1) run cut_188byte_sections.sh.txt (cuts raw.ts into sections)
(2) fix a section:

$ ./fix_tspackets -o 0x03dd16c section5.ts section5-1.ts
Loaded 2917 packets
03ea430: 4740001x packet (h:47400011 diff:0.000000)
03f0b00: 4740001x packet (h:47400012 diff:0.000000)
03fd08c: 4740001x packet (h:47800013 diff:0.000000)
03fd08c: fixing header from 47800013 to 47400013
03fd08c: fixing payload
0408d48: 4740001x packet (h:47400014 diff:0.000000)
0410094: 4740001x packet (h:47400015 diff:0.000000)
0424a50: 4740001x packet (h:47400017 diff:0.000000)
042947c: 4740001x packet (h:46000018 diff:0.083333)
042947c: fixing header from 46000018 to 47400018
042947c: fixing payload
0437188: 4740001x packet (h:47400019 diff:0.000000)
0445764: 4740001x packet (h:4740001a diff:0.000000)
044e230: 4740001x packet (h:4740001b diff:0.000000)
045e9d4: 4740001x packet (h:4740001c diff:0.000000)
045e9d4: fixing payload
Saved to 'section5-1.ts'

(-o OFFSET is cosmetic: it adjusts packet offsets so that they can match raw.ts)

(gosh... I need to add .txt to attachments for them to be posted. strip it...)

Tags:
 

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