After all your visits to the pub in the previous episode you taught yourself that
the most efficient way of encoding your message results in a message where every
transmitted bit carries the highest amount of information possible.
But can you define such a code, and use it to transmit a digital television
picture?
Yes you can.
You can use a process called Huffman coding. This coding method produces an
optimally compressed version of the original data message. Every time you use
a zip file to download a data file across the internet, you are using the principles
of Huffman coding.
The fascinating bit about Huffman coding is that the actual encoding rules
employed to process your input message will change from message to message!
When I say this I don't just mean that you should use a different coding method
for transmitting a football match compared with the method you should use for
transmitting a news bulletin. I mean that two different football matches (or
even the same football match shot from slightly different camera angles) will
each require a different coding method, simply because the message you wish
to encode is different.
The Huffman coding process works by reading the entire message first, symbol
by symbol, calculating the probabilities of receiving each of the symbols within
it, then encoding these symbols in a completely new way, based solely on the
probability of each symbol occurring. The most common symbols are given very
short codes, and the rarest are assigned the longest codes. This results in
a message where every transmitted binary digit carries the maximum possible
amount of information.
Unfortunately, you need to know the entire message contents before you can
encode and transmit it! This is not the ideal way to transmit a football match
- the game would have to be over before you could even start transmitting it.
There are other flaws with this approach too.
You already know that no part of your encoded message should be predictable
at the receiving end of the link, because predictable data carries no useful
information. Every single data bit you transmit should be totally unexpected.
Huffman compression fails on this criterion, because it does not discard predictable
data from the messages you send. It just codes any predictable portions in the
most compressed way possible.
Huffman coding is a lossless method of coding, nothing in the message is discarded,
which is ideal for compressing computer binaries for internet transmission,
but is it the best technique for video?
Imagine you are transmitting colour bars and a caption, something very frequently
seen if you are a satellite feed hunter! You encode the signal using the Huffman
compression algorithm, so that the transmitted data contains the highest amount
of information possible per transmitted bit.
But it doesn't take you very long to notice that there is an incredible amount
of predictability about the signal your viewers are receiving. For example,
if they have just decoded a red pixel in the bottom area of the screen it doesn't
take much of a genius to guess what the next pixel is going to be!
As if this was not bad enough - the entire image stays the same for hour after
hour after hour after hour. So rather than receiving the highly unexpected data
that you hoped for, you seem to have got a message that is just the reverse;
despite your efforts in coding it in the most efficient way you could!
But you learned what to do about this when you were worried about the possible
beer drought at the pub. You only need to transmit the changes, both within
each picture in the sequence of pictures that make up your broadcast, and between
the current picture and the next.
What you need is a lossy method of encoding your video signals, so you only
transmit the changes in your video signals rather than the original signal.
But you still have some problems!
What happens to people who tune in to your channel some time after you have
started your transmission? You can't simply tell them that the current picture
is the same as the all the previous ones, because they didn't see any of the
previous ones!
So it looks like you are going to have to repeat your message after all - just
to accommodate the people who have only just tuned in. But this was the very
thing you were trying to avoid doing!
On the other hand, what happens if your moving picture transmission really
is a tale of the totally unexpected? A sports event, with thousands of agitated
waving, cheering spectators in the background who refuse to stay still, lots
of madly running, jumping, swerving sportsmen in the foreground, manic cameramen
who constantly pan and zoom about, trying to capture the most exciting action.
And if this isn't bad enough, there is a frantic director in charge of it all
who keeps on cutting from camera to camera and back again.!
The message from the pub technique doesn't work very well now, there isn't
very much in your data that you can throw away, it's just too full of changes.
You will just have to bite the bullet and throw some of this precious data
about the changes in your video signal away! And just hope nobody notices you've
done it!!
But you need to know which data you can throw away, and how you can cover up
the fact that you have done so with the best chance of getting away with it.
Could this be time to call on the services of the Motion Pictures Expert Group?
And why have we spent so much time looking at Huffman coding?
Will we ever see a proper mpeg article?
Who does this professor guy think he is anyway?
The Professor
|