Today I have done a low-level analysis of the raw.ts file. Most notably the "Transport Stream Headers" (see http://en.wikipedia.org/wiki/MPEG_transport_stream
While it is bad, its not as bad as is being suggested above. The raw file consists of 23,838 ts-packets (containing 188 bytes each). Each one of these has a 4-byte header. These should always begin with the hexadecimal value "47". Of these 23,838 headers the following are correct:
4703e8: 15,014 times
471fff: 4,966 times
4743e8: 263 times
474000: 81 times
474020: 74 times
The actual video-packets have the code "4703e8" and as you can see there are quite a lot of them! And they contain a LOT of data.
The code "471fff" identify the so called null-packets and these contain a lot of FF's. But this is totally normal. Since they are "used for fixed bandwidth padding".
The other correct packets are basicly overhead. I will not go into them. But they are essential for the video working. There are a lot more than shown above btw.
The problem lies in the remaining bad
headers (still several thousand): they get ignored by the video-player which causes it to act strangely. Also: a lot of bits (not just in the header but also in the content) are flipped. But my hope is that this is not the biggest issue: mpeg-4 is quite resilient.
I'm trying to figure out if I can "repair" most of the headers so the video player can at least decide what to do with the data in it (now it will just ignore it because they have the wrong PID, invalidating valid packets in the meantime).
This however is no simple task.