VP2614

3

VIDEO LOCK

Once the VP2614 has locked to the H261 frames it will

begin searching for the 20 bit unique Picture Start Code. Once

this has been identified the "Video Lock" status bit will be set,

and the bitstream will be translated on a code by code basis.

Video lock will be lost and translation process interrupted

under the following conditions:

1) A Picture Start Code or Group of Blocks ( GOB ) Start

Code is not present when expected.

2) The codeword is not valid for its context, causing no

match to be obtained. Each variable length code in the

bitstream is analysed by the VP2614, and invalid patterns will

force Video Lock to be lost.

3) Too many coefficients are transferred for the current

macroblock because the End of Block code was missing.

4) GOB number is not in the correct range for the operat-

ing mode.

5) A GOB number not in sequence will cause lock to be

lost and then regained.

Note that only the most frequently occurring coefficients

are variable length coded, the others being represented by an

escape sequence followed by a fixed length code. The Intra

DC coefficient is also a fixed length code. These fixed length

codes have bit patterns which are forbidden in the H.261

specification, but they could appear due to bit errors. These

invalid codes are trapped by the VP2614, but do not cause

Video Lock to be lost. Instead the run length coefficient is

replaced by a default value of magnitude 1. When video lock

has been lost the DMODE 3:0 outputs indicate a WAIT state.

When lock is regained any missing macroblocks are replaced

with Fixed Macroblocks.

A count is maintained of up 256 occurrences of faults 1 -

3, and a status bit is set when lock is lost ( the Video Lock

Achieved bit is also cleared ). An output signal is also provided

which can, if required, be used to interrupt the system control-

ler. This indicates any of the above errors which cause Video

Lock to be lost and also frame alignment errors; alternatively

it can be used to just indicate framing errors.

When Video Lock has been achieved, the detection of a

Picture or GOB start code when it is not expected will not

cause lock to be lost. Instead the VP2614 will resynchronize

to the new start code, and dummy macroblocks will be

generated for the missing GOB's. These dummy blocks will be

Fixed Macroblocks, and will cause the VP2615 Decoder to

use data from the previously decoded picture. Note that Video

Lock is actually lost and re-gained under these conditions. The

status bit will momentarily be set and then reset, and the Video

Lock Lost Counter will be incremented.

Similarly any errors in the actual GOB number will not

cause lock to be lost and then gained again. Since sequential

GOB numbers are always produced by the encoder, then the

Decoder generates its own GOB numbers and ignores those

in the bitstream.

A Control Bit allows the system controller to take one of two

actions when Video Lock is lost. Either the VP2614 can be

forced to re-initialize to the next Picture Start Code, or it can

abandon the decoding operation until the next GOB Start

Code is detected. When lock has been lost, and a new start

code has been found, the VP2614 assumes its number to be

initially correct and starts its own sequence from that number.

If, however, the next number in the bitstream is not in se-

quence then this new number is used to start a new sequence.

This process continues until two sequential numbers are

obtained, and then no further checks on the GOB numbers are

made until Video Lock is again lost. The VP2614 will generate

"Fixed Macroblocks " for the missing GOB numbers since

Video Lock was lost, and will output these to the VP2615

decoder. This then uses data from the previous decoded

picture for those macroblocks.

A Video Hold bit is provided in one of the System Control

Registers which forces Video Lock to be lost immediately. No

further data is passed to the VP2615 whilst this bit is set, but

the Received Data Buffer is not allowed to fill unnecessarily.

Incoming data will be flushed out and lost. When the hold bit

is cleared a Picture Start Code must be detected to re-gain

Video Lock. The VP2615 will then be provided with any

missing GOB's as described above, before GOB's in the new

picture are processed.

A Freeze Frame Control Bit is also provided. This has a

similar action to the Video Hold Bit, except that it is only

actioned when PTYPE has been decoded in the picture layer,

and it also sets a Freeze Frame status bit. If Video Lock is lost

before the start of a new frame then Freeze Frame will become

active and a search will commence for a picture start code.

Even though Freeze Frame causes Video Lock to be lost, the

VP2614 will still search for picture start codes and will extract

PTYPE and Temporal Reference values.

If clear, a Release Mode Control Register Bit will allow the

freeze condition to be released when the Freeze Bit is cleared,

but is only actioned when the next Picture Header is decoded.

If the Release Mode Bit is set, then the freeze condition is only

released when the PTYPE bit in the H.261 stream specifies

that this is to occur. Even when automatic release has been

selected the system controller can still monitor the length of

time that the freeze has been in effect. It can then force a

release after a time out period by setting the Release Mode Bit

and clearing the Freeze Bit.

DE-MUX CORE

Once Video Lock has been achieved, the core of the

VP2615 will convert the H.261 bitstream into video param-

eters and run length coded coefficients. A state machine,

which is a hardware manifestation of the H.261 coding struc-

ture, maintains the current position in the bitstream. When

necessary variable length de-coding is performed, and side

information such as temporal reference and Picture Type

Information is stored in registers.

LINE I/P

DATA

DATA VALID

DATA

ENABLE (LEN)

0ns

min

2Ø +10ns

min

LINE

STROBE I/P

(LCLK)

Note. Ø is the system clock period

Asynchronous

NOT

READY O/P

(LRED)

Fig 2 : Line Interface Timing