[opendtv] Re: Analog v Digital TV

  • From: Tom Barry <trbarry@xxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Sun, 14 Jan 2007 18:30:31 -0500



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.

>Al Limberg mentioned this some time ago. As of now, receivers use the RS
> code in regular 8T-VSB to fix up to 10 messed up bytes in any 188-byte
> data block, using its 20 check bytes. But if receivers could use the
> results of the Viterbi decode process to localize where in the MPEG-TS
>block the errors occurred, instead of having the RS decode perform that
> localization function, then you should be able to fix 20 messed up bytes.

Actually the difference between approaching 10 messed up bytes or 20 as a limit is whether you are using an error correcting code or an erasure code, like I mentioned in my example. The simpler erasure code at first seems more efficient because it only works if you already know which bytes/blocks/symbols are bad, using some other means. But those other means also take bits somehow. However in many cases (most Internet) that information is more or less reliably available.

- Tom





Tom Barry wrote:

I think we are just talking around each other here, with maybe no
disagreement. I said error correction never "provides" new information
but meaning that sufficient bits of extra information have to be sent
("provided") by the sender, not mathematically created somehow at
the receiving end. The sent extra information is the redundancy that
all schemes include so you can calculate the values of any missing bits.

Reed-Solomon is a good example, say a simple erasure code. There,
for each group of so many symbols you can add a few extra ones,
with carefully calculated redundancy. If you drop a few symbols, say
n, in delivery you can make up the complete group as long as you
have sent an equal number n of redundant symbols (not just
duplicates). But you still have to plan ahead to send a sufficient
number (at least n) of extra ones to match the max number the
receiver might miss.


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.

Al Limberg mentioned this some time ago. As of now, receivers use the RS code in regular 8T-VSB to fix up to 10 messed up bytes in any 188-byte data block, using its 20 check bytes. But if receivers could use the results of the Viterbi decode process to localize where in the MPEG-TS block the errors occurred, instead of having the RS decode perform that localization function, then you should be able to fix 20 messed up bytes.

And this sort of computational tweak should be able to be enhanced even more, perhaps with multiple passes, to finally arrive at the corrected block. Every time you improve this FEC system, you get closer to the Shannon limit.

So even though we can receive "perfect" images today (for 19.39 Mb/s of payload), with something around 15 dB of C/N, there's no reason to think this is a hard limit.

Bert

_________________________________________________________________
Your Hotmail address already works to sign into Windows Live Messenger! Get it now http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview



----------------------------------------------------------------------
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.



--
Tom Barry                       trbarry@xxxxxxxxxxx     
Find my resume and video filters at www.trbarry.com


----------------------------------------------------------------------
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: