by W.A. Steer PhD
About...
by W.A. Steer PhD
About...
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.
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.
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.
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.
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.]
©2001 William Andrew Steer