RecA’(u,v) denotes the final reconstructed coefficient values for the block immediately above the
`current block. RecB’(u,v) denotesthefina/ reconstructed coefficient values of the block immediately
`to the left of the current block.
`
`Theability to use the reconstructed coefficient values for blocks A and B in the prediction of the
`coefficient values for block C depends on whether blocks A and B are in the same video picture
`segment as block C. A block is defined to be "in the same video picture segment" as another block
`only if the following conditions are fulfilled:
`1)
`Therelevant block is within the boundary ofthe picture, and
`2)
`If not in Slice Structured mode (see Annex K), the relevant block is either within the same
`GOBor no GOBheader is present for the current GOB,and
`If in Slice Structured mode,the relevant block is within the sameslice.
`
`3)
`
`The block C to be decoded is predicted only from INTRA blocks within the same video picture
`segmentas block C, as shown below.
`
`If Prediction Mode = 0 is used (DCprediction only) and blocks A and B are both INTRA blocks
`within the same video picture segment as block C, then the DC coefficient of block C is predicted
`from the average (with truncation) of the DC coefficients of blocks A andB.If only one of the two
`blocks A and B is an INTRA block within the same video picture segment as block C, then the DC
`coefficient of only this one of the two blocks is used as the predictor for Prediction Mode = 0.If
`neither of the two blocks A and B are INTRA blocks within the same video picture segmentas block
`C,then the prediction uses the value of 1024 as the predictor for the DC coefficient.
`
`If Prediction Mode = 1 or 2 (vertical DC & AC or horizontal DC & AC prediction) and the
`referenced block (block A or block B) is not an INTRA block within the same video picture segment
`as block C, then the prediction uses the value of 1024 as the predictor for the DC coefficient and the
`value of0 as the predictor for the AC coefficients of block C.
`
`A process of "oddification" is applied to the DC coefficient in order to minimize the impact of IDCT
`mismatch errors. Certain values of coefficients can cause a round-off error mismatch between
`different IDCT implementations, especially certain values of the (0,0), (0,4), (4,0), and (4,4)
`coefficients. For example, a DC coefficient of 8k+4 for some integer k results in an inverse-
`transformed block having a constant value k + 0.5, for which slight errors can cause rounding in
`different directions on different implementations.
`
`Define the clipAC() function to indicate clipping to the range —2048 to 2047. Define the clipDC()
`function to indicate clipping to the range 0 to 2047. Define the oddifyclipDC(x) functionas:
`
`If (x is even) {
`result = clipDC(x+1)
`} else {
`result = clipDC(x)
`
`}
`
`The reconstruction for each INTRA prediction mode is then specified as follows, in which the
`operator "/" is defined as division by truncation:
`
`Mode0: DCprediction only.
`
`(u,v) # (0,0), u=0, ..., 7, v=0, ..., 7.
`RecC (u,v) = clipAC( RecC(u,v) )
`If (block A and block B are both INTRA coded andare both in the same video picture segment as
`block C) {
`tempDC = RecC(0,0) + ( RecA’(0,0) + RecB’(0,0) )/2
`} else {
`
`91
`
`Recommendation H.263
`
`(02/98)
`
`79
`
`91
`
`

`

`If (block A is INTRA coded andis in the same video picture segmentas block C) {
`tempDC = RecC(0,0) + RecA’(0,0)
`\ else {
`If (block B is INTRA coded andis in the samevideo picture segmentas block C) {
`tempDC = RecC(0,0) + RecB’(0,0)
`} else {
`tempDC = RecC(0,0) + 1024
`
`}
`
`}
`
`} R
`
`ecC'(0,0) = oddifyclipDC( tempDC)
`
`Mode 1: DC and AC prediction from the block above.
`
`If (block A is INTRA coded andis in the same video picture segmentas block C) {
`tempDC = RecC(0,0) + RecA‘(0,0)
`RecC ’(u,0) = clipAC( RecC(u,0) + RecA’(u,0))
`RecC (u,v) = clipAC( RecC(u,v) )
`} else {
`tempDC = RecC(0,0) + 1024
`RecC (u,v) = clipAC( RecC(u,v) )
`
`u=1,..., 7,
`UO = 0yccg Fs V = lyacss 7.
`
`(u,v) # (0,0), u=0, ...,7, v=, ..., 7
`
`} R
`
`ecC’(0,0) = oddifyclipDC( tempDC)
`
`Mode2: DC and ACprediction from the blockto theleft.
`
`If (block B is INTRA coded andis in the same video picture segmentas block C) {
`tempDC = RecC(0,0) + RecB’(0,0)
`RecC’(0,v) = clipAC( RecC(0,v) + RecB’(0,v))
`RecC’ (u,v) = clipAC( RecC(u,v))
`} else {
`tempDC = RecC(0,0) + 1024
`RecC (u,v) = clipAC( RecC(u,v) )
`
`v=1,...7,
`u=l1,...,7,v=0, ..., 7.
`
`(u,v) # (0,0), u=0, ..., 7, v=90, ..., 7
`
`} R
`
`ecC'(0,0) = oddifyclipDC( tempDC)
`
`ANNEX J
`
`Deblocking Filter mode
`
`J.1
`
`Introduction
`
`This annex describes the use of an optional block edge filter within the coding loop. The main
`purpose of the block edgefilter is to reduce blocking artifacts. The filtering is performed on 8 x 8
`block edges. Motion vectors may have either 8 x 8 or 16 x 16 resolution (see J.2). The processing
`described in this annex applies only for the P-, I-, EP-, or El-pictures or the P-picture part of an
`Improved PB-frame. (Possible filtering of B-pictures or the B-picture part of an Improved PB-frame
`is not a matter for standardization; however, sometype offiltering is recommended for improved
`picture quality.) The capability of this mode is signalled by external means (for example,
`Recommendation H.245). The use of this mode is indicated in the PLUSPTYPEfield of the picture
`header.
`
`80
`
`Recommendation H.263
`
`(02/98)
`
`9?
`
`92
`
`

`

`J.2
`
`Relation to UMV and AP modes (AnnexesD and F)
`
`The use of the deblocking filter mode has similar effects on picture quality as Overlapped Block
`Motion Compensation (OBMC)as defined in Annex F when used alone. When both techniques are
`used together, a further improvement in picture quality can be obtained. The Advanced Prediction
`mode (see also Annex F) consists of three elements:
`1)
`four motion vectors per macroblockas defined in F.2;
`
`2)
`3)
`
`overlapped motion compensation for luminanceas defined in F.3;
`motion vectors over picture boundaries as defined in D.1.
`
`In order for the Deblocking Filter mode to be able to provide maximum performance when
`complexity considerations may prevent use of the OBMCpart of the Advanced Prediction mode, the
`Deblocking Filter mode includes the ability to use four motion vectors per macroblock and motion
`vectors over picture boundaries.
`
`In summary, the three options defined in Annexes D, F and J contain the following five coding
`elements:
`
`1)
`2)
`
`3)
`
`4)
`5)
`
`motion vectors over picture boundaries (D.1);
`extension of motion vector range (D.2);
`
`four motion vectors per macroblock (F.2);
`
`overlapped motion compensation for luminance (F.3);
`deblocking edgefilter (J.3).
`
`Table J.1 indicates which of the five elements are turned on depending on whichof the three options
`defined in AnnexesD, F and J are turned on.
`
`Unrestricted|Advanced|Deblocking|Motion Extension|Four motion|Overlapped Deblocking
`
`
`
`
`
`
`
`Motion of motion|vectors pericti i vectors motion edgefilter
`
`
`Vector mode macroblock|compensationover vector
`
`
`picture
`range
`for luminance
`
`Table J.1/H.263 — Feature Elements for UMV, AP, and DF modes
`
`boundaries
`
`J3
`
`Definition of the deblocking edgefilter
`
`Thefilter operations are performed across 8 x 8 block edges at the encoder as well as on the decoder
`side. The reconstructed image data (the sum of the prediction and reconstructed prediction error) are
`clipped to the range of 0 to 255 as described in 6.3.2. Then the filtering is applied, which alters the
`picture that is to be stored in the picture store for future prediction. The filtering operations include
`an additional clipping to ensure that resulting pixel values stay in the range 0...255. No filtering is
`performedacross a picture edge, and when the Independent Segment Decoding modeis in use, no
`
`93
`
`Recommendation H.263
`
`(02/98)
`
`81
`
`93
`
`

`

`filtering is performed across slice edges when the Slice Structured mode is in use (see Annexes K
`and R)or across the top boundary of GOBs having GOB headers present when the Slice Structured
`modeis not in use (see Annex R). Chrominanceas well as luminance data are filtered.
`
`When the mode described in this annex is used together with the Improved PB-frames mode of
`Annex M, the backward prediction of the B-macroblock is based on the reconstructed P-macroblock
`(named Ppgc in G.5) after the clipping operation but before the deblocking edge filter operations. The
`forward prediction of the B-macroblock is based on the filtered version of the previous decoded
`picture (the samepicture data that are used for prediction of the P-macroblock).
`
`The deblocking filter operates using a set of four (clipped) pixel values on a horizontal or vertical
`line of the reconstructed picture, denoted as A, B, C and D, of which A and B belong to one block
`called block] and C and D belong to a neighbouring block called block2 whichis to the right of or
`below block1. Figure J.1 shows examples for the position of these pixels.
`
`Exampleforfiltered pixels
`
`Block boundary
`
`on a horizontal block edge
`
`Example forfiltered pixels
`
`Figure J.1/H.263 — Examples of positionsoffiltered pixels
`
`71602910-97
`
`One or both of the following conditions must be fulfilled in order to apply the filter across a
`particular edge:
`-
`Condition 1: block! belongs to a coded macroblock (COD==0 || MB-type == INTRA); or
`—
`Condition 2: block2 belongs to a coded macroblock (COD==0 || MB-type == INTRA).
`
`If filtering is to be applied across the edge, A, B, C, and D shall be replaced by Al, B1, Cl, D1
`where:
`
`Bl =clip(B + dl)
`
`Cl =clip(C — dl)
`
`Al=A-d2
`
`D1 =D+d2
`
`d=(A-4B+4C-D)/8
`
`dl = UpDownRamp(d, STRENGTH)
`
`d2 = clipd1((A — D) / 4, d1/2)
`
`UpDownRamp(x, STRENGTH) = SIGN(x) * (MAX(0, abs(x)-MAX(0, 2*(abs(x) —
`STRENGTH))))
`
`82
`
`Recommendation H.263
`
`(02/98)
`
`94
`
`94
`
`

`

`STRENGTH depends on QUANT and determines the amount of filtering. The relation between
`STRENGTHand QUANT isgiven in Table J.2.
`QUANT = quantization parameter used for block2 if block2 belongs to a coded macroblock,
`or
`
`QUANT = quantization parameter used for block! if block2 does not belong to a coded
`macroblock (but block! does).
`
`Table J.2/H.263 — Relationship between QUANT and STRENGTHoffilter
`
`QUANT|STRENGTH — STRENGTH |6|
`
`|7|
`|8
`|9|
`|10
`pou|
`|2
`|3
`|4
`|ts
`|16|
`The function clip(x) is defined according to 6.3.2, and the function clipd1(x, lim) clips x to the range
`+ abs(lim). The symbol "/" denotes division by truncation toward zero.
`
`Figure J.2 shows how the value of dl varies as a function of d. As a result, the filter has an effect
`only if d is smaller than 2*STRENGTH(and different from zero). This is to prevent the filtering of
`strong true edges in the picture content. However, if the Reduced-Resolution Update modeis in use,
`STRENGTHis set to infinity, and as a result, the value of dl is always equal to the value of d
`(see Q.7.2).
`
`95
`
`Recommendation H.263
`
`(02/98)
`
`83
`
`95
`
`

`

`a4
`
`
`
`
`
`Strength
`
`2*Strength
`
`4
`71602920-97
`
`Figure J.2/H.263 — Parameter d1 as a function of parameterd for deblocking filter mode
`
`The definition of dl is designed to ensure that small mismatches between the encoder and decoder
`will remain small and will not build up over multiple pictures of a video sequence. This would be a
`problem, for example, with a condition that simply switchesthe filter on or off, because a mismatch
`of only +1 for d could then cause the filter to be switched on at the encoder side and off at the
`decoderside, or vice versa.
`
`Due to rounding effects, the order of edges where filtering is performed mustbe specified.
`
`Filtering across horizontal edges:
`
`A B
`
`Basically this process is assumed to take place first. More precisely, the pixels C that are used in
`D
`
`filtering across a horizontal edge shall not have been influenced by previousfiltering across a vertical
`edge.
`
`Filtering across vertical edges:
`
`Before filtering across a vertical edge using pixels (A, B,C,D), all modifications of pixels
`(A, B, C, D) resulting from filtering across a horizontal edge shall have taken place.
`
`Note that if one or more of the pixels (A, B, C, D) taking part in a filtering process are outside of a
`picture, no filtering takes place. Also,
`if the Independent Segment Decoding mode is in use
`(see Annex R) and one or more of the pixels (A, B, C, D) taking part in a filtering process are in
`different video picture segments (see I.3 concerning when a block is considered to be in the same
`video picture segment), no filtering is performed.
`
`84
`
`Recommendation H.263
`
`(02/98)
`
`96
`
`96
`
`

`

`ANNEX K
`
`Slice Structured mode
`
`K.1
`
`Introduction
`
`This annex describes the optional Slice Structured mode of this Recommendation. The capability of
`this H.263 modeis signalled by external means (for example, Recommendation H.245). The use of
`this modeis indicated in the PLUSPTYPEfield of the picture header. In order to facilitate optimal
`usage in a number of environments, this mode contains two submodes which are also capable of
`being signalled by external means (for example, Recommendation H.245). These two submodes are
`used to indicate whether or not rectangular slices will be used and/or whether the slices will be
`transmitted in sequential order or sent in an arbitrary order.
`
`A slice is defined as a slice header followed by consecutive macroblocks in scanning order. An
`exception is for the slice that immediately follows the picture start code in the bitstream for a picture
`(which is not necessarily the slice starting with macroblock 0). In this case only part of the slice
`headeris transmitted as described in K.2. The slice layer defines a video picture segment, and is used
`in place of the GOB layerin this optional mode. A slice video picture segment starts at a macroblock
`boundary in the picture and contains a number of macroblocks. Different slices within the same
`picture shall not overlap with each other, and every macroblock shall belong to one and only one
`slice.
`
`This mode contains two submodes, whichare signalled in the SSSfield of the picture header:
`1)
`The Rectangular Slice submode (RS): When RS is in use,
`the slice shall occupy a
`rectangular region of width specified by the SWI parameter of the slice header in units of
`macroblocks, and contains a number of macroblocks in scanning order within the rectangular
`region. When the Rectangular Slice submodeis not in use, the SWIfield is not present in the
`slice header and a slice contains a number of macroblocks in scanning order within the
`picture as a whole.
`The Arbitrary Slice Ordering submode (ASO): When ASOisin use, the slices may appear in
`any order within the bitstream. When ASO is not in use, the slices must be sent in the
`(unique) order for which the MBAfield of the slice headeris strictly increasing from each
`slice to each subsequentslice in the picture.
`
`2)
`
`Slice boundaries are treated differently from simple macroblock boundaries in order to allow slice
`header locations within the bitstream to act as resynchronization points for bit error and packetloss
`recovery and in order to allow out-of-order slice decoding within a picture. Thus, no data
`dependencies can cross the slice boundaries within the current picture, except for the Deblocking
`Filter mode which, when in use without the Independent Segment Decoding mode,filters across the
`boundaries of the blocks in the picture. However, motion vectors within a slice can cause data
`dependencies which cross the slice boundaries in the reference picture used for prediction purposes,
`unless the optional Independent Segment Decoding modeis in use.
`
`The following rules are adopted to ensure that slice boundary locations can act as resynchronization
`points and to ensure that slices can be sent out of order without causing additional decoding delays:
`1)
`The prediction of motion vector values are the same as if a GOB header were present
`(see 6.1.1), preventing the use of motion vectors of blocks outside the current slice for the
`prediction of the values of motion vectors within the slice.
`The Advanced INTRA Coding mode (see Annex I) treats the slice boundary as if it were a
`picture boundary with respect to the prediction of INTRA block DCTcoefficient values.
`
`2)
`
`97
`
`Recommendation H.263
`
`(02/98)
`
`85
`
`97
`
`

`

`3)
`
`The assignment of remote motion vectors for use in overlapped block motion compensation
`within the Advanced Prediction mode also prevents the use of motion vectors of blocks
`outside the current slice for use as remote motion vectors (see F.3).
`
`K.2
`
`Structure ofslice layer
`
`Thestructure ofthe slice layer of the syntax is shown in Figure K.1 for all slices except the slice that
`immediately follows the picture start code in the bitstream for a picture. For the slice following the
`picture start code, only the emulation prevention bits (SEPB1, SEPB3, and conditionally SEPB2 as
`specified below), the MBAfield and, when in the RS submode,also the SWIfield are included.
`
`[_ssTur|ssc|seppi|sspi_|Mpa|sepp2|squant|swi|sepp3|GrID_|MacroblockData_|
`
`Figure K.1/H.263 — Structure ofslice layer
`
`Refer to 5.2.5 for GFID, and to 5.3 for description of Macroblock layer.
`
`K.2.1 Stuffing (SSTUF) (Variable length)
`
`A codeword of variable length consisting of less than 8 bits. Encoders shall insert this codeword
`directly before an SSC codeword whenever needed to ensure that SSC is byte aligned. If SSTUFis
`present, the last bit of SSTUF shall be the last (least significant) bit of a byte, so that the start of the
`SSC codeword is byte aligned. Decoders shall be designed to discard SSTUF. Notice that 0 is used
`for stuffing within SSTUF.
`
`K.2.2
`
`Slice Start Code (SSC)(17 bits)
`
`A word of 17 bits. Its value is 0000 0000 0000 0000 1. Slice start codes shall be byte aligned. This
`can be achievedby inserting SSTUF before the start code such that the first bit of the start code is the
`first (most significant) bit of a byte. The slice start code is not present for the slice which follows the
`picture start code.
`
`K.2.3
`
`Slice Emulation Prevention Bit 1 (SEPB1) (1 bit)
`
`A single bit always having the value of "1", which is included to prevent start code emulation.
`
`K.2.4 Slice Sub-Bitstream Indicator (SSBD (4 bits)
`
`A codeword of length four bits which is present only when CPM = "1" in the picture header. SSBI
`indicates the Sub-Bitstream number for the slice for Continuous Presence Multipoint and Video
`Multiplex operation, as described in Annex C. The mapping from the value of SSBI to the
`Sub-Bitstream number is shown in Table K.1. SSBI is not present for the slice which follows the
`picture start code.
`
`Table K.1/H.263 — Values of SSBI and associated Sub-Bitstream numbers
`
`25
`
`Sub-Bitstream
`number
`
`SSBI field
`value
`
`GNvalue
`emulated
`
`86
`
`Recommendation H.263
`
`(02/98)
`
`98
`
`98
`
`

`

`K.2.5 Macroblock Address (MBA)(5/6/7/9/11/12/13/14 bits)
`
`A codeword having a length that is dependent on the current picture size and whether the Reduced-
`Resolution Update modeis in effect (see Annex Q). The bits are the binary representation of the
`macroblock numberofthe first macroblock in the current slice as counted from the beginning of the
`picture in scanning order, starting with macroblock number0 at the upper left corner. MBA uniquely
`identifies which macroblock in the picture the current slice starts with. Codeword lengths for this
`codeword are provided in Table K.2. For custom picture sizes, the field width is given by thefirst
`entry in the table that has an equal or larger number of macroblocks, and the maximum value is the
`number of macroblocks in the current picture minus one. When in the Reduced-Resolution Update
`mode, the relevant picture size is the lower resolution update picture size rather than the picture size
`indicated in the picture header (see AnnexQ).
`
`|Default||RRUmodemode
`vale
`vale
`width
`
`Picture format
`
`Field
`
`TableK.2/H.263—arofMBAantes
`
`
`
`
`
`K.2.6 Slice Emulation Prevention Bit 2 (SEPB2)(1 bit)
`
`A single bit always having the value "1", which is included under certain conditions to prevent start
`code emulation. For slices other than the one following the picture start code, SEPB2 is included
`only if the MBA field width is greater than 11 bits and CPM = "0" in the picture header, or if the
`MBAfield width is greater than 9 bits and CPM = "1"in the picture header. Forthe slice following
`the picture start code, SEPB2 is included only if the Rectangular Slice submodeis in use.
`
`K.2.7 Quantizer Information (SQUANT)(5 bits)
`
`A fixed length codewordof five bits which indicates the quantizer QUANTto be used forthat slice
`until updated by any subsequent DQUANT.The codewords are the natural binary representations of
`the values of QUANTwhich, being half the step sizes, range from 1 to 31. SQUANT is not present
`for the slice which followsthe picture start code.
`
`K.2.8 Slice Width Indication in Macroblocks (SWI) (3/4/5/6/7 bits)
`
`A codeword whichis present only if the Rectangular Slice submodeis active, and having a length
`which depends on the current picture size and whether the Reduced-Resolution Update mode is
`active, as specified in Table K.3. For custom picture sizes, the field width is given by the next
`standard format size whichis equal or larger in width (QCIF,CIF, ...), and the maximum valueis the
`total number of macroblocks across the picture minus one. The last row of the table indicates the
`field width for picture sizes wider than 16CIF. SWI refers to the width of the current rectangular slice
`havingits first macroblock (upper left) specified by MBA.The calculation of the actual slice width is
`given by
`
`Actual Slice Width = SWI + 1
`
`99
`
`Recommendation H.263
`
`(02/98)
`
`87
`
`99
`
`

`

`the relevant picture size is that of the lower
`When in the Reduced-Resolution Update mode,
`resolution picture size for the update information, rather than the picture size indicated in the picture
`header.
`
`TableK.3/H.263—aofSWIaa
`|Default||RRUmode|mode
`
`aie
`value
`width
`
`
`
`
`4CIF Pe
`
`
`[cr|7|3fp
`1412. 2048eaeee
`
`
`
`a C
`
`IF
`
`K.2.9 Slice Emulation Prevention Bit 3 (SEPB3)(1 bit)
`
`i he
`A single bit always having the value of"1"in order to prevent start code emulation.
`
`ANNEX L
`
`Supplemental Enhancement Information Specification
`
`L.1
`
`Introduction
`
`This annex describes the format of the supplemental enhancement information sent in the PSUPP
`field of the picture layer of this Recommendation. The capability of a decoder to provide anyorall of
`the enhanced capabilities described in this annex may be signalled by external means (for example
`Recommendation H.245). Decoders which do not provide the enhanced capabilities may simply
`discard any PSUPP information bits that appear in the bitstream. The presence of this supplemental
`enhancement information is indicated in PEI, and an additional PEI bit is inserted between every
`octet of PSUPP data, as described in 5.1.24 and 5.1.25.
`
`In this annex, a distinction is made between the "decoded picture" and the "displayed picture". For
`purposes of this annex,
`the "displayed picture" is a picture having the same picture format as
`specified for the current picture by the picture layer of the video bitstream syntax. The "displayed
`picture" is constructed as described in this annex from the decoded picture, the prior displayed
`picture, the supplementary enhancementinformation described herein, and in somecases partly from
`a backgroundpicture whichis externally controlled.
`
`L.2
`
`PSUPP format
`
`The PSUPP data consists of a four-bit function type indication FTYPE, followed by a four-bit
`parameter data size specification DSIZE, followed by DSIZE octets of function parameter data,
`optionally followed by another function type indication, and so on. One function type indication
`value is defined as an escape code to provide for future extensibility to allow definition of more than
`fifteen different functions. A decoder which receives a function type indication which it does not
`support can discard the function parameter data for that function and then check for a subsequent
`
`88
`
`Recommendation H.263
`
`(02/98)
`
`100
`
`Picture format
`
`Max
`
`Field
`
`100
`
`

`

`function type indication which may be supported. The defined FTYPE values are shown in
`Table L.1.
`
`Table L.1/H.263 — FTYPEfunction type values
`
`[0[ReneeOS—SCS
`
`
`
`
`
`[6|FulePictureSnapshotTag
`
`3]
`
`a9
`
`]
`
`Pan
`2]
`2
`13
`
`i 1
`
`L.3
`
`Do Nothing
`
`No action is requested by the Do Nothing function. This function is used to prevent start code
`emulation. Wheneverthe last five or more bits of the final octet of the previous PSUPP octetare all
`zero and no additional PSUPP function requests are to be sent, the Do Nothing function shall be
`inserted into PSUPPto prevent the possibility of start code emulation. The Do Nothing function may
`also be sent whenit is not required by rule expressed in the previous sentence. DSIZE shall be zero
`for the Do Nothing function.
`
`L.4
`
`Full-Picture Freeze Request
`
`The full-picture freeze request function indicates that the contents of the entire prior displayed video
`picture shall be kept unchanged, without updating the displayed picture using the contents of the
`current decoded picture. The displayed picture shall then remain unchanged until the freeze picture
`release bit in the current PTYPE or in a subsequent PTYPEis set to 1, or until timeout occurs,
`whichever comes first. The request shall lapse due to timeout after five seconds or five pictures,
`whicheveris a longer period of time. The timeout can be prevented by the issuance of another full-
`picture freeze request prior to or upon expiration of the timeout period (e.g. repeating the request in
`the headerofthe first picture with temporal reference indicating a time interval greater than or equal
`to five seconds since issuance, or in the header ofthe fifth picture after issuance). DSIZE shall be
`zero for the full-picture freeze request function.
`
`L.5
`
`Partial-Picture Freeze Request
`
`The partial-picture freeze request function indicates that the contents of a specified rectangular area
`of the prior displayed video picture should be kept unchanged, without updating the specified area of
`the displayed picture using the contents of the current decoded picture. The specified area of the
`displayed picture shall then remain unchanged until the freeze picture release bit in the current
`
`101
`
`Recommendation H.263
`
`(02/98)
`
`89
`
`101
`
`

`

`PTYPEor in a subsequent PTYPEisset to 1, until a partial-picture freeze-release request affecting
`the specified area is received, until the source format specified in a picture headerdiffers from that of
`previous picture headers, or until timeout occurs, whichever comesfirst. Any change in the picture
`source format shall act as a freeze release for all active partial-picture freeze requests. The request
`shall lapse due to timeout after five seconds or five pictures, whichever is a longer period oftime.
`The timeout can be prevented by the issuanceofan identical partial-picture freeze request prior to or
`upon expiration of the timeout period (e.g. repeating the request in the headerofthe first picture with
`temporal reference indicating a time interval greater than or equal to five seconds since issuance, or
`in the header of the fifth picture after issuance). DSIZE shall be equal to 4 for the partial-picture
`freeze request. The four octets of PSUPP that follow contain the horizontal and vertical location of
`the upper left corner of the frozen picture rectangle, and the width and height of the rectangle,
`respectively, using eight bits each and expressed in units of eight pixels. For example, a 24-pixel
`wide and 16 pixel tall area in the upper left corner of the video display is specified by the four
`parameters (0, 0, 3, 2).
`
`L.6
`
`Resizing Partial-Picture Freeze Request
`
`the contents of a specified
`The resizing partial-picture freeze request function indicates that
`rectangular area of the prior displayed video picture should be resized to fit into a smaller part of the
`displayed video picture, which should then be kept unchanged, without updating the specified area of
`the displayed picture using the contents of the current decoded picture. The specified area of the
`displayed picture shall then remain unchanged until the freeze release bit in the current PTYPEorin
`a subsequent PTYPEis set to 1, until a partial-picture freeze-release request affecting the specified
`area is received, until the source format specified in a picture header differs from that of previous
`picture headers, or until timeout occurs, whichever comes first. Any change in the picture source
`formatshall act as a freeze release for all active resizing partial-picture freeze requests. The request
`shall lapse due to timeout after five seconds or five pictures, whichever is a longer period of time.
`The timeout can be prevented by the issuance ofa partial-picture freeze request for the affected area
`of the displayed picture prior to or upon expiration of the timeout period (e.g. issuing a partial-
`picture freeze request in the header of the first picture with temporal reference indicating a time
`interval greater than or equal to five seconds since issuance, or in the headerofthe fifth picture after
`issuance). DSIZE shall be equal to 8 for the resizing partial-picture freeze request. The eight octets of
`PSUPPdata that follow contain 32 bits used to specify the rectangular region of the affected area of
`the displayed picture, and then 32 bits used to specify the corresponding rectangular region of the
`affected area of the decoded picture. The width and height of the rectangular region in the decoded
`picture shall both be equal to 2’ times the width and height specified for the rectangular region in the
`displayed picture, where / is an integer in the range of | to 8. The location and size of each of these
`two rectangular regions is specified using the same format as such a region is specified in the partial-
`picture freeze request function.
`
`L.7
`
`Partial-Picture Freeze-Release Request
`
`the contents of a specified
`function indicates that
`The partial-picture freeze-release request
`rectangular area of the displayed video picture shall be updated by the current and subsequent
`decoded pictures. DSIZE shall be equal to 4 for the partial-picture freeze-release request. The four
`octets of PSUPP data that follow specify a rectangular region of the displayed picture in the same
`formatas such a region is specified in the partial-picture freeze request function.
`
`L.8
`
`Full-Picture Snapshot Tag
`
`The full-picture snapshot tag function indicates that the current picture is labelled for external use as
`a still-image snapshot of the video content. DSIZE shall be equal to 4 for the full-picture snapshot
`
`90
`
`Recommendation H.263
`
`(02/98)
`
`102
`
`102
`
`

`

`tag function. The four octets of PSUPPdata that follow specify a snapshot identification number for
`external use.
`
`L.9
`
`Partial-Picture Snapshot Tag
`
`The partial-picture snapshot tag function indicates that a specified rectangular area of the current
`picture is labelled for external use as a still-image snapshot of the video content. DSIZE shall be
`equal to 8 for the partial-picture snapshot tag function. The first four octets of PSUPP data that
`follow specify a snapshot identification number for external use, and the remaining four octets of
`PSUPPdata that follow specify a rectangular region of the decoded picture in the same format as
`such a region is specified in the partial-picture freeze request function.
`
`L.10 Video Time Segment Start Tag
`
`The video time segmentstart tag function indicates that the beginning of a specified sub-sequence of
`video data is labelled as a useful section of video content for external use, starting with the current
`picture. The tagged sub-sequence of video data shall continue until stopped by the receipt of a
`matching video time segment end tag function or until timeout, whichever comesfirst. The tagged
`sub-sequence shall end due to timeout after five seconds or five pictures, whichever is a longer
`period of time. The timeout can be prevented by the issuance of an identical video time segmentstart
`tag function prior to or upon expiration of the timeout period (e.g. repeating the video time segment
`start tag function in the header ofthe first picture with temporal reference indicating a time interval
`greater than or equal to five seconds since issuance, or in the header of the fifth picture after
`issuance). DSIZEshall be equal to 4 for the video time segmentstart tag function. The four octets of
`PSUPPdatathat follow specify a video time segment identification numberfor external use.
`
`L.11.
`
`Video Time Segment End Tag
`
`The video time segment end tag function indicates that the end of a specified sub-sequence of video
`data is labelled as a useful section of video content for external use, ending with the previouspicture.
`DSIZEshall be equal to 4 for the video time segmentstart tag function. The four octets of PSUPP
`data that follow specify a video time segment identification numberfor external use.
`
`L.12
`
`Progressive Refinement Segment Start Tag
`
`The pr