[Discuss-gnuradio] Re: ffff... in transport stream

[John Gilmore]

> Looking at both Eric's transport stream and John's using a hex dump
> program, I see fairly long sequences of the byte 0xff (all bits equal to
> 1).  Is this normal?  Does it represent transmitted data in the
> transport stream, or is it possible that it represents something
> missed by the demodulator?

MPEG transport streams are fixed-length 188-byte packets.  Each packet
is mostly filled with padding, unless very high resolution pictures
are being sent.  Remember, this is a 20 Mbit/sec data stream, and all
but the highest resolution video occupies much lower data rates.  So,
if they aren't sending two or three or four channels of video down,
there'll be a lot of padding bytes.

The demodulator is way too complex to "miss" things and fill them with
FF's.  What you get has been through two levels of error correction
and some hairy bit-multiplexing; the decoded data is not even remotely
in the same order as the signal samples that came in.

There are field sync bytes that have to come along every so often, or
the decoder realizes that it's lost sync with the transmitter and starts
looking for them again.  You might get some dummy data while it's looking,
I haven't looked at that part of the code recently.

        John