Performance Comparison of Hevc Main Still Picture Profile

FINAL REPORT FOR MULTIMEDIA PROCESSING

PERFORMANCE COMPARISON OF HEVC MAIN STILL PICTURE PROFILE

SPRING 2015 MULTIMEDIA PROCESSING- EE 5359 05/11/2015

ADVISOR: DR. K. R. RAO DEPARTMENT OF ELECTRICAL ENGINEERING UNIVERSITY OF TEXAS, ARLINGTON

DEEPU SLEEBA PHILIP 1001038966 [email protected] TABLE OF CONTENTS

1. Acronyms And Abbreviations...... 2 2. Objective Of The Project...... 3 3. Overview Of HEVC...... 3 4. WebP...... 10 5. Performance Comparison Metrics...... 15 6. Implementation...... 15

1 | P a g e 7. Results...... 16 8. Test Images...... 28 9. Test Configuration...... 29 10. Conclusions...... 30 11. Appendix...... 31 12. References...... 33

2 | P a g e 1. Acronyms And Abbreviations  AMVP: Advanced motion vector prediction  AVC: Advanced Video Coding  BD-PSNR: Bjontegaard metric calculation  BSD: Berkeley Software Distribution  CABAC: Context Adaptive Binary Arithmetic Coding  CB: Coding Block  CIF: Common Intermediate Format  CU: Coding Unit  CTB: Coding Tree Block  CTU: Coding Tree Unit  DCT: Discrete Cosine Transforms  DST: Discrete Sine Transform  EBCOT: Embedded block coding with optimized truncation

 GIF: Graphics interchange format  HD: High Definition  HEVC: High Efficiency Video Coding  JCT-VC: Joint Collaborative Team on Video Coding  MC: Motion Compensation  ME: Motion Estimation  MPEG: Moving Picture Experts Group  MSP: Main Still Picture Profile  MV: Motion Vector  NGOV: Next Generation Open Video  PCS: Professional Communication Society  PNG: Portable Network Graphics  PSNR: Peak Signal To Noise Ratio  PU: Prediction Unit  QP: Quantization Parameter  QCIF: Quarter Common Intermediate Format  RD: Rate Distortion

3 | P a g e  SAO: Sample Adaptive Offset  SAD: Sum of Absolute Differences  SATD: Sum of Absolute Transformed Differences (SATD)  SHVC: Scalable HEVC  SSIM: Structural Similarity  SVC: Scalable Video Coding  TM: True Motion  TU: Transform Unit  URQ: Uniform Reconstruction Quantization  VCEG: Visual Coding Experts Group 2.Objective: • The aim of this project is to compare the rate-distortion performance analysis of the HEVC MSP profile with that of WebP • The peak-signal-to-noise ratio (PSNR) and the average bit rate savings in terms of Bjøntegaard delta rate (BD) is considered for this comparison

3.Overview of HEVC:

• The High Efficiency Video Coding (HEVC) standard is the most recent joint video project of the ITU-T Visual Coding Experts Group (VCEG) and the ISO/IEC Moving Picture Experts Group (MPEG) standardization organizations, working together in a partnership known as the Joint Collaborative Team on Video Coding (JCT-VC) [1]. • It is widely used for many applications, including broadcast of high definition (HD) TV signals over satellite, cable, and terrestrial transmission systems, video content acquisition and editing systems, camcorders, security applications, Internet and mobile network video, Blu-ray Discs, and real-time conversational applications such as video chat, video conferencing, and telepresence systems. However, an increasing diversity of services, the growing popularity of HD video, and the emergence of beyond- HD formats (e.g., 4k×2k or 8k×4k resolution) are creating even stronger needs for coding efficiency superior to H.264/ MPEG-4 AVC’s capabilities. An increased desire for higher quality and resolutions is also arising in mobile applications [2].

4 | P a g e Block Diagram of HEVC ENCODER and DECODER :

Figure 1: Block Diagram of HEVC Encoder (with decoder modelling elements shaded in light gray). [3]

Figure. 1a HEVC Decoder Block Diagram [29]

5 | P a g e 3.1 Macro block concept and Prediction block sizes: The concept of macro-block in HEVC [3] is represented by the Coding Tree Unit (CTU). CTU size can be 16x16, 32x32 or 64x64, while AVC macro-block size is 16x16. Larger CTU size aims to improve the efficiency of block partitioning on high resolution video sequence. Larger blocks provoke the introduction of quad-tree partitioning of a CTU into smaller coding units (CUs). A coding unit is a bottom-level quad-tree syntax element of CTU splitting. The CU contains a prediction unit (PU) and a transform unit (TU). The TU is a syntax element responsible for storing transform data. Allowed TU sizes are 32x32, 16x16, 8x8 and 4x4. The PU is a syntax element to store prediction data like the intra-prediction angle or inter-prediction motion vector. The CU can contain up to four prediction units. CU splitting on PUs can be 2Nx2N, 2NxN, Nx2N, NxN, 2NxnU, 2NxnD, nLx2N and nRx2N where 2N is a size of a CU being split. In the intra-prediction mode only 2Nx2N PU splitting is allowed. An NxN PU split is also possible for a bottom level CU that cannot be further split into sub CUs. 3.2 Coding units (CUs) and coding blocks (CBs):

Figure 2. 64*64 CTBs split into CBs [3]

6 | P a g e The quad tree syntax of the CTU specifies the size and positions of its luma and croma CBs. The root of the quad tree is associated with the CTU. Hence, the size of the luma CTB is the largest supported size for a luma CB. The splitting of a CTU into luma and croma CBs is signaled jointly. One luma CB and ordinarily two croma CBs, together with associated syntax, form a coding unit (CU) as shown in Figure.3.

Figure 3. CUs split into CBs [3]

3.3 Prediction Modes : 3.3.1 Intra Prediction Modes : There are a total of 35 intra-prediction modes in HEVC: planar (mode 0), DC (mode 1) (fig.4) and 33 angular modes (modes 2-34 in Figure 4). DC intra- prediction is the simplest mode in HEVC. All PU pixels are set equal to the mean value of all available neighbouring pixels. Planar intra-prediction is the most computationally expensive. It is a two- dimensional linear interpolation. Angular intra-prediction modes 2-34 are linear interpolations of pixel values in the corresponding directions. Vertical intra-prediction (modes 18- 34) is an updown interpolation of neighbouring pixel values. Also, intra prediction can be done at different block sizes, ranging from 4 X 4 to 64 X 64.

7 | P a g e Fig 4: Modes and directional orientations for intra picture prediction [9]

3.3.2 Inter Prediction : Each PU is predicted from image data in one or two reference pictures (before or after the current picture in display order), using motion compensated prediction. Transform and Quantization Any residual data remaining after prediction is transformed using a block transform based on the integer Discrete Cosine Transform (DCT) [4]. Only for 4x4 intra luma, a transform based on Discrete Sine Transform (DST) is used. One or more block transforms of size 32x32, 16x16, 8x8 and 4x4 are applied to residual data in each CU. Then the transformed data is quantized. 3.3.3 Entropy coding: Context adaptive binary arithmetic coding (CABAC) is used for entropy coding. This is similar to the CABAC scheme in H.264/MPEG-4 AVC, but has undergone several improvements to improve its throughput speed (especially for parallel-processing architectures) and its compression performance, and to reduce its context memory requirements.

3.3.4 In-loop deblocking filtering: A deblocking filter similar to the one used in H.264/MPEG-4 AVC is operated within the inter picture prediction loop. However, the design is simplified in regard to its decision-making and filtering processes, and is made more friendly to parallel processing.

8 | P a g e 3.3.5 Sample adaptive offset (SAO): A nonlinear amplitude mapping is introduced within the inter picture prediction loop after the deblocking filter. Its goal is to better reconstruct the original signal amplitudes by using a look-up table that is described by a few additional parameters that can be determined by histogram analysis at the encoder side.

4. Overview of WebP:

9 | P a g e figure 6: Block Diagram of VP8 Encoder [21]

WebP is an image format employing both lossy and lossless compression [19]. It is currently developed by Google, based on technology acquired with the purchase of On2 Technologies. As a derivative of the VP8 video format, it is a sister project to the WebM multimedia container format. WebP-related software is released under a BSD license. The format was first announced in 2010 as a new open standard for lossily compressed true- color graphics on the web, producing smaller files of comparable image quality to the older JPEG scheme [19]. According to Google's measurements, a conversion from PNG to WebP results in a 45% reduction in file size when starting with PNG found on the web, and a 28% reduction compared to PNG that are recompressed with pngcrush and pngout. [19] Google has proposed using WebP for animated images as an alternative to the popular GIF format, citing the advantages of 24-bit color with transparency, combining frames with lossy and lossless compression in the same animation, and as well as support for seeking to

10 | P a g e specific frames. Google reports a 64% reduction in file size for images converted from animated GIF to lossy WebP, and a 19% reduction when converted to lossless WebP. [19] 4.1 Prediction Techniques WebP's lossy compression uses the same methodology as VP8 for predicting (video) frames. VP8 is based on block prediction and like any block-based codec, VP8 divides the frame into smaller segments called macro-blocks. It has two prediction modes : Intra prediction uses data within a single video frame and Inter prediction uses data from previously encoded frame. 4.1.1 Intra Prediction: WebP has three types of blocks:  4x4 luma  16x16 luma  8x8 chroma Four common intra prediction modes used by these blocks are: H_PRED (horizontal prediction): Fills each column of the block with a copy of the left column, L. V_PRED (vertical prediction) : Fills each row of the block with a copy of the above row, A. DC_PRED (DC prediction): Fills the block with a single value using the average of the pixels in the row above A and the column to the left of L [16]. TM PRED (True Motion prediction): In addition to the row A and column L, TM_PRED uses the pixel C above and to the left of the block. Horizontal differences between pixels in A and vertical differences between pixels in L are propagated (starting from C) to form the prediction block. For 4x4 luma blocks, there are six additional intra modes corresponding to predicting pixels in different directions. As mentioned above, the TM_PRED mode is unique to VP8. Fig. 7 uses a 4x4 block as example to illustrate how the TM_PRED mode works:

In Fig. 7, C, A and L represent reconstructed pixel values from previously coded blocks, and Xoo through X33 represent predicted values for the current block. TM_PRED uses the following

11 | P a g e equation to calculate Xij = Li + Aj - C (i,j=0, 1, 2, 3). The TM PRED prediction mode for 8x8 and 16x16 blocks works in a similar fashion. Among all the intra prediction modes, TM PRED is one of the more frequently used modes in VP8. For natural video sequences, it is typically used by 20% to 45% of all intra coded blocks. Together, these intra prediction modes help VP8 to achieve high compression efficiency, especially for key frames, which can only use intra modes.

figure 7: Illustration of intra prediction mode TM_PRED [16]

4.1.2 Inter prediction Modes: Inter prediction modes are used on inter frames (non- keyframes). For any VP8 inter frame, there are typically three previously coded reference frames that can be used for prediction. A typical inter prediction block is constructed using a motion vector to copy a block from one of the three frames. The motion vector points to the location of a pixel block to be copied. In video compression schemes, a good portion of the bits is spent on encoding motion vectors; the portion can be especially large for video encoded at lower data rates. VP8 provides efficient motion vector coding by reusing motion vectors from neighboring macro-blocks. For example, the prediction modes "NEAREST' and "NEAR" make use of last and second-to-last, non-zero motion vectors from neighboring macro-blocks. These inter prediction modes can be used in combination with any of the three different reference frames. In addition, VP8 has a sophisticated, flexible inter prediction mode called SPLITMV. This mode was designed to enable flexible partitioning of a macro-block into sub-blocks to achieve better inter

12 | P a g e prediction. SPLITMV is useful when objects within a macro-block have different motion characteristics. Within a macro-block coded using the SPLITMV mode, each sub-block can have its own motion vector. Similar to the strategy of reusing without transmitting motion vectors at the macro-block level, a sub-block can also use motion vectors from neighboring sub-blocks above or left of the current block without transmitting the motion vectors. This strategy is very flexible and can encode any shape of submacro-block partitioning. Fig. 8(a) shows an example of a macro-block with l6xI6 luma pixels that are partitioned to 16 4x4 blocks: 1 1 1 1 1 2 2 1 1 2 2 1 3 3 3 1

(a) (b) figure 8: Illustration of VP8 inter prediction mode SPLITMV [16]

In Fig. 8 (a), New represents a 4x4 bock coded with a new motion vector, and Left and Above represent a 4x4 block coded using the motion vector from the left and above, respectively. This example effectively partitions the 16xI6 macro-block into three different segments with three different motion vectors (represented by 1, 2and 3), as seen in Fig. 8 (b).

4.1.3 Reference Frames VP8 uses three types of reference frames for inter prediction: the "last frame", a "golden frame" and an "alternate reference frame." Depending on content, a frame from the distant past can be very beneficial in

13 | P a g e terms of inter prediction when objects re-appear after disappearing for a number of frames. Based on such observations, VP8 was designed to use one reference frame buffer to store a video frame from an arbitrary point in the past. This buffer is known as the "Golden Reference Frame." Unlike other types of reference frames used in video compression, which are always displayed to the user by the decoder, the VP8 alternate reference frame is decoded normally but may or may not be shown in the decoder. It can be used solely as a reference to improve inter prediction for other coded frames.

4.2 Adaptive Loop Filtering:

Loop filtering is a process of removing blocking artifacts introduced by quantization of the DCT coefficients from block transforms. VPS brings several loop-filtering innovations that speed up decoding by not applying any loop filter at all in some situations. VPS also supports a method of implicit segmentation where different loop filter strengths can be applied for different parts of the image, according to the prediction modes or reference frames used to encode each macro-block. For example it would be possible to apply stronger filtering to intra-coded blocks and at the same time specify that inter coded blocks that use the Golden Frame as a reference and are coded using a (0,0) motion vector should use a weaker filter. The choice of loop filter strengths in a variety of situations is fully adjustable on a frame-by-frame basis, so the encoder can adapt the filtering strategy in order to get the best possible results. In addition, similar to the region-based adaptive quantization in section 3, VPS supports the adjustment of loop filter strength for each segment. Most symbol values in VPS are binarized into a series of Boolean values using a pseudo Huffman tree scheme. In such a scheme, a binary tree is first created for a set of symbols similarly to how a Huffman coding tree is created, and any symbol in the set can be represented by a series of binary values generated by traversing the binary tree from the root node to the corresponding leaf node. Each non-leaf node in the binary tree has a probability assigned based on the likelihood of taking the left (0) branch for traversing. Through such a binarization scheme and storing data in pseudo Huffman tree structures, the encoding/decoding style in VP8 is very consistent for all the values in the bitstream, such as macro-block coding modes, reference frame types, motion vectors, quantized coefficients, and so on. Such a scheme improves module reusability in both hardware and software implementations of VPS entropy encoder or decoder.

14 | P a g e 4.3 Entropy Coding and Data Partitioning: Except for very few header bits that are coded directly as raw values, the majority of compressed VPS data values are coded using a boolean arithmetic coder. The boolean arithmetic coder encodes one boolean value (0/1) at a time. It is used to losslessly compress a sequence of bools for which the probability of their being 0 or 1 can be well-estimated.

5. Performance comparison metrics MSE and PSNR for an NxM pixel image are defined in equations 1 and 2 where O is the original image and R is the reconstructed image. M and N are the width and height of an image and ‘L’ is the maximum pixel value in the NxM pixel image.

Bjøntegaard-Delta Bit-Rate Measurements As rate-distortion (R-D) performance assessment [14], Bjøntegaard-Delta bit-rate (BD-BR) measurement method is used for calculating average bit-rate differences between R-D graphs for the same objective quality (e.g., for the same PSNRYUV values), where negative BD-BR values indicate actual bit-rate savings. As part of this project BD-BR performance metric is used to determine bit-rate savings.

15 | P a g e 6. Implementation For comparison purpose, open-source implementations of the reviewed codecs will be used. HEVC compression efficiency will be measured with the HM Test Model [12]. WebP is downloaded from [19].The rate distortion is compared in HEVC and WebP for MSP is done by plotting graphs for PSNR and BD rate. The implementation complexity will be evaluated based on the encoding time.

7. Results: Reference picture: barbara.jpg (512x512) HEVC-Main Still Picture WebP Profile QP PSNR in Bit rate in Bits per Encoding Q PSNR in dB Bit rate in Bits per Encoding dB kbps Pixel time in kbps Pixel time in seconds seconds 22 42.8459 344.120 1.312 45.923 75 39.08 289.920 1.106 0.070 7 27 39.4053 211.704 0.807 42.491 50 36.84 217.986 0.831 0.061 6 32 36.1660 126.712 0.483 38.835 35 35.10 176.112 0.672 0.058 4 37 32.9291 71.1120 0.271 35.737 25 33.84 148.576 0.567 0.054 3 Table.1 figure 9. Encoding Time vs Bpp Plot for Barbara.jpg (512x512)

16 | P a g e figure 10. Encoding Time vs Quantization Parameter Plot for Barbara.jpg (512x512)

17 | P a g e Note: For WebP Q=100 is loseless and for HEVC QP=0 for loseless.

figure 11. PSNR vs Bpp plot for Barbara.jpg(512x512)

18 | P a g e Reference picture: lena.jpg (512x512) HEVC-Main Still Picture Profile WebP QP PSNR in Bit rate in Bits per Encoding Q PSNR in dB Bit rate in Bits per Encoding dB kbps Pixel time in kbps Pixel time in seconds seconds 22 46.4342 230.176 0.878 43.767 75 39.08 289.92 1.106 0.069 1 0 27 41.7790 131.606 0.502 38.886 50 36.86 217.93 0.831 0.064 0 6 32 38.1066 68.744 0.262 36.753 35 35.12 176.11 0.672 0.062 2 2 37 35.1546 36.512 0.139 32.886 25 33.86 148.57 0.567 0.058 3 6 Table.2.

figure. 12 Encoding Time vs Bpp Plot for Lena.jpg (512x512)

19 | P a g e figure.13 Encoding Time vs Quantization Parameter Plot for Lena.jpg(512x512)

figure.14 PSNR vs Bpp plot for Lena.jpg (512x512)

21 | P a g e Reference picture: bikers.png (768x512) HEVC-Main Still Picture Profile WebP QP PSNR in Bit rate in Bits Encoding Q PSNR in dB Bit rate in Bits per Encoding dB kbps per time in kbps Pixel time in Pixel seconds seconds 22 42.4694 844.776 2.148 100.537 75 38.70 673.776 1.714 0.180 27 38.2584 561.384 1.428 95.841 50 35.68 459.248 1.168 0.159 32 34.2295 345.296 0.878 88.631 35 34.32 393.024 0.999 0.150 37 30.5506 193.784 0.493 78.496 25 32.89 327.904 0.834 0.102

22 | P a g e Table.3

figure.15 Encoding Time vs Bpp Plot for Bikers.png (768x512)

figure.16 Encoding Time vs Quantization Parameter Plot for Bikers.png (768x512)

figure.17 PSNR vs Bpp plot for Bikers.png (768x512)

24 | P a g e Reference picture: HDimage.jpg(1920x1200) HEVC-Main Still Picture Profile WebP QP PSNR in Bit rate in Bits Encoding Q PSNR in dB Bit rate in Bits per Encoding dB kbps per time in kbps Pixel time in Pixel seconds seconds 22 46.5287 2869.112 1.245 394.778 75 39.86 2286.240 0.992 0.643 27 41.6819 2055.936 0.892 360.664 50 37.33 1722.416 0.748 0.628 32 37.3081 1318.456 0.572 334.069 35 35.38 1367.264 0.593 0.627 37 31.1712 698.928 0.303 306.008 25 34.04 1137.440 0.494 0.624 Table.4

figure.18 Encoding Time vs Bpp Plot for HDimage.jpg (1920x1200)

25 | P a g e figure.19 Encoding Time vs Quantization Parameter Plot for HDimage.jpg (1920x1200)

figure.20 PSNR vs Bpp plot for HDimage.jpg (1920x1200)

27 | P a g e figure.21 BD-Bit rate Reduction of HEVC with respect to WebP

8. Test Images: barbara.jpg(512x512)

28 | P a g e Lena512.jpg(512x512)

Bikers.png(768x512)

HDimage.jpg(1920x1200)

29 | P a g e 9. Test Softwares/Configurations

1) HM16.5 2) libwebp-0.4.3 3) ImageMagick-6.9.1 4) Intel Core i5 processor,1 Tb hard disk, 8GB RAM 5)Microsoft Visual Studio 2012

30 | P a g e 10. Conclusions The rate distortion plot for pictures of different resolutions (512x512,768x512,1920x1200) were evaluated. Based on the results obtained and the BD-BR plot it is concluded that HEVC has 20-30 % bit rate savings over WebP. The encoding time of HEVC is very high which implies that the implementation complexity of HEVC is high compared to WebP.

11. Appendix:

31 | P a g e figure. 22 In line command for HEVC encoder HM software: Encoder Version [16.5] (including RExt)[Windows][VS 1700][32 bit] Input File : C:\Users\deepu\Desktop\test_sequence\HM_16\barbara.yuv Bitstream File : str.bin Reconstruction File : rec.yuv Real Format : 512x512 1Hz Internal Format : 512x512 1Hz Sequence PSNR output : Linear average only Sequence MSE output : Disabled Frame MSE output : Disabled Cabac-zero-word-padding : Enabled Frame/Field : Frame based coding Frame index : 0 - 0 (1 frames) Profile : main CU size / depth / total-depth : 64 / 4 / 4 RQT trans. size (min / max) : 4 / 32 Max RQT depth inter : 3 Max RQT depth intra : 3 Min PCM size : 8 Motion search range : 64 Intra period : 1 Decoding refresh type : 0 QP : 32.00 Max dQP signaling depth : 0 Cb QP Offset : 0 Cr QP Offset : 0 QP adaptation : 0 (range=0) GOP size : 1 Input bit depth : (Y:8, C:8) MSB-extended bit depth : (Y:8, C:8) Internal bit depth : (Y:8, C:8)

32 | P a g e PCM sample bit depth : (Y:8, C:8) Intra reference smoothing : Enabled diff_cu_chroma_qp_offset_depth : -1 extended_precision_processing_flag : Disabled implicit_rdpcm_enabled_flag : Disabled explicit_rdpcm_enabled_flag : Disabled transform_skip_rotation_enabled_flag : Disabled transform_skip_context_enabled_flag : Disabled cross_component_prediction_enabled_flag: Disabled high_precision_offsets_enabled_flag : Disabled persistent_rice_adaptation_enabled_flag: Disabled cabac_bypass_alignment_enabled_flag : Disabled log2_sao_offset_scale_luma : 0 log2_sao_offset_scale_chroma : 0 Cost function: : Lossy coding (default) RateControl : 0 Max Num Merge Candidates : 5

TOOL CFG: IBD:0 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 SQP:0 ASR:0 FEN:1 ECU:0 FDM:1 CFM:0 ESD:0 RQT:1 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:2 Slice: M=0 SliceSegment: M=0 CIP:0 SAO:1 PCM:0 TransQuantBypassEnabled:0 WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 AQpS:0 SignBitHidingFlag:1 RecalQP:0

Non-environment-variable-controlled macros set as follows:

RExt__DECODER_DEBUG_BIT_STATISTICS = 0 RExt__HIGH_BIT_DEPTH_SUPPORT = 0 RExt__HIGH_PRECISION_FORWARD_TRANSFORM = 0 O0043_BEST_EFFORT_DECODING = 0

Input ChromaFormatIDC = 4:2:0 Output (internal) ChromaFormatIDC = 4:2:0

POC 0 TId: 0 ( I-SLICE, nQP 32 QP 32 ) 126712 bits [Y 34.4051 dB U 999.9900 dB V 999.9900 dB] [ET 39 ] [L0 ] [L1 ]

SUMMARY ------

33 | P a g e Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR 1 a 126.7120 34.4051 999.9900 999.9900 36.1660

I Slices------Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR 1 i 126.7120 34.4051 999.9900 999.9900 36.1660

P Slices------Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR 0 p -1.#IND -1.#IND -1.#IND -1.#IND -1.#IND

B Slices------Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR 0 b -1.#IND -1.#IND -1.#IND -1.#IND -1.#IND

RVM: 0.000 Bytes written to file: 15854 (126.832 kbps)

Total Time: 38.835 sec.

34 | P a g e figure.23 In line command for WebP encoder

12. Reference [1] Joint Collaborative Team On Video Coding Information website- http://www.itu.int/en/ITU-T/studygroups/2013-2016/16/Pages/video/jctvc.aspx [2] H.261: Video Codec for Audiovisual Services at px64 kbit/s,” http://www.itu.int/rec/T- REC-H.261-199303-I/en” [3] G. J. Sullivan, J. Ohm, T. Wiegand ,H. Woo-Jin Han, “Overview of the High Efficiency Video Coding (HEVC) Standard”, IEEE Transactions on Circuits and Systems for Video Technology, Vol. 22, No. 12, pp. 1649-1668, Dec. 2012. [4] N. Ahmed , T. Natarajan and K.R. Rao, “Discrete Cosine Transform”, IEEE Transactions on Computers, Vol. C-23, pp. 90-93, Jan. 1974. [5] P.K Ranjan, D. Pacharla, B. Ravindran and D. Mani, "Quality evaluation of HEVC Main Still Picture with limited coding tree depth and intra modes", Advances in Computing, Communications and Informatics, New Delhi. [6] S. Bultje and M. Frost, Access website http://www.webmproject.org/vp9/ PPT on “WebM and the new Open Video Codec”. [7] M. Budagavi and V. Sze, http://www.rle.mit.edu/eems/wp- content/uploads/2014/06/H.265-HEVC-Tutorial-2014-ISCAS.pdf, " Design and Implementation of Next Generation Video Coding Systems (H.265/HEVC Tutorial)". [8] http://www.uta.edu/faculty/krrao/dip/Courses/EE5359/index_tem.html, S.C Kodpadi , " Comparative study of Intra Frame Coding efficiency in HEVC and VP9" EE5359, UTA, spring 2014 [9] J. Bankoski et al, “Towards a Next Generation Open source Video Codec” SPIE, Vol. 8666, pp. 2-7, Dec. 2013. [10] D. Grois et al, “Performance Comparison of H.265/ MPEG-HEVC, VP9, and H.264/MPEGAVC Encoders”, IEEE PCS 2013, pp. 394-397, San José, CA, USA, Dec 8-11, 2013

35 | P a g e [11] M.P. Sharabayko et al, "Intra Compression Efficiency in VP9 and HEVC" Applied Mathematical Sciences, Vol. 7, no. 137, pp.6803 – 6824, Hikari Ltd, 2013 [12] HM Reference Software- https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/tags/HM-16.5/ [13]HEVC Software manual : https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk/doc/software-manual.pdf [14]G. Bjøntegaard, “Calculation of average PSNR differences between RD-curves”, ITU-T Q.6/SG16 VCEG 13th Meeting, Document VCEG-M33, Austin, USA, Apr. 2001. [15]F. Liang, X. Peng and J. Xu, "A light weight HEVC Encoder for Image Coding" MSRA-MOE joint key lab, Univ. of Sci and Technology of China, Hefei, China [16] J. Bankoski, P. Wilkins and Y. Xu, "Technical Overview of VP8, an open source video codec for the web", International conference on Multimedia and Expo, pp. 1-6, 2011 [17] T. Nguyen and D. Marpe, "Objective Performance Evaluation of the HEVC Main Still Picture Profile" IEEE Transactions on circuits and systems for video technology, pp. 1- 3,Sep2014 [18] “The WebM Project.” [Online]. Available: http://www.webmproject.org/ [19] “WebP Google Developers.” [Online]. Available: http://code.google. com/speed/webp/ [20] “Kodak Lossless True Color Image Suite.” [Online]. Available: http://r0k.us/graphics/kodak/ [21]P.K. Bansal, M.N. Shukla and A.S. Motra, "VP8 Encoder-Cost effective implementation", SoftCOM, pp.1-6, 2012 [22] Z. Xiong et.al, “A comparative study of DCT- and wavelet-based image coding,” IEEE Transactions on Circuits and Systems for Video Tech., vol.9, pp. 692-695, Aug. 1999. [23] Visual studio download for students for free- www.dreamspark.com [24] Tortoise SVN download- http://tortoisesvn.net/downloads.html [25]MPL Website-http://www.uta.edu/faculty/krrao/dip/Courses/EE5359/index_tem.html [26] K.R. Rao, D.N. Kim and J.J. Hwang, “Video Coding Standards: AVS China, H.264/MPEG-4 Part 10, HEVC, VP6, DIRAC and VC-1”, Springer, 2014. [27] http://www.imagemagick.org/script/install-source.php : software for converting to YUV format.

36 | P a g e [28] V. Sze, M. Budagavi and G. J. Sullivan (Editors), "High Efficiency Video Coding (HEVC): Algorithms and Architectures," Springer, 2014 [29] I.E Richardson/www.Vcodex.com “HEVC An Introduction to High Efficiency Video Coding” 2013 [30] I.E Richardson, “Video Codec Design: Developing Image and Video Compression Systems”, Wiley, 2002. [32] http ://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/# image_sets , Lossy compressed image formats study , Mozilla corporation July 2014 [33] M. Wien, “high efficiency video coding: coding tools and specification”, Springer, 2014. [34] G. J Sullivan, J. Ohm, J.M Boyce et al ,"Standardized Extensions of High Efficiency Video Coding ", IEEE journal of Selected Topics in Signal Processing Vol. 7, No. 6, pp. 1001-1016, Dec. 2013.

37 | P a g e