Improvements in DCT-based video
`coding
`
`Puri, Atul, Schmidt, Robert, Haskell, Barry
`
`Atul Puri, Robert L. Schmidt, Barry G. Haskell, "Improvements in DCT-based
`video coding," Proc. SPIE 3024, Visual Communications and Image
`Processing '97, (10 January 1997); doi: 10.1117/12.263279
`Event: Electronic Imaging '97, 1997, San Jose, CA, United States
`
`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`PROCEEDINGS OF SPIE
`
`SPIEDigitalLibrary.org/conference-proceedings-of-spie
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 1
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`Improvements in DCT Based Video Coding
`
`A. Pun, R. L. Schmidt and B. G. Haskell
`
`AT&T Labs
`101 Crawfords Corner Road
`Holmdel, NJ 07733
`
`ABSTRACT
`
`We report on recent advances in traditional DCT based video coding at low bitrates. These improvements allow either
`an increase in coding efficiency or an increase in other functionalities. Our investigation is conducted within the framework of
`the ongoing work towards the MPEG-4 video standard. The ISO Moving Picture Experts Group (MPEG) is currently developing
`this standard after having completed the MPEG-i and the MPEG-2 standards. The MPEG-4 video standard is addressing a
`number of content based as well as traditional functionalities. The development process consists of iterative refmement of the
`Verification Model (which describes the coding method) via a set of well defined core experiments.
`
`Our first experiment is on improved coding efficiency of Intra and uses DC and AC predictions and optimized scanning
`of DCT coefficients followed by a separate optimized variable length code table. Our second experiment is the study of
`bidirectional coding to allow additional functionality such as temporal scalability at low bit-rates. We present results of these
`experiments and summarize our findings.
`
`Keywords: video compression, video coding, MPEG coding standards, MPEG-4, interframe coding, DCT coding, motion
`compensation, motion compensated DCT coding.
`
`1. INTRODUCTION
`
`The recent experience in the development of the ITU-T H.263 standard illustrates that several incremental
`improvements when combined can collectively result in a notable advance in the coding performance or increase in functionality
`of an earlier coding standard (in this case, H.261) making it quite competetive to fairly complex new proposals. It appears that
`although the DCT based coding framework was optimized for H.263 for low bitrate coding, it can still be refined further to allow
`improved coding efficiency as well as increased functionality. In this paper our goal is to investigate techniques for further
`refmments within the context of the ongoing development work of the MPEG-4 video coding standard. The ISO Moving Picture
`Experts Group (MPEG) is currently developing this standard after having completed the MPEG-i and the MPEG-2 standards.
`
`The MPEG-l video standard is designed for Digital Storage Media (DSM) applications at bitrates of about 1.2 Mbit/s
`and supports basic interactivity with stored bitstream such as random access, fast forward, fast reverse and others. MPEG-i video
`coding [1] uses block motion compensated DCT coding within a group-of-pictures (GOP) structure consisting of an arrangement
`of intra (I-), predictive (P-) and bidirectional (B-) pictures to deliver good coding efficiency and desired interactivity. This
`standard is optimized for coding of noninterlaced video only. The second phase MPEG (MPEG-2) standard, on the other hand, is
`more generic. MPEG-2 is intended for coding of higher resolution video as compared to MPEG-i and can deliver TV quality in
`range of 4 to 10 Mbit/s and HDTV quality in range of 15 to 30 Mbit/s. MPEG-2 video standard [2,4] is mainly optimized for
`coding of interlaced video. MPEG-2 video coding builds on the motion compensated DCT coding framework of MPEG-i and
`further includes adaptations for efficient coding ofinterlaced video [3,5].MPEG-2 supports interactivity functions ofMPEG-l as
`well as new functions such as scalability [3]. Scalability is the property that enables decodability of subsets of entire bitstream on
`decoders ofless than full complexity to produce useful video from the same bitstream. Scalability in picture quality is supported
`via SNR scalability [3], scalability in spatial resolution by Spatial scalability [3] and scalability in temporal resolution via
`Temporal scalability [3,6J. The MPEG-2 video standard is both forward and backward compatible with MPEG-i; backward
`compatibility can be achieved using spatial scalability. Both MPEG-i and MPEG-2 standards only specify a bitstream syntax and
`decoding semantics, allowing considerable innovation in optimization of encoding.
`
`676
`
`SPIE Vol. 3024 • 0277-786X1971$10.00
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 2
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`The MPEG-4 standard, was started in 1993 with the goal of very high compression coding at very low bitrates of 64
`kbitls or under. Coincidentally, the ITU-T also started two very low bit-rate video coding efforts: a short term effort to be
`completed by early 1996 intended to improve H.261 for coding at around 20 to 30 kbit/s, and a long term effort to be completed
`by late 1998 intended to achieve higher compression coding at similar bitrates. Currently, the ITU-T short term standard called
`H.263 [8] is complete and there is also an ongoing activity for improving this standard and the refined standard will be called the
`H.263+ standard. In the meantime, the ongoing MPEG-4 effort [9,10] is focussing on providing a new generation of interactivity
`with the audio-visual content, i.e., access to and manipulation of objects or in the coded representation of a scene. Furthermore,
`moderate improvement in the basic coding efficiency is also expected offset the overhead needed for content based and other
`functionalities. Up to now, optimization ofMPEG-4 has been carried with noninterlaced video at bitrates in range of 10 kbitls to
`1000 kbit/s. However, MPEG-4 is also expected to address higher bitrates and other video formats. Among the foreseen
`applications of MPEG-4 are mobile video phone/game/information access terminal, video answering machines and video email,
`interactive multimedia over internet, video catalogs, home shopping, virtual travel, surveillance, networked games etc.
`
`As mentioned earlier, the MPEG-4 video effort [9,10,14] is addressing a number of content based as well as traditional
`flinctionalities which can be grouped into three main areas - high compression, content based interactivity and universal
`accessibility. The development process consists of iterative refinement of the Verification Model (VM) which describes the
`coding method, via a set of well defined core experiments. The latest Verification Model is VM5.O [15]. Recently, following
`MPEG-4 workplan, a first draft ofthe standard describing the formal bitstream syntax and the decoding process was also released
`and is referred to as WD1.O [16]. In this paper we report on our experiments to improve the coding performance and functionality
`such as scalability for low bitrate video applications while employing the DCT coding framework ofthe VM5.O.
`
`The rest of this paper is organized as follows. In section 2, we present the basic coding structure employed in DCT
`coding framework of the MPEG-4 VM's. In section 3, we describe our proposed improvements to the DCT coding framework;
`these improvements have been recently accepted in the VM. In section 4, we present experimental results. In section 5, we
`summarize the main points ofthi s paper.
`
`2. CODING STRUCTURE
`
`In MPEG-4 video coding [15,16] a scene to be coded is thought of as composed of several Video Objects (VOs) such
`that each Video Object can further be coded as one or more scalability layers referred to as Video Object Layers (VOLs).
`Furthermore, the time instances (snapshots) of a Video Object are referred to as Video Object Planes (VOPs). Generally
`speaking, VOPs are expected to be 2D mappings ofVO's and thus considered to be of artbitary shape.VOPs are constructed by
`segmenting semantic objects of interest in each picture (frame) of a scene, thus one picture can be considered to be composed of
`one or more VOPs. If the entire scene is considered as one object and all VOPs are rectangular and of the same size as each
`picture then a VOP is identical to a picture. Similar to the fact that in MPEG-i or MPEG-2, a picture may be coded as an I-
`picture, P-picture or B-picture, in MPEG-4, a VOP can be coded as a 1-VOP, a P-VOP or a B-VOP. An 1-VOP is intra-coded, a
`P-VOP is predictive-coded and a B-VOP is bidirectionally-predictive-coded. Thus although in MPEG-4 each VOP can be
`arbitrary shape and there is significantly more flexibility in coding, there is a basic correspondence in coding structure of MPEG-
`1 , MPEG-2 and MPEG-4. Furthemore, for the case of rectangular VOPs of same size as each picture, the coding structure is
`practically identical.. For the case ofrectangular VOPs, in Figure 1 we show an example prediction structure which is similar to
`M=2 structure used in MPEG-i or MPEG-2 encoding. Such a structure is now possible due to recent introduction of B-VOPs.
`
`.
`
`!:T-T;T,::7- c::;:-"
`
`Figure 1 An example ofl-, P- and B-VOP based coding now allowed in the MPEG-4 VM
`
`The basic MPEG-4 VM coding currently employs motion compensation and DCT based coding. Each VOP is
`comprised ofmacroblocks that can be coded as intra- or as inter- macroblocks.The definition of a macroblock is exactly the same
`as in MPEG-i and MPEG-2. In 1-VOPs, only intra- macroblocks exist. In P-VOPs, intra as well as unidiretionall y predicted
`macroblocks can occur.where as in B-VOPs, both uni- or bidirectionally predicted- macroblocks can occur.
`
`3. Coding of I-, P- and B-VOPs
`
`677
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 3
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`We investigate three potential improvements. Ourfirst experiment [1 1,12] is on improved coding efficiency of intra. Our second
`experiment [13] is the study of coding of B-VOPs to allow additional functionality such as temporal scalability at low bit-rates.
`
`3.1 Intra-macroblock Coding in I- and P-VOPs
`We introduce improved prediction of DC coefficients of intra DCT blocks. For reference, H.263 does not include DC prediction
`while MPEG-i only allows a simple DC prediction. Then we introduce prediction of AC coefficients of intra Dct blocks, such
`prediction is not allowed in H.263 or MPEG-i. Further, we introduce block adaptive scanning of intra DCT coefficient blocks,
`again, this type of scanning is not included in H.263 or MPEG-i. Next, we propose use of a optimized VLC for intra DCT
`coefficient block coding, H.263 or MPEG-i do not alow such VLC's, however, MPEG-2 allows them but MPEG-2 VLC
`structure is optimized for higher bitrates.
`
`3.1.1 DC Prediction Improvement
`The DC prediction method of MPEG-i (or MPEG-2) is improved to allow adaptive selection of either the DC value of
`immediately previous block or that of the block immediately above it (in the previous row ofblocks). This adaptive selection of
`the DC prediction direction does not incur any overhead as the decision is based on comparison ofthe horizontal and vertical DC
`value gradients around the block whose DC value is to be coded.
`
`Figure 2 shows 4 surrounding blocks to the block whose DC value is to be coded. However, only three of the previous DC
`values are currently being used, the fourth value is anticipated to provide a better decision in the case of higher resolution images
`and may be used there. Assume, 'X', 'A', 'B', 'C and 'D' correspondingly refer to the current block, the previous block, the
`block above and to the left, the block immediately above, and the block above and to the right as shown.
`
`r B JC ]
`r A
`
`Figure 2 Previous neighboring blocks used in improved DC prediction
`
`The DC value of 'X' is predicted by either the DC value of block 'A' or the DC value of the block 'C based on the
`comparison of horizontal and vertical gradients by use of Graham's method as follows.
`
`The dc values 'dc' obtained after DCT are first quantized by 8 to generate 'DC' values.
`DC=dc//8
`
`if(DCA DCBI < IDCB DCcI)
`DC = DCc
`DC = DCA
`
`else
`
`S
`
`.
`
`For DC prediction the following simple rules are used:
`Ifany of the blocks A, B or C are outside of the VOP boundary, their DC values are assumed to take a value of 128
`and are used to compute prediction values.
`In context of computing DC prediction for block 'X', if the absolute value of a horizontal gradient (IDCA -DCBI) is
`less than the absolute value of a vertical gradient (DCB - DCcI), then the prediction is the DC value of block 'C',
`otherwise, DC value of block 'A' is used for prediction. This process is independently repeated for every block of a
`macroblock using appropriate immediately horizontally adjacent block 'A' and and immediately vertically adjacent
`block 'C'.
`• DC predictions are performed identically for the luminance component as well as each of the two chrominance
`components.
`
`678
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 4
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`3.1.2 AC Coefficient Prediction: Prediction of First Row or First Column
`Either coefficients from the entire or part of the first row or the entire or part of the first column of a previous coded block
`are used to predict the co-located coefficients of the current block. For best results, the number of coefficients of a row or
`colunm and the precise location of these coefficients needs to be identified and adapted in coding different pictures and
`even within the same picture. This however results in either too much complexity or too much overhead. A practical
`solution is to use a predetermined number ofcoefficients for prediction, for example, we use 7 ac coefficients.
`On a block basis, the best direction (from among horizontal and vertical directions) for DC coefficient prediction is also
`used to select the direction for AC coefficients prediction. An example of the process of AC coefficients prediction
`employed is shown in Figure 3.
`
`WHW
`
`:
`
`Hi H "NI1 :
`
`Figure 3 Previous neighboring blocks and coeficients used in improved AC prediction
`
`Since, the improved AC prediction mainly employs prediction from either the horizontal or the vertical directions, whenever
`diagonal edges, coarse texture or combinations ofhorizontal and vertical edges occur, the AC prediction does not work very well
`and needs to be disabled. While ideally one would like to turn off AC prediction on a block basis, this generates too much
`overhead; thus we disable AC prediction at the macroblock basis. The criterion for AC prediction enable/disable is discussed in
`next.
`
`In the cases when AC coefficient prediction results in a larger magnitude error signal as compared to the original signal, it is
`desirable to disable AC prediction. However, the overhead is excessive if AC prediction is switched on or off every block so AC
`prediction switching is performed ona macroblock basis.
`If block 'A' was selected as the DC predictor for the block for which coefficient prediction is to be performed, we calculate a
`criterion, 5, as follows.
`
`S = (
`
`AC0 I — I AQ — AQA I )
`
`Ifblock 'C' was selected as the DC predictor for the block for which coefficient prediction is to be performed, we calculate
`S as follows.
`
`.
`
`679
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 5
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`Next if for all blocks for which a common decision is to be made (in this case on a macroblock basis) a single YS is
`calculated and the ACpredflag is either set! reset to enable/disable AC prediction as follows.
`if(S (cid:18) 0) ACpred_flag=1
`else ACpred_flag=O
`
`3.1.3 Scanning of DCT coefficients
`In H.263 or MPEG-i the intra block DCT coefficients are scanned by the zigzag scan to generate run-level events that are VLC
`coded. The zigzag scan works well on the average and can be looked upon as a combination of three types of scans, a horizontal
`type of scan, a vertical type of scan and a diagonal type of scan. Often in natural images, on a block basis, a predominant
`preferred direction for scanning exists depending on the orientation of significant coefficients.
`We propose two scans (in addition to the zigzag scan) such that in coding a block (or a number of blocks, depending on the
`overhead incurred), a scanning direction is chosen which results in more efficient scanning of coefficients to produce (run,level)
`events that can be efficiently entropy coded as compared to scanning by zigzag scan alone. These two additional scans are
`referred to as altemate-hor and altemate-vert (used in MPEG-2 for block scanning of DCT coefficients of interlaced video) and
`along with the zigzag scan are shown in Figures 4(a), 4(b) and 4(c).
`
`0
`
`4
`
`6
`
`1
`
`5
`
`7
`
`20
`
`21
`
`2
`
`8
`
`19
`
`24
`
`3
`
`9
`
`18
`
`25
`
`11
`
`16
`
`27
`
`31
`
`10
`
`17
`
`26
`
`30
`
`42
`
`12
`
`15
`
`28
`
`32
`
`44
`
`13
`
`14
`
`29
`
`33
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`8
`
`9
`
`6
`
`7
`
`19
`
`18
`
`20
`
`21
`
`24
`
`25
`
`22
`
`23
`
`34
`
`35
`
`36
`
`37
`
`40
`
`41
`
`38
`
`39
`
`50
`
`51
`
`52
`
`53
`
`54
`
`55
`
`0
`
`2
`
`3
`
`9
`
`1
`
`4
`
`8
`
`11
`
`5
`
`7
`
`12
`
`18
`
`6
`
`13
`
`17
`
`24
`
`14
`
`16
`
`25
`
`31
`
`15
`
`26
`
`30
`
`40
`
`27
`
`29
`
`41
`
`44
`
`28
`
`42
`
`43
`
`53
`
`22
`
`36
`
`38
`
`52
`
`23
`
`37
`
`39
`
`53
`
`34
`
`40
`
`50
`
`54
`
`35
`
`41
`
`51
`
`55
`
`43
`
`47
`
`57
`
`61
`
`46
`
`56
`
`60
`
`45
`
`49
`
`59
`
`63
`
`48
`
`58
`
`62
`
`10
`
`11
`
`12
`
`13
`
`17
`
`16
`
`15
`
`14
`
`26
`
`27
`
`28
`
`29
`
`30
`
`31
`
`32
`
`33
`
`42
`
`43
`
`44
`
`45
`
`46
`
`47
`
`48
`
`49
`
`56
`
`57
`
`58
`
`59
`
`60
`
`61
`
`62
`
`63
`
`10
`
`20
`
`21
`
`35
`
`19
`
`22
`
`34
`
`36
`
`23
`
`33
`
`37
`
`48
`
`32
`
`38
`
`47
`
`49
`
`39
`
`46
`
`50
`
`57
`
`45
`
`51
`
`56
`
`58
`
`52
`
`55
`
`59
`
`62
`
`54
`
`60
`
`61
`
`63
`
`Figure 4(a) Alternate Horizontal scan Figure 4(b) Alternate Vertical (MPEG-2) scan
`
`Figure 4(c) Zigzag scan
`
`There is however an important tradeoff in the amount of savings that result from scan adaptation versus the overhead required in
`block to block scan selection. Furthermore, if the selection of scan is based on counting the total bits generated by each scanning
`method and selecting the one that produces the least bits then complexity becomes an important issue. The key thus is that the
`scan selection overhed be minimized. Thus criterion of previous subsection used to decide AC prediction direction is now
`employed to indicate the scan direction also. If ACpred_flag=O, zigzag scan is selcted for all blocks in a macroblock, otherwise,
`DC prediction direction (hor/vert) is used to slect a scan on block basis. For instance if the DC prediction refers to the
`horizontally adjacent block, alternate-vert scan is selected for the current block, otherwise (for DC prediction referring to
`vertically adjacent block), altemate-hor scan is used for the current block.
`
`3.1.4 Variable Length Coding
`Neither the H.263 nor the MPEG-i standard allows a separate variable length code (VLC) table for DCT cofficients of intra
`blocks forcing use of the inter block DCT VLC table which is inefficient for intra blocks. The MPEG-2 standard does allow a
`separate VLC table for intra blocks but it is optimized for much higher bitrates. We propose an additional table optimized for
`coding of AC coefficients of intra blocks [13]. Furthermore, after examining the statistics of intra luminance blocks and intra
`chrominance blocks we recommend use of this VLC table only for AC coefficients of intra luminance DCT coefficient block, for
`intra chrominance block we recommend using the inter VLC table ofH.263 (also employed in the MPEG-4 VM). Thus the VLC
`coding of intra blocks can be summarized as follows.
`.
`The H.263 VLC table of the VM is used for coding of ac coefficients of DCT chrominance blocks of intra coded
`macroblocks
`Th VLC Table of [13] is used for coding of ac coefficients of DCT luminance blocks of Intra coded macroblocks. An
`important exception that allows further bit savings is mentioned at the end of this table and employs a trick to reduce the
`number of bits for coding a specific event (run=O, level=2) by reusing the codeword for End-of-Block (EOB) since in
`H.263(MPEG-4 like intra coding syntax, EOB can't occur as the first code for a coded block.
`
`I
`
`680
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 6
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`3.2 Inter-macroblock Coding in P-VOPs
`We perform the coding of inter-macroblocks in P-VOPs similar to that in the VM or H.263 based encoding. Thus, either
`one or 4 motion vectors are allowed per macroblock. Motion estimation is performed by exhaustive search to determine integer
`pixel accurate motion vectors for 1 6x16 luminance block of each macroblock followed by half-pixel search. Motion estimation
`for computing 8x8 luminance block motion vectors is performed using 16x16 block motion vector as the guesss and a small
`refmement is performed. Mode decisions allow choice of 16x16 or 8x8 motion vector mode on the macroblock basis. Further, on
`top of choice of motion vector mode, it is also possible to select a coding mode in which explicit quantizer update may be
`performed; these decisions are collectively referred to as macroblock type selection.
`
`We are continuing effort in the direction of adaptive scanning and efficient motion vector coding by using similar
`prediction as that used in our improved DC prediction to improve the coding efficiency of P-VOPs. These experiments are still in
`progress and only partial results exist (and are not reported in this paper).
`
`3.3 Coding of B-VOPs and Temporal Scalability
`Earlier in [8] we had considered a techinque to allow improved coding ofB-VOPs. However, that technique incrases the
`coding delay for low bitrate visual communication applications. further study on that technique is likely to continue.
`
`As mentioned earlier, macroblock coding in B-VOPs can employ either unidirectional prediction (like the one employed
`by inter macroblocks in P-VOPs) or bidirectional interpoative prediction. The proposed macroblok coding syntax for B-VOPs
`efficiently incorporates the low overhead of H.263 based B-block coding in PB-frames and the flexibility of independent motion
`prediction in forward or/and backward directions as needed. Further, we explicitly remove the restrictions in H.263 ofportion of
`macroblock area that can be used in prediction in B-blocks. The decision ofwhether to use the "direct mode" derived from H.263,
`or "forward", "backward" or "bidirectional" modes ofMPEG-1 is allowed individually for each macroblock in a B-VOP.
`
`The unique property of B-VOPs (and also of B-pictures) is that they are coded outside of the main interframe predictive
`loop and thus are non-causal. B-VOPs contribute to overall improved coding efficiency and work similar to B-pictures.
`Furthermore, B-VOPs similar to B-pictures can also be used for a simple, yet effective form of scalability referred to as temporal
`scalability which can provide the ability to selectively discard part of the coded bitstream for ease of decoding complexity,
`adapting to varying channel bandwidth or simply increased error resilience. In this experiment, we separate the B-VOPs into an
`enhancement layer and examinebitrate/quality tradeoffs between basic rate VOPs (base-layer) and enhancement VOPs
`(enhancement layer) under the constraints oflow bitrates.
`
`Enhancement
`Layer
`
`Base
`Layer
`
`-
`
`Figure 5 B-VOPs arranged to provide Temporal scalability
`
`4. RESULTS
`
`We now present results of the two described experiments on several MPEG-4 standard test scenes at QCIF and CIF resolutions.
`For the intra coding experiment a number of different quantizer values are chosen. For the B-VOP experiment, fixed target
`bitrates for the combination of base and enhancement layer bitrates is chosen. All simulations use fized quantizer for entire frame,
`however, in the case of B-VOP coding, there is an exception such that whenever "Direct" mode is chosen, the quantizer for those
`macroblocks is automatically generated by scaling of corresponding macroblock quantizer in the following P-VOP.
`
`681
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 7
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`4. 1 Intra-macroblock Coding Results on 1-VOPs
`Now, in Tables 1, 2 and 3 we present results [13] ofour intra coding experiment [1 1,13] on 1-VOPs.
`Table 1 SNR and Bit Counts oflntra coding at CIF resolution with and without proposed DC pred, AC pred and VLC
`
`Bits: MPEG-i
`DC pred (%age
`reduc)
`
`Bits: Proposed
`DC pred (%age
`reduc)
`
`94477 (- 5.89)
`55354 (- 9.65)
`
`92196 (- 8. 16)
`
`Bits: Proposed
`DC pred and
`AC VLC (%age
`reduc)
`82953 (-17.37)
`
`Bits: Proposed DC
`pred, AC pred and
`AC VLC (%age
`reduc)
`79792 (-20.51)
`
`53073 (-13.37)
`
`49685 (-1 8.90)
`
`40669 (-12.68)
`
`38388 (-17.59)
`
`33045(-15.17)
`
`30764(-21.03)
`
`36951 (-20.67)
`30182(-22.52)
`
`47987 (-21.67)
`36062 (-22.58)
`29828 (-23.43)
`
`28587(-l7.13)
`
`26306(-23.74)
`
`25997(-24.64)
`
`26128 (-24.26)
`
`25465(-18.83)
`
`192443 (- 3.90)
`96016 (- 7.52)
`
`23054(-26.52)
`
`23214(-26.O1)
`
`174496 (-12.86)
`
`171806 (-14.20)
`
`92265 (-1 1. 13)
`
`90044 (-13.27)
`
`Sequence
`
`SNR,
`Y
`
`Bits:
`H.263
`
`42.84
`
`100387
`
`38.78
`
`61264
`
`36.40
`
`46579
`
`34.69
`
`33.43
`
`32.44
`
`38955
`
`34497
`31375
`
`38.99
`
`200251
`
`33.89
`
`103824
`
`3 1 .44
`
`—4 8 1
`
`2
`
`16
`
`20
`
`24
`
`Akiyo
`
`70603
`
`62795 (-1 1 .06)
`
`23184(-26.11)
`191220 (- 4.51)
`94793 (- 8.69)
`61 572 (-12.79)
`
`61554 (-12.82)
`
`46030(-14.50)
`
`44807(-16.77)
`
`45499(-15.49)
`
`59776 (-15.33)
`44269 (-17.77)
`
`29.86
`
`53838
`
`28.78
`
`43681
`
`35873(-17.88)
`
`34650(-20.67)
`
`3583i(-17.97)
`
`34919(-20.06)
`
`28.01
`
`37921
`
`301 13 (-20.59)
`
`28890 (-23.81)
`
`29884 (-21.19)
`
`29106 (-23.25)
`
`39.03
`
`175033
`
`34.49
`
`32.34
`
`30.97
`
`86219
`
`59075
`
`45551
`
`170353(-2.67)
`8 1539 (- 5.43)
`
`l68803(-3.56)
`79989 (- 7.22)
`
`158263(-9.58)
`77948 (- 9.59)
`
`154062(-1l.98)
`
`74524 (-13.56)
`
`54395(-7.92)
`
`52845(-10.55)
`
`5l739(-12.42)
`
`49218 (-16.69)
`
`40871 (-10.27)
`
`39321 (-13.68)
`
`38482 (-15.52)
`
`4 8 1
`
`2
`
`16
`
`20
`
`24
`
`4 8 1
`
`2
`
`16
`
`Coastguard
`
`Silent
`
`36680 (-19.47)
`
`33461(-l2.27)
`
`31911(-16.33)
`
`31845(-16.51)
`
`30534(-19.94)
`
`29290(-l3.78)
`
`27740(-18.34)
`
`27905(-17.85)
`
`26468 (-22.08)
`
`86590 (- 7.04)
`
`84666 (- 9.10)
`
`78541 (-15.68)
`
`74201 (-20.34)
`
`47522(-12.12)
`34455 (-15.98)
`27572(-19.21)
`23825 (-21.58)
`21702 (-30.83)
`
`45598(-9.64)
`32531 (-20.67)
`25648(-24.85)
`21901 (-27.90)
`19778 (-36.96)
`
`43505(-19.55)
`31338 (-23.58)
`25343(-25.74)
`21949 (-27.75)
`19936 (-36.45)
`
`40775 (-24.60)
`29544 (-27.96)
`23612(-30.8l)
`20431 (-32.75)
`
`19061 (-39.25)
`
`136887(-3.97)
`80369 (- 6.57)
`
`134819(-5.42)
`78301 (- 8.98)
`
`117502(-17.57)
`
`108300(-24.02)
`
`69817 (-18.84)
`
`62681 (-27.14)
`
`20
`
`30.07
`
`.±__
`
`4 8 1
`
`2
`16
`
`20
`
`4 8 1
`
`2
`
`16
`
`Mother
`
`Hall
`
`38141
`
`33970
`
`93145
`
`54077
`
`41010
`34127
`30380
`
`31375
`
`29.38
`
`42.12
`
`38.01
`
`35.84
`34.47
`
`33.44
`
`32.60
`
`41.00
`
`142543
`
`37.30
`
`86025
`
`34.97
`33.24
`
`59127(-8.73)
`4813 1 (-10.52)
`40926(-12.14)
`35989 (-13.58)
`
`139735 (- 3.37)
`73471 (- 6.22)
`
`5l467(-8.63)
`
`57059(-11.92)
`46063 (-14.36)
`38858(-16.58)
`33921 (-18.55)
`
`138829 (- 3.99)
`72565 (- 7.38)
`
`52789(-17.18)
`43429 (-19.26)
`37427(-19.65)
`32927 (-20.93)
`
`46897(-27.61)
`38496 (-28.43)
`33589(-27.89)
`29669 (-28.76)
`
`125 192 (-13.43)
`
`123964 (-14.27)
`
`68176 (-12.98)
`
`67486 (-13.86)
`
`50561(-l0.26)
`
`48689(-13.58)
`
`48234(-14.39)
`
`40985(-10.62)
`
`40079(-l2.60)
`
`38818(-15.35)
`
`38819(-15.35)
`
`34445(-12.39)
`
`33539(-14.70)
`
`32697(-16.84)
`
`32786 (-16.61)
`
`30254(-13.87)
`
`29348(-l6.50)
`
`28973(-17.52)
`
`29232(-16.78)
`
`64783
`53787
`46582
`
`41645
`
`20
`
`3±_
`
`31.88
`
`30.74
`
`40.08
`
`144607
`
`35.91
`
`78343
`
`33.76
`
`56339
`
`32.24
`
`45857
`
`31.07
`
`39317
`
`30.17
`
`35126
`
`4 8 1
`
`2
`
`16
`
`20
`
`.±_
`
`Foreman
`
`682
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 8
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`News
`
`4
`
`8
`
`12
`
`16
`
`20
`
`37.10
`
`34.46
`
`32.58
`
`3 1.23
`
`24
`30.15
`7— 40.12
`8
`35.65
`
`41.65
`
`157505
`
`93215
`
`68386
`
`54905
`
`46874
`
`41480
`
`180091
`
`101270
`
`Container
`
`12
`
`16
`
`33.23
`
`73845
`
`31.54
`
`59082
`
`152100(-3.43)
`87810 (- 5.80)
`62981 (- 7.90)
`
`150012(-4.76)
`85722 (- 8.04)
`
`131694(-16.39)
`
`126643(-19.59)
`
`78206 (-16.10)
`
`75366 (-19.15)
`
`60893 (-10.96)
`
`57063 (-16.56)
`
`55382 (-19.01)
`
`49500(-9.84)
`
`47412(-13.65)
`
`45586(-16.97)
`
`44526 (-18.90)
`
`41469 (-1 1.53)
`
`39381 (-15.99)
`
`38223 (-18.46)
`
`37549 (-19.89)
`
`36075(-13.03)
`
`33987(-18.06)
`
`33376(-19.54)
`
`32814(-20.89)
`
`172978(-3.95)
`94157 (- 7.02)
`
`171342(-4.86)
`92521 (- 8.64)
`
`152682(-15.22)
`
`147897(-17.88)
`
`84936 (-16.13)
`
`80339 (-20.67)
`
`66732(-9.63)
`
`65096(-11.85)
`
`61065(-17.31)
`
`56848 (-23.02)
`
`51969(-12.04)
`
`50333(-14.81)
`
`47892(-18.94)
`
`44557(-24.58)
`
`20
`
`30.36
`
`29.3 1
`
`50637
`
`44523
`
`43524(-14.05)
`
`41888(-17.26)
`
`40392(-20.23)
`
`37592 (-25.76)
`
`37410 (-15.98)
`
`35774 (-19.65)
`
`35013 (-22.25)
`
`32514 (-26.97)
`
`Table 2 SNR and Bit Counts of Intra coding at QCIF resolution with and without proposed DC pred, AC pred and VLC
`
`Bits: MPEG-i
`DC pred(%age
`reduc)
`
`Bits: Proposed
`DC pred (%age
`reduc)
`
`38943 (- 1.90)
`
`38307 (- 3.50)
`
`Bits: Proposed
`DC pred and
`AC VLC (%age
`reduc)
`34668 (-12.67)
`
`Bits: Proposed
`DC pred, AC pred
`and AC VLC
`(%age reduc)
`33683 (-15.15)
`
`21805(-3.34)
`
`21169(-6.16)
`
`20025(-11.23)
`
`19604(-i3.lO)
`
`15297(-4.69)
`
`i4661(-8.66)
`
`i3974(-12.94)
`
`13929(-13.22)
`
`11914(-5.95)
`
`i1278(-lO.97)
`
`1i096(-12.4i)
`
`11O1O(-13.lO)
`
`10079(-6.96)
`
`9443(-12.83)
`
`9357(-13.62)
`
`9239(-14.71)
`
`8i68(-14.54)
`
`8122(-15.02)
`
`8018 (-16.11)
`
`Sequence
`
`SNR,
`Y
`
`Bits:
`H.263
`
`41.69
`
`36.76
`
`39697
`
`22559
`
`34.08
`
`16051
`
`32.48
`
`12668
`
`31.29
`
`10833
`
`30.26
`
`9558
`
`5 1294
`
`—4 8 1
`
`2
`
`16
`
`20
`
`24
`
`Akiyo
`
`8804(-7.88)
`49490 (- 3.52)
`
`49101 (- 4.27)
`
`45342 (-1 1 .60)
`
`44038 (-14.14)
`
`24334(-6.90)
`
`23945(-8.39)
`
`23689(-9.37)
`
`22959(-13.85)
`
`15565 (-iO.39)
`
`15 176 (-12.62)
`
`15176 (-12.62)
`
`14653 (-15.64)
`
`11363(-i3.70)
`
`10974(-16.66)
`
`i1205(-15.00)
`
`10585(-i9.61)
`
`8901 (-16.85)
`
`8512 (-20.49)
`
`8779 (-18.01)
`
`8287 (-22.58)
`
`7560 (-19.26)
`
`7171 (-23.42)
`
`7323 (-21.79)
`
`6866 (-26.68)
`
`51470 (- 1.70)
`
`51 134 (- 2.34)
`
`46537 (-1 1.12)
`
`45432 (-13.23)
`
`26183(-3.29)
`
`25847(-4.53)
`
`24477(-9.59)
`
`23642(-12.68)
`
`17065(-8.97)
`
`16729(-6.83)
`
`16394(-8.69)
`
`15915 (-11.36)
`
`38.50
`
`33.62
`
`26i38
`
`3 1.29
`
`17369
`
`4 8 i
`
`2
`
`16
`
`29.89
`
`13167
`
`Coastguard
`
`20
`.—
`
`28.78
`
`10705
`
`28.09
`
`9364
`
`39.40
`
`52361
`
`34.48
`
`27074
`
`4 8 1
`
`Silent
`
`2
`
`31.96
`
`17956
`
`30.42
`
`16
`
`13756
`
`12865(-6.48)
`
`12529(-8.92)
`
`12430(-9.64)
`
`11996 (-12.79)
`
`29.30
`
`11510
`
`28.24
`
`9797
`
`40.83
`
`36.23
`
`33.91
`
`35212
`
`19050
`
`13712
`
`32.41
`
`1 1000
`
`31.32
`
`30.54
`
`9354
`
`8365
`
`10619(-7.74)
`
`10283(-10.66)
`
`10218(-11.23)
`
`9871 (-14.24)
`
`8906(-9.09)
`
`8570(-12.52)
`
`8532(-12.91)
`
`8345 (-14.82)
`
`34299(-2.59)
`
`33610(-4.55)
`
`30860(-12.35)
`
`28596 (-18.79)
`
`18137(-4.79)
`
`17448(-8.41)
`
`16713(-12.26)
`
`15120(-20.63)
`
`12799(-6.66)
`10087 (- 8.30)
`
`8441(-9.76)
`
`12110(-11.68)
`
`11786(-14.05)
`
`10583 (-22.82)
`
`9398 (-14.56)
`
`9227 (-16. 12)
`
`8291 (-24.63)
`
`7752(-17.13)
`
`7708(-17.60)
`
`7007(-25.10)
`
`7452(-10.91)
`
`6763(-19.15)
`
`6809(-18.60)
`
`6144(-26.55)
`
`683
`
`20
`.—
`
`4 8 1
`
`2
`
`16
`
`20
`
`-.—
`
`Mother
`
`Unified Patents, LLC v. Elects. & Telecomm. Res. Inst., et al.
`
`Ex. 1015, p. 9
`
`

`

`Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 12 Sep 2020
`Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
`
`49419 (- 2.04)
`
`49058 (- 2.04)
`
`42290 (-16. 17)
`
`40586 (-19.55)
`
`28386(-3.49)
`
`28025(-4.72)
`
`25259(-14.13)
`
`24018 (-18.35)
`
`20175(-4.85)
`
`19814(-6.55)
`
`18528(-12.62)
`
`17539(-17.28)
`
`15682(-6.15)
`
`15321(-8.31)
`
`14619(-12.51)
`
`13651 (-18.31)
`
`13090(-7.28)
`
`12729(-9.83)
`
`12342(-12.58)
`
`11547 (-18.21)
`
`11049(-8.51)
`
`10688(-11.50)
`
`10590(-12.31)
`
`10076 (-16.56)
`
`48289 (- 1.43)
`26678 (- 2.56)
`
`48041 (- 1.94)
`26430 (- 3.47)
`
`42146 (-13.97)
`
`41548 (-15.19)
`
`24388 (-10.92)
`
`23891 (-12.74)
`
`18792(-3.60)
`
`18544(-4.87)
`
`17607(-9.68)
`
`17217 (-11.68)
`
`14782(-4.53)
`
`14534(-6.13)
`
`14111(-8.86)
`
`13740(-11.26)
`
`12230(-5.42)
`
`11982(-7.92)
`
`11622(-10.12)
`
`11329 (-