www.techmind.org logo
by W.A. Steer  PhD


This page outlines an image-processing algorithm for high-quality reconstruction of individual frames of television pictures scrambled using the VideoCrypt system.


The VideoCrypt system is widely used in the broadcast of (analogue) satellite television, and basic details are easily available elsewhere on the web. Essentially, the active-picture part of each raster line is 'cut' at a postion determined by a pseudo-random number generator, then the line is wrapped around horizontally so that the picture from adjacent to the cut is transmitted at the left/right edge of the image. For example:
 Original picture line:     abcdefghijklmnopqrstuvwxyz
    cutpoint:                                  ^
 Transmitted as:            tuvwxyzabcdefghijklmnopqrs
Regular set-top-boxes combine extra transmitted codes with cryptographic information held on the subscribers smart card to regenerate the cutpoint sequence and reconstruct the picture in real time.

Back in 1994, Markus Kuhn released a demonstration-of-concept program called antisky.c which used FFT to perform inter-line correlation to reconstruct such pictures empirically. Markus' program however worked on images obtained using standard PC video-capture cards and at arbitrary resolutions/scan rates. By contrast, my goal has been to achieve 'perfect' (glitchless, colour) decoded images, using whatever is required. I started from raw composite-video images and worked out a little more quantitative information about the system, and implemented software accordingly. Because the PAL colour system is phase-sensitive, the picture has to be reconstructed as well as with a proper decoder to enable the colour to be resolved.


It is widely known that domestic set-top-boxes sample the video signal at 14MHz, so that seemed a good starting point. Also that there are only 256 possible cutpoints per line, and further that these cutpoints don't occur within ~15% of a picture-width of the left/right edges of the image.

Figure 1: VideoCrypt scrambled composite-video image

By a good guess, supported by observation, it was then determined that the cutpoints all fall on 1/(7MHz) intervals (ie even pixel boundaries).

Study of the images revealed duplicated information at the edges, and it was fairly straightforward to deduce that there are exactly 710 non-repeated pixels of scrambled image.

A slightly fuller description of the coding is thus:

 Original picture line:     __abcdefghijklmnopqrstuvwxyz_    [ _ = back/front porch, ie black level ]
    cutpoint:                                    ^
 Transmitted as:            __astuvwxabcdefghijklmnopqrs_
noting that the first part, 'a', is not scrambled (prevents giveaway porch/black being found withing the scrambled section), and that section 's' is duplicated at both ends of the line (giving some decoder timing tolerance, preventing glitches in the reconstructed picture). Inevitably this means that a little of the original picture, 'yz', has to be discarded.

My algorithm starts by filtering out the PAL subcarrier to leave the luminance-only information, then rotates each line by all 355 possible steps relative to the previous line, and calculating a 'square difference' tally for each (with some short-circuits for speed). Except in very tricky circumstances, the best fit occurs at the correct step, plus or minus one. At this point, the chrominance component is referred to - a kind of fine-tuning: on alternate lines within a field (assuming no change of colour), the PAL coding is 180 degrees out of phase. This enables the best fit to be narrowed down to precisely the right step.

Having worked through all the lines of the picture, assuming the process was successful, the result at this point is now a pixel- perfect image, but with a 'net roll' in the horizontal sense. A very quick analysis of the cutpoints shows a big gap, roughly the centre of which represents to right/left boundary in the picture.

Given 288 lines with random cutpoints between 0 and 255, the odds of the leftmost cut actually used in that field being at the leftmost possible, ie 'cut zero', is quite high (~66% if truly random).
[I am still working on fixups for the other 33% of the time!!!]

The whole pic is then rolled around accordingly. 'Cut zero' actually requires a roll of 50 steps (100 pixels).

You may have noticed that in a VideoCrypt'ed image the scrambled section is one-line above the non-scrambled bit at the edge. It was empirically determined therefore that post-descrambling, the unjumbled part needs to be lowered one line. This makes sense in terms of the simplest hardware decoder design (rotate+delay lines) anyway. This was doubly confirmed when I found that it is also required to get the correct PAL burst which corresponds with the picture data for correct colour decoding. Finally the descrambled picture needs to be shifted leftwards by 8 pixels to get alignment with the unscrambled bit at the left and for perfect PAL phasing.


Figure 2: Descrambled composite video image

The whole process above takes just 4 seconds on a 233MHz PentiumII under Windows NT4.

I can then save the image and then colourise it using my PalColour program, described elsewhere on this website (3 seconds).

Figure 3: The coloured and geometrically restored final image: 'As Good as it Gets'

As it now stands, my program gives perfect results on about half of the 50-odd sample images I have. The rest still exhibit one or two correlation glitches, or a region which wanders. With more development, no doubt success rate could be improved even further.

Examples of failure

There are several distinct failure modes with the present software: I have some strategies in mind for dealing with the above. In general though they are non-trivial, and computationally time consuming. It will simply not be possible to cope with all eventualities with this type of approach, however.


While this is an interesting area for study, and the results are very satisfying, I don't feel it represents a major threat to the satellite companies' revenue stream owing to the fact that the method would still need to be 100 times faster for real-time processing, and because such an empirical technique can never be 100% successful on all images! Furthermore, the days of analog/VideoCrypt DBS are numbered, with the companies concerned rapidly rolling out new 'digital' services.

The results illustrate what was achieved with about 10 hours programming effort after receiving my first VideoCrypt'ed images. Unfortunately having spent at least as much time again since then, little further progress has been made. This has a lot to do with the 'law of diminishing returns', other things on my mind, and the fact that to a fair extent the original goal has been reached.

Update: 24th July 2000

By eliminating the duplicate effort in recalculating the luminance/ chrominance, and removing all remaining modulo-operators in the deeper loops, and other minor miscellaneous optimisations, my program now does a typical descramble in 1.0 seconds!!! [PII-233/WinNT4]

Integral PAL-colour decoding implemented: descramble-and-colour in around 1.4 seconds on machine of above spec!

[Update: 2002 - a 2GHz PC running exactly the same program can decode-and-colour images in about a quarter of a second. Suspect that with handcrafted machine-code a real-time software solution is within reach... though an FPGA may be a better strategy. However I have no interest in expending any more effort on this problem!]

[Image quality/correlation-reliability has not been significantly changed.]


Grateful thanks are due to Chris Maw of New Zealand who inadvertently provided the initial stimulus for this work, and subsequently kept me supplied with a stream of images to my specifications!


Please do not email me about the content of these pages, or for further information. I do not intend divulging any more detailed information, or software, at the present time.
Content last modified: 24 July 2000
Cosmetic changes: June 2002

Source: http://www.techmind.org/vdc/

©2001 William Andrew Steer