[opendtv] Re: Analog v Digital TV
- From: Craig Birkmaier <craig@xxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Mon, 15 Jan 2007 08:57:27 -0500
At 6:30 PM -0500 1/14/07, Tom Barry wrote:
Albert Manfredi wrote:
Agreed, Tom. I was taking issue with your "no extra info is sent."
You send redundant info, so that even though MPEG encoding deleted much
of this redundancy info from the image itself, your FEC schemes put it
back in.
Yes, darn it, we agree you send some redundant info. (I am doing it
now ;-) ) I was both originally, and still, saying and agreeing
that no extra info is magically conjured up ("provided") on the
receiving end that was not sent, at least in aggregate. Glad we
have that cleared up.
Obviously the issue is not cleared up. Once again Bert is smokin some
good stuff.
The MPEG encoded bit are what they are. There is no redundancy or
error correction in the encoded bits. The MPEG encoder produces four
main components of the image that the decoder uses to reconstruct the
image:
1. I - frame DCT coefficients - These can stand on their own allowing
the decoder to reconstruct the anchor frame in the GOP. The encoder
quantizes the DCT coefficients and sends what is left, nothing more.
Think of this as a data file. THERE IS NO WAY TO MAGICALLY SEND
ADDITIONAL COEFFICIENTS AS PART OF ANY ERROR CORRECTION SCHEME. Any
downstream processing can only use the bits in what's left of that
"file," in an effort to reproduce it as accurately as possible.
2. Motion vectors - these are used by the decoder to reconstruct
other frames. These too are "data files" which carry the motion
vector information. Again, there is no error correction in these
files. Any downstream processing can only use the bits in that
"file," in an effort to reproduce it as accurately as possible.
3. DCT coefficients carrying the differences between the I frame and
the P frames that are included in the GOP. These coefficients may
also be quantized by the encoder. These too are "data files" which
carry DCT coefficient information. Again, there is no error
correction in these files. Any downstream processing can only use the
bits in that "file," in an effort to reproduce it as accurately as
possible.
4. DCT coefficients carrying the differences between the actual B
frames and the predictions of the B frames produced by the decoder.
These coefficients may also be quantized by the encoder. These too
are "data files" which carry DCT coefficient information. Again,
there is no error correction in these files. Any downstream
processing can only use the bits in that "file," in an effort to
reproduce it as accurately as possible.
Obviously there is additional information about the encoded frames
that is delivered (size, aspect ratio, frame rate etc.). In other
words, more data. All of these bits are wrapped up in an MPEG
transport stream. Within THAT stream there may be redundancy bits,
pad bits to fill out the packets etc. BUT THERE IS NO ADDITIONAL
INFORMATION THAT CAN IMPROVE THE PICTURE.
Anything downstream in an ATSC transmission is error protection with
the sole purpose of trying to get the data in the files I described
above to the decoder in the receiver with the lowest number of errors
possible. IF you can receive the ATSC transmitted bits perfectly, you
can reconstruct the MPEG video stream at the same level of accuracy,
as a decoder that is connected to the output of the encoder ( i.e. NO
CHANNEL ERRORS).
IN AN ATSC TRANSMISSION THE VIDEO QUALITY CANNOT BE ANY BETTER THAN
WHAT WAS ORIGINALLY PRODUCED BY THE ENCODER, BUT IT CAN BE
SIGNIFICANTLY WORSE.
Error Protection is there to deal with the fragile nature of the
transmission channel. And this error protection actually reduces the
delivered image quality.
WHY?
Because any overhead for error protection that is used in the
transmission channel reduces the payload available to the encoder for
image data. If you use 2 Mbps for error protection that is 2 Mbps
that cannot be used for image data. All of the cool stuff in A-VSB,
is there for only two purposes:
1. To help the equalizer in the receiver lock to the stream better.
2. To protect/correct channel errors.
The result is that the payload for the image data is further reduced.
Regards
Craig
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
