WSS data not present when Videocrypt is enabled

[philpem]

I noticed that with VideoCrypt scrambling enabled, line 24 was being passed through as clear video, while all other lines were scrambled.

Upon further investigation, I noticed that videocrypt.c includes a "hack for WSS signalling":

https://github.com/fsphil/hacktv/blob/e03945bc01d1dc4fa93569e2f84e16362864a215/videocrypt.c#L481

This allows line 24 to pass through the VideoCrypt encoding process unmodified -- but WSS data is carried on line 23. The net effect is that:

• The WSS data on line 23 is clobbered by the encrypted line 24 (due to the VideoCrypt encoder compensating for the decoder's 1-line decryption delay)
• Line 24 is passed through as-is -- the VideoCrypt decoder decrypts this onto line 25, scrambling it.
• Lines 25 onwards are encrypted correctly.

This means WSS will not work in conjunction with VideoCrypt.

If the "if" statement is modified to check for line 23, the following happens -- at least with the Thomson/Sky SVA1:

• WSS on line 23 is passed through verbatim by the descrambler
• The VideoCrypt descrambler "decrypts" line 23 onto output line 24
• The first actual encrypted video line -- line 24 -- is correctly descrambled onto line 25.

This sounds closer to the intended behaviour, and TVs checking Line 23 should ignore the scrambled WSS data on line 24. If the TV is adjusted to eliminate overscan, the WSS data will appear (in scrambled form) as the first complete line of the picture.

[fsphil]

Looks like I broke this when I introduced the new process functions. Fix applied.