[opendtv] Re: Analog v Digital TV
- From: "Allen Le Roy Limberg" <allimberg@xxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 15 Jan 2007 20:00:05 -0500
The redundancy is in the 2/3 trellis coding of MPEG-2 data packets, which
makes 8VSB performance on all-white Gaussian noise slightly better than
4VSB, and in the (207, 187) Reed-Solomon coding, which adds 20 parity bytes
to the 187-byte MPEG-2 data packet to improve burst error performance.
A-VSB uses turbo coding to add further redundancy.
----- Original Message -----
From: "Craig Birkmaier" <craig@xxxxxxxxx>
To: <opendtv@xxxxxxxxxxxxx>
Sent: Monday, January 15, 2007 8:57 AM
Subject: [opendtv] Re: Analog v Digital TV
> 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.
>
----------------------------------------------------------------------
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: