[22:51 UTC]
[Fri, 19 Apr 2024]

 

"Veni, Vidi, Video."
 

[New OS Tracker]

Humax IRCI 5400 HIC-1.05.00 Plus CAM and ToH 3.0
[down. times]

Nokia MM 9800S MA 2.07-287A
[down. times]

Humax IRCI 5400 HIC-1.05.00 Plus CAM and ToH 2.3
[down. times]

Humax IRCI 5400 HIC-1.05.00 Plus CAM and ToH 2.2
[down. times]

Humax IRCI 5400 HIC-1.05.00 Plus CAM and ToH 2.1
[down. times]


Know of a new OS not included here?
Mail US!


Tech and Mods

The tales of the unexpected [22 June 2001]


 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





 

 




Our Reviews in
foreign languages

Micronik TVBox 1200S [SDTV Polish:]

Digiquest P2000 [SDTV Polish:]

Digiquest P2000 [SatIL Hebrew:]

Samsung 9000 Via CI [SatIL Hebrew:]

Force DMaster 1122s [SDTV Polish:]

Force DMaster 1122s [SatIL Hebrew:]

Technisat Technibox Cam 1 Plus [SatIL Hebrew:]

GbSat 2CI 20 [SatIL Hebrew:]


[SatTrack News]

Last change:
[14 September 2008]
by Digis@t






(...Click below for more)

[Lead me to your]
[DX section NOW]


 
www.satcritics.com | © SatCritics 2001-2012 | www.satreviews.com