GB2251528A - Improvements in digitally-assisted television systems - Google Patents

Abstract

In a digitally-assisted HD-MAC system, the digital assistance data relating to blocks of pixels is encoded by an encoding method which is of a type which produces a variable number of bits per frame. Preferred methods comprise simple, linear or complementary quadtree coding, or a Peano scan with run-length coding. A Huffman code may be employed. If the number of bits produced exceeds the system capacity, the coding method reverts to a fallback mode in which, for example, the areas closest to the centre of the picture receive the greatest coding detail.

Description

INPROVEMENTS IN TELEVISION SYSTEMS This invention relates to television systems in which a television signal is transmitted which comprises picture information at a normal level of definition and, in a non-active-picture part of the signal, additional coded digital information representative of further picture detail. A normal definition receiver receives and displays the picture at the normal level of definition. A high definition receiver receives the picture at the normal level of definition, also receives and decodes the additional information, and modifies the normal definition picture on the basis of the decoded additional information, to give a picture which is displayed at a higher definition.

Such a system is known as a digitally-assisted television (DATV) system and the signal transmitted is a DATV signal.

In one proposed type of system, DATV information is transmitted on a block-by-block basis. Each block is an area of the picture comprising a plurality of pixels. The encoding system may comprise a plurality of branches; the branch to be used for each block is chosen in dependence upon the picture content and movement so as to provide optimum quality of the displayed picture at the decoder/receiver. The branch decision information is contained in the transmitted DATV data so as to enable the decoder to decode the transmitted signal properly.

Each block may also have an associated motion vector indicating picture movement associated with that block. The vector may be transmitted as a reference or index number rather than by its full description; a menu of vectors then being transmitted periodically. For further information reference should be made to IEE Conference Publication No. 293 (IBC '88), see especially pages 62-65, which describes a high definition HD-MAC system using three branches and known as the P3 system.

The blocks should be kept as small as possible, since a smaller size means an improved picture quality. The smaller the block size is, the better the block boundaries will fit (on average) to the edges of objects moving in the picture. This means there will be less "boundary effects" where some foreground pixels use the background vector or vice versa. A smaller block size means that the DATV bit rate will be higher, and there is a limit on the bit rate allowed for HD-MAC.

To counter this we propose a bit-rate reduction process which takes advantage of the fact that the DATV information will often be similar in neighbouring blocks. It is important to note that this process should describe the same data in a more efficient way; it should not alter it (so the decoded DATV information will be identical to the original information).

In one proposed format for DATV transmission which will fit within the allocated bit rate for HD-MAC (950 kbits/sec), the picture is divided into measurement blocks (also called menu blocks"), each of which is divided into assignment blocks. A measurement block has a menu of vectors associated with it.

Each assignment block has an index number. This corresponds to one of the choices on the menu and specifies the most suitable vector for that assignment block. Each assignment block also has a "branch decision" number which specifies which branch the coder has selected for the block. In practice the branch decision numbers and assignment data index numbers may be transmitted as two separate sets of data in the DATV information.

Table I (appended to this description) shows the size and number of blocks and the corresponding bit rates proposed, for the full HD picture and for the quarter-size pictures used during simulation. Note that almost all of the 950 kbits/sec allowed have been used. The "global" vectors are ones which apply to a complete picture rather than just one block. Each menu contains a selection from: a) the two global vectors, b) two vectors calculated for the current measurement block, c) the vectors calculated for the eight neighbouring blocks.

The rules governing which eight vectors are chosen are simple and are the same at the encoder and decoder.

As can be seen from the table, the majority of the bits transmitted are used to send the index number and branch decision information for the assignment blocks. We have appreciated that bit rate reduction would be useful if it could effectively be used to reduce this amount of data.

In the context of a DATV system as described above, this invention proposes improvements by which bit-rate reduction is applied to the DATV data in a way which takes advantage of the fact that the DATV information will often be similar in neighbouring blocks of the picture.

The invention in its various aspects is defined in the appended claims to which reference should now be made.

Preferred embodiments of the invention will be described by way of example with reference to the drawings, in which: Figure 1 is a diagram showing an 8 by 8 picture, and possible coding as produced by a Huffman data coding system; Figure 2 is a diagram showing an 8 by 8 pixel array, and how it is divided up in simple quadtree coding; Figure 3 shows how a "tree" can be constructed to represent the picture of Figure 2; Figure 4 shows a third order at 8 by 8 Peano scan superimposed on the same picture as Figure 2; Figure 5 is a block diagram or flow chart illustrating a possible fallback configuration.

Figure 6 shows possible disallowed and allowed combinations of branch decisions with a view to permitting smaller block sizes; Figure 7 illustrates the division of the picture into nine parts for supplementary quadtree coding; and Figure 8 is a block diagram of a supplementary coding system.

1. DATV CODING METHODS The coding methods to be described may also be used for encoding images; it is most effective if the image has only a few grey levels.

In the following description, to keep things simple, the words "pixels" and "colour" have been used in describing the algorithms. When coding an image they will mean what they say, but for coding of DATV information, "pixels" refers to DATV blocks, and "colour" means the information being coded; this might be vector values, menu index numbers or branch decisions.

1.1 Huffman Data Coding We have appreciated that this well known minimal-length code is particularly suitable for coding the menu index numbers used in the above-described DATV scheme. Analysis of the DATV data for several sequences has shown that on average about half of the blocks were assigned vector number 1 (the most popular vector in the measurement block), about a quarter took vector number 2, and so on (more exact figures are given below). A suitable coding is 0 for vector 1, 01 for vector 2, etc. (again see below).

As an example consider the 8 x 8 picture in Figure 1.

The four different colours refer to the menu vector index numbers. Using the Huffman coding given, the picture is encoded in 29 + 2 x 21 + 3 x 14 = 113 bits. This compares with 64 x 2 = 128 bits for the uncoded picture.

Coding may also be used for the branch decision values; for many sequences most of the picture may be coded with the same branch and this can be coded with a single bit, using longer codes for the other branches. The code can alter from frame to frame to reflect the changing motion content of the picture.

1.2 Simple Ouadtree The principle of quadtree coding is known from: (1) BUHLER Y. and FORTIER M., "Hierarchical picture coding using quadtree decomposition", SPIE Vol. 804 Advances in Image Processing, 1987.

(2) HENOT J.P., "Coding of motion information for high definition television", 2nd International Workshop on Signal Processing of HDTV, 29 February - 2 March 1988, L'Aquila, Italy, Vol.2.

Quadtree coding works by dividing the picture up into successively smaller quadrants, until all the pixels within each quadrant are the same colour. Then only the colour of each quadrant need be sent, together with information telling the decoder where the quadrant is. Different versions of quadtree coding use different methods of this information.

Figure 2 shows an 8 x 8 pixel picture and how it is divided up. Figure 3 shows how a tree can be constructed to represent this picture. A circle is a "node" and represents a region which is "inhomogeneous", i.e. parts of it are different colours. It will have four children: these are, from left to right the NW, NE, SW and SE subquadrants of the region. A square is a "leaf" and represents a homogeneous region, and the number in it gives its "colour4"; when coding a menu-based DATV signal this number could be the menu index number for the block which corresponds to this "pixel".

In the simplest quadtree algorithm (similar to that described in the Buhler and Fortier reference), the tree itself is represented as a series of bits. For a leaf (homogeneous region), a one is sent, except for where the region is only a single pixel as this is bound to be homogeneous. For a node (inhomogeneous region) a zero is sent, followed by the code for the NW, NE, SW and SE children in that order.So the code describing the tree for the example above is: (8 x 8 pixels): 0 (4 x 4 pixels): 0 ~ 10 0 (2 x 2 pixels): ~ 1110 ~ 0111~1111 By including the Huffman coded numbers for each homogeneous region (including single pixels) we can obtain the complete code for the picture: (8 x 8 pixels): o (4 x 4 pixels): 0 1 0 0 (2 x 2 pixels): 1110 0 1 1 1 1 1 1 1 (Region code): 0 0 0 10 0 10 10 0 111 10 111 10 10 111 10 10 10 110 110 In this, 55 bits are used to code the picture, as compared with 128 bits for the uncoded picture.

1.3 Linear Ouadtree An alternative method of describing a quadtree can be based on that described in: (3) SAMET H. and TAMMINEN M., "Computing geometric properties of images representing by linear quadtreel' 1EE Trans. PAMI-7, No. 2, March 1985.

This alternative method uses a code to identify each homogeneous quadrant, subquadrant or pixel, rather than the tree structure. As an example, consider Figure 2 again: The large white quadrant has the code: : NE x 1 The left hand half of the region with colour 3 is: SE SW x 3 The most northerly single pixel of colour 2 is : NW SE NW 2 The "compass points" uniquely identify the area. An x is required when the region is greater than 1 x 1 pixel to signify the end of the code.The number at the end of the code gives the colour of the area, in this way the whole picture can be coded as: NW SE NW 2, NW SE SW 2, NW SE SE 2, SW NW NW 4, SW NW NE 2, SW NW SW 4, SW NW SE 2, SW NE x 2, SW SW x 4, SW SE x 2, SE NW x 2, SE NE x 2, SE SW x 3, SE SE x 3.

Areas with colour 1 are background and these do not have to be sent. In fact for this particular case it would be more efficient to call colour 2 the background colour even though more pixels are of colour 1. We can use simple codes to send the compass points, e.g.: NW - 00, NE - 01, SW - 10 SE - 110, x - 111, and the colour index numbers, e.g.

2 - 0, 3 - 10, 4 - 11.

Because number 1 is no longer sent, there is no point in wasting the code 0 on it. Using this code the picture takes 121 bits to code, so it is not very efficient in this case, although other examples code considerably better.

1.4 Complementary Quadtree This is a refinement of linear quadtree which can lead to much improved efficiency, and is described in: (4). KIM Y. M. and PARK S.B. "New method for representing linear quadtree" Electronics Letters, January 1989, pages 137 to 139.

Each (inhomogeneous) node is given the colour which is dominant amongst its children, be they leaves or nodes. If there is no dominant colour, then the node is given the colour of the child spatially closest to its (the node's) parent. This rule is based upon the high probability of neighbouring pixels being the same colour. For example in Figure 2, the NW 4 x 4 quadrant is given colour number 1 and the SW 4 x 4 quadrant is given number 2. The numbers in the circles of Figure 3 show all these allocations.

After the nodes have been allotted colours, the picture is coded in a similar manner as in a linear quadtree, such that those nodes or leaves with a different colour to their parent are coded, and also the "root" node of the tree. From the tree, we see that this reduces the number of coded regions, and gives the following coding for the picture: x 1, NW SE x 2, NW SE NE 1, SW x 2, SW NW NW 4, SW MW SW 4, SW SW x 4, SE SW x 3, SE SE x 3 With the same coding for the compass points and the original coding for index numbers, the number of bits required is 80, better than the linear quadtree although not as good as the simple quadtree. The Kim and Park reference discusses the advantages of this method, the most relevant being that it supposedly becomes very efficient for large multi-valued trees.

1.5. Peano Run Length Our U.K. Patent Applications 2 193 411; 2 215 167 and 2 215 935 describe the properties of the Peano scan. Strictly, for the two-dimensional case this should be referred to as the Hilbert scan, but for convenience the better-known more general term Peano scan is used herein. The scan's property of usually traversing pixels which are close together in a short period of time leads to its suitability for run-length coding.

Figure 4 shows a 3rd-order (i.e. 8 x 8 points) Peano scan superimposed on the same picture as before. The form of the Peano curve tends to make it traverse large areas of one colour at a time. By sending the length of each "runt in scan points, and the colour of the run, we can efficiently code the picture.

In this example, the transmitted run lengths and index numbers are: Run length : 6 10 8 8 21 3 8 Index number: 4 2 3 2 1 2 1 Using simple 8-bit codes for the run length and the usual code for the index number, the number of bits used is 7 x 8 + 14 = 80 (the same as for the complementary quadtree coding). By also coding the run lengths the coding efficiency can be improved. Shorter run lengths should be given shorter codewords; one can afford to use a relatively large number of bits to code a long run because there will be relatively few of these in the picture.

2. IMPLEMENTATION The quadtree algorithm and Peano scan are well suited to square pictures whose sides are a power of two (e.g. 64 x 64 pixels). However the DATV scheme described in the introduction has 45 x 36 (assignment) blocks per picture, which is rather an awkward size. There are several possible ways of using quadtree or Peano coding with such a size; three of these are: a) Create a square picture (64 x 64) which includes the picture to be coded, and fill in the extra area (19 wide at the right of the picture and 28 high at the bottom of the picture) with a code which tells the coding algorithm to ignore data in this area. (What in fact may happen is that the quadtree encoder temporarily "assigns" a value to each block in the "border" area if this will keep a region homogeneous, and the Peano coder does the same if this will "keep a run going").

b) Divide the picture to be coded up into smaller square sections (with sides a power of two), each of which is coded separately. This method would not be very helpful with a 45 x 36 picture unless also combined with a) above by creating extra area around some of the small sections. One possibility would be to divide the picture into nine squares, each 16 x 16, requiring a strip 3 wide to the right of the picture and 12 high to the bottom of the picture.

c) Modify the quadtree algorithm to divide a region up into a different number (i.e. other than four) of subregions. The number of regions might vary at each level of the tree. A possible set of subdivisions for a 45 x 36 picture would be: 5 x 4, then 3 x 3, then 3 x 3; this would complicate the coding of the tree significantly. Similarly modify the shape of the Peano scan to suit the picture size (this is not always easy).

Method a) is preferred, this is the simplest method, thus reducing complexity at the decoder, and the number of wasted bits caused by the redundant area is small.

2.1 Simple Ouadtree Coding In one example a 64 x 64 quadtree is coded using the code of Table II appended to this description. A menu index file is converted into a picture file and then coded into a picture stream. The "value" bits are, as described above (Section 1.2) interleaved between the "tree" bits where homogeneous areas have been identified. Alternatively separate "value and "tree" outputs can be provided by the coder. The block branch decisions as output from the so-called Philips P3 bandwidth reduction system (see the IBC '88 paper mentioned above) can be separately coded using the code: 40 ms branch - 0 20 ms branch - 10 80 ms branch - 11 2.2 Linear Ouadtree Coding It might be expected that this algorithm would yield poorer efficiency than complementary quadtree coding.The codes used to describe the "region" and "value" are given in Sections 1.3 and Table 11 respectively. Again the "value" bits for a region appear immediately after the region code bits.

2.3 Complementarv Ouadtree Coding This used the same codes as above, together with the principle of defining the "colour" of nodes to reduce the number of codes to be sent.

2.4 Peano Run Lenqth Coding A Peano scan generating routine can be used to produce a 64 x 64 scan; a single bit stream with alternate run length and value codes being produced. Table III appended to this description shows possible codewords used to code the run lengths, the value code being the same as before.

3. EFFICIENCIES OF ALGORITHMS 3.1 Coding Vector Index numbers The results are summarised in Table IV for three different picture sequences. Variations on the algorithms (such as using different codebooks or different versions of the Peano scan) are not included. Particular attention was paid to the results with the PRLCAR sequence which is a sequence with a great deal of motion, and severely tests the coding algorithm.

The table shows that the simple quadtree gave the best results. It reduces the number of bits transmitted by almost half in the worst case. Peano coding follows closely behind.

Complementary quadtree coding did not perform as well as was hoped and certainly did not justify its extra complexity. Linear quadtree performed still worse (as expected). Finally raster run-length coding (tried as a comparison) was not as efficient as Peano coding, again as expected.

3.2 Coding Branch Decisions With selected combinations of sequences and branch coding algorithms, results with RENATA gave coding efficiencies of 4.9 for simple quadtree and 4.7 for Peano run length coding (i.e. slightly worse than for the index numbers).

4. SMALLER BLOCK SIZES 4.1 Initial Methods By coding the DATV information more efficiently, one can use a smaller block size when assigning vectors; this will improve the performance of the bandwidth reduction algorithm.

Also, careful choice of measurement and assignment block sizes can mean that the DATV data is better suited for coding using one of the methods discussed. Ideally the number of assignment blocks per picture would be a power of two. In practice this is difficult to achieve with a 720 x 576 picture, but we can make the number of assignment blocks per measurement block a power of two. This is useful because subquadrants of the quadtree algorithm or of the Peano scan will coincide with measurement blocks (whereas before they did not). And similar vectors within any one measurement block all will have the same index number, so there is a good chance that a subquadrant may be homogeneous.

For a 720 x 576 picture, if the assignment block size is a x b, and the measurement block size is m x n, then the number of assignment blocks per measurement block is (m/a) x (n/b) = c x d, and the number of measurement blocks per picture is (720/m) x (576/n) = r x s. Now c and d should be powers of two, a and b should be divisible by 4 (to keep the assignment algorithm happy) and r and s should preferably be integral. The efficiency required from the coder to meet the current bit rate is 256/ab (because the current DATV format uses 16 x 16 assignment blocks). The aspect ratio of the assignment blocks in the 16 : 9 HDTV picture is 4a : 3b; this should be kept as close to 1 : 1 as possible.

A few possibilities were tried. The best one found was: a = 8, b = 12, m = 64, n = 96, which gives: c = 8, d = 8, r = 11.25, s = 6, required efficiency = 2.667, aspect ratio of assignment blocks = 8 : 9.

Thus the block size is 8 by 12 pixels, which is significantly smaller than the present 16 by 16 size. This does mean there is a non-integral number of measurement blocks in the picture (22.5 across the full HDTV width), but otherwise this is quite a good choice.

Table V below shows the efficiencies for the simple quadtree and Peano run length algorithms. Again the former achieved slightly better figures. The right hand column shows that neither algorithm failed to code any frame in more bits than the uncoded case with 16 x 16 blocks (4860 bits), although the Peano coder came very close on one frame.

To obtain some branch decisions using the smaller block size some modifications were made to the P3 codec and PRLCAR put through it. The simple quadtree algorithm only just met the bit rate requirement with an overall efficiency of 2.682 and unfortunately 42% of frames were "failures". However, Table VI shows that the overall average bit rate for the complete DATV signal is comfortably within the limit of 950 kbits/sec.

There will always be the occasional frame which codes so badly that the total number of bits exceeds the limit for one frame. When this happens, a "fallback" mode is needed. One possibility would be to "miss" out the lowest level of the quadtree, and assume a 2 x 2 subquadrant is homogeneous regardless of whether it really is. The "colour" of this 2 x 2 area would be set to the most popular colour of its 1 x 1 "children". A less extreme but more complex version of this would only make the above "assumption" where three of the 1 x 1 blocks are the same. If this still gives too many bits, the assumption is made where two blocks are the same, and failing this for all 2 x 2 regions. Figure 5 shows a possible block diagram to implement this.

4.2 Further Methods By bit rate reducing the current P3 DATV information, this will leave room for additional information used by a possible further algorithm; branch decisions for 8 x 8 blocks (rather than the 16 x 16 blocks used by P3), vector numbers for a motion-compensated 80ms mode, and possibly for a motion-compensated 20ms mode.

If quadtree coding is used for the current DATV data then the simplest method, and probably the most efficient, is just to extend the quadtree coding one further level to include 8 x 8 pixels, and use a simple Huffman-type code to encode the branch used for the 8 x 8 blocks and the vector number for the 80 ms branch (and 20ms branch) if required. Possible codes are discussed below. A fallback method is required1 by preprocessing the data to decide when to send 8 x 8 information, looking at how many bits are left for a given frame, and possibly using a spiral pattern for this allocation. With a spiral scan, the central areas of the picture, which tend to be of most interest to the viewer, can be covered first.

The problem with all this is that with simple quadtree coding, the 8 x 8 block data appears intermingled with the data for larger blocks, so making "compatible" decoding by an "older" receiver (i.e. without these further extensions) more difficult.

It would be better to send the basic DATV first and the extensions afterwards. This can be done by sending a list of those 16 x 16 blocks whose four sub-blocks are not in the same mode, followed by the (coded) mode and vector number data for the four blocks. However this would probably not be very efficient as there are 90 x 72 = 6480 possible 16 x 16 blocks in an HD picture, so identifying an individual one would require 13 bits.

The regions of the picture which would require 8 x 8 blocks will tend to be object boundaries, and quadtree coding would be effective in describing these regions. It could be used to identify the individual 8 x 8 blocks and Huffman-type codes to send the branch and vector data e.g. as follows: Codeword Meaning 00 40 MC mode, vector 1 010 40 MC mode, vector 2 0110 40 MC mode, vector 3 etc.

100 80 MC mode, vector 1 1010 80 MC mode, vector 2 10110 80 MC mode, vector 3 etc.

11 20 NMC mode Note that this "supplementary" quadtree code would be completely independent to the "main" quadtree code which might be used to send the P3 data.

Alternatively, rather than use the supplementary quadtree code to identify the 8 x 8 blocks, it could be used to identify the 16 x 16 blocks whose sub-blocks are in different modes and a different Huffman code could describe these four modes. This would be more efficient than the method just described if there are restrictions on what combinations of mode are allowed for the four sub-blocks. For example, to allow for all possible combinations of 20, 40 and 80ms branches within a 16 x 16 block, an 78 word code would be needed. If 20, 40 and 80 ms branches could not all be used in the same 16 x 16 block, this would reduce the number of possibilities by 18 to 60. By not allowing cases like in Figure 6(a), we just get ones like in Figure 6(b), and there are only 36 of these. Figure 6(c) shows some of an example code for this case.Hopefully the extra bit rate might be significantly reduced without too much loss of freedom as to what block can be in what mode. Note that limiting the possibilities should have favourable implications with the "compatible" picture with the "older" receiver.

4.3 Implementation of reduction in block sizes.

A reduction in block size from 16 x 16 to a sub-block size of 8 x 8 would be expected to give a significant improvement to the quality of the decoded picture from a second-generation receiver. The block decisions for the 8 x 8 blocks will be taken in the coder in the same way as occurs for 16 x 16 blocks in the present system, although there may be some advantage in biasing the decisions in favour of not "splitting" a 16 x 16 block to reduce impairments on the compatible picture and limit the amount of additional DATV information required. Such a bias can take the form of slight modifications to the existing spatial consistency processing.

There are two issues which need to be considered when devising methods of introducing smaller blocks: firstly, the way in which a first-generation receiver deals with split blocks needs to be defined, and secondly a method is needed of coding the additional DATV information.

The best way of decoding a split 16 x 16 block in a first generation receiver is to process the whole block as if it were transmitted using the 20ms branch. The effect of this is to introduce dot patterning in sub-blocks coded using the 80ms branch, and a degree of motion judder in sub-blocks coded using the 40ms branch. However, as such effects are (by definition) confined to regions smaller than a 16 x 16 block, the resulting impairments may be small. Any such impairments can be further reduced by increasing the degree of compatibility filtering applied to such split blocks. As the need to split blocks only occurs at object boundaries, the additional noise that this filtering introduces in the HD image from a second generation receiver may be masked by the presence of the edge.

The additional branch selection and vector data required can be transmitted as a lower hierarchy of the P3 data, if a menu-based bit-rate reduction system with quadtree coding is employed for the existing P3 data. A first-generation DATV decoder simply ignores information relating to blocks smaller than 16 x 16, and classifies such blocks as being in the 20ms branch. Alternatively, the P3 data and the data for the split blocks can be transmitted separately. One way of encoding the split block data is to use a quadtree code; this might be expected to be quite efficient as the split blocks tend to lie along object boundaries, and the quadtree technique is known to be able to code such data efficiently. By limiting the combinations of branches into which a block can be split, it may be possible to obtain further reductions in the bit rate required.

4.4 Improved Fallback Mode.

Finally a mention of the fallback mode for the supplementary quadtree code The central region of the picture should be coded first, and if there are enough bits left for that frame, the outer regions can be coded. Since quadtree likes data with sides a power of two and there are 90 x 72 blocks (of size 16 x 16), the picture can be divided into 32 x 32 regions as shown in Figure 7. Note that the dimensions correspond to 16 x 16 blocks. In this figure the numbers in circles indicate the order in which the parts are transmitted. Each of these nine regions will have its own quadtree code (the extra number of bits introduced because there are nine regions should be quite small). Thus, the numbers show the order in which the quadtrees are sent. When one of these looks like overflowing the DATV "budget", the supplementary coding is stopped, and uncoded regions are transmitted with 16 x 16 blocks. This method is simpler and fits better the quadtree algorithm than a spiral method and still should ensure that the central data is almost always sent, with the corner data given least importance. It also ensures that the image is split into square regions whose side lengths are a power of two. Note that the blocks outside the picture area can be given "dummy values" for efficient coding (see above) and regions 2 and 3 are sent first because they contain more "real values". Figure 8 shows a block diagram of the supplementary coding process, the construction of which will be apparent from inspection thereof. Note that the decision between 16 x 16 and 8 x 8 blocks will be biased towards 16 x 16, i.e. towards not splitting the block.In this way the impairments in the compatible picture will be reduced, and the amount of additional DATV information required will be reduced.

Attention is drawn to our British Patent Application No. 9024021.9 (serial number 2 240 005) out of which this application is divided.

Table I HD size 1/4 size Frame rate 25 Hz 25 Hz Picture size (pixels) -. 1440 x 1152 720 x 576 Measurement block size (pixels) 80 x 96 80 x 96 Assignment block size (pixels) ' 16 x 16 16 x 16 Measurement blocks per picture 216 54 Vectors calculated per meas. block 2 2 Bits per vector (x + y components) 6+6 = 12 6+6 = 12 Bit rate used to transmit menus 25 x 216 x 2 x 12 = 25 x 54 x 2 x 12 = 129.6 kb/s 32.4 kb/s Number of global vectors 2 2 Bits per vector (x + y components) 6+6 = 12 6+6 = 12 Bit rate for global vectors 25 x 12 x 2 = 600 bits/s 600 bits/s Assignment blocks per picture 6480 1620 Number of choices on each menu 8 8 Bit rate for menu index numbers 25 x 6480 x log 8 = 25 x 1620 x log28 486.0 kb/s 121.5 kb/s No. of possible branch decisions 4 4 Bit rate for branch decisions 25 x 6480 x log 4 = 25 x 1620 x log 4 - 324.0 b7s 81.0 Kb/s OVERALL BIT RATE 940.2 kb/s 162.6 kb/s Table II Index Code Measured No. Word Frequency 1 0 0.420 2 10 0.276 3 110 0.157 4 1110 0.086 5 11110 0.039 6 111110 0.015 7 1111110 0.005 8 1111111 0.002 Table Ill Run length Codeword No. of bits in codeword 1 0 1 2 1000 4 3 1001 4 4 1010 4 5 1011 4 6 1100 4 7 1101 4 8 1110 4 9 11110000 8 10 11110001 8 11 11110010 8 23 11111110 8 24 1111111100000000 16 25 1111111100000001 16 278 1111111111111110 16 279 1111111111111111000000000000000 32 280 1111111111111111000000000000001 32 Table IV Sequence Simple Linear Complem. Peano Raster Name Quadtree Quadtree Quadtree Run Len. Run Len.

RENATA 0.604 7.244 6.681 4.566 4.851 1.970 2.082 2211 2.088 6.006 2.178 2.889 5.945 5.071 PRLCAR 0.510 6.832 6.593 2.982 2.739 1.860 2.064 2.485 2.127 1.972 0.741 0.879 1.812 1.798 CACTUS 1.427 6.756 6.547 3.218 2.949 1.553 1.722 2.298 1.837 2.472 1.104 1.204 2.259 2.140 The first figure given is the mean number of bits per homogeneous region used to code the structure of the quadtree. For Peano or raster run length coding it is the mean number of bits used in the run length code.The second number is the mean number of bits used to code the vector index number using the above codebook Table II). The final number is the overall coding efficiency for the given sequence and is: no. of bits used in uncoded picture (= 3 x 45 x 36 x no. of frames) total bits to code tree structure/run lengths + total bits to code vector index numbers) Table V Minimum Overall Number Sequence Algorithm Frame Average of Efficiency Efficiency Failures PRLCAR Simple QT 2.929 4.144 none Peano RL 2.667 3.688 none CACTUS Simple QT 12.90 18.9 none Peano RL 11.13 17.21 none Frame Efficiency = 90 x 48 x 3 / (bits used to code frame) Overall Average Efficiency = 90 x 48 x 3 x (no. of frames) x (total bits used) Failure means frame efficiency is less than 2.667 Table Vl HD size 1/4 size Measurement block size (pixels) 64 x 96 64 x 96 Assignment block size (pixels) 8 x 12 8 x 12 Measurement blocks per picture 276 72 Bit rate used to transmit menus 25 x 276 x 25 x 72 x 2x12= 2x12= 165.6 kb/s 43.2 kb/s Bit rate for global vectors 600 bits/s 600 bits/s Assignment blocks per picture 17280 4320 Uncoded bit rate for index nos. 1296.0 kb/s 324.0 kb/s Typical worse case efficiency 4.144 4.144 Coded bit rate for index numbers 312.7 kb/s 78.2 kb/s Bit rate for branch decisions 864.0 kb/s 216.0 kb/s Typical worse case efficiency 2.682 2.682 Coded bit rate for decisions 3211 kb/s 80.5 kb/s OVERALL BIT RATE WITH COOING 801.0 kb/s 202.5 kb/s

Claims (3)

1. CLAIMS: 1. An encoder providing a television signal which comprises picture information at a normal level of definition and, in a non-active-picture part of the signal digital assistance data comprising in relation to each of a plurality of blocks of the picture (a) data indicating which of a plurality of coding modes are employed for that block and/or (b) data indicating a movement vector associated with that block; characterized in that the encoder includes means for encoding at least part of the digital assistance data with a coding method that produces a variable number of bits per frame and including means for detecting when the total number of coded bits per frame exceeds a predetermined level and for changing the coding method to a fallback mode in response thereto.
2. 2. An encoder according to claim 1, in which in the fallback mode the areas closest to the centre of the picture receive the greatest coding detail.
3. 3. A decoder for receiving a signal provided by an encoder in accordance with claim 1 or 2, and providing a high definition display in response thereto by decoding the signal by making use of the digital assistance data.