INTERIM REPORT FOR MULTIMEDIA PROCESSING
PERFORMANCE COMPARISON OF HEVC MAIN STILL PICTURE
PROFILE
SPRING 2015
MULTIMEDIA PROCESSING- EE 5359
04/19/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................ ......................................14
6. Implementation.........................................................................................14
7. Results........................................................................................................15
8. Test Images................................................................................................21
9. Test Configuration...................................................................................22
10. Conclusions...............................................................................................23
11. Appendix....................................................................................................24
12. References...................................................................................................27
1
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
2
 RD: Rate Distortion
 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].
3
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]
4
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 quadtree 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 interprediction 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):
5
Figure 2. 64*64 CTBs split into CBs [3]
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.
6
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.
7
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.
8
4. Overview
of WebP:
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]
9
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 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:
10
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
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
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
11
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
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
12
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.
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.
13
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.
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.
14
7. Results:
Reference picture: barbara.jpg (512x512)
HEVC-Main Still Picture Profile
WebP
QP
PSNR in dB
Bit rate in
kbps
Bits per
Pixel
Encoding
time in
seconds
Q
PSNR in dB
Bit rate in
kbps
Bits per
Pixel
Encoding
time in
seconds
22
27
32
37
42.8459
39.4053
36.1660
32.9291
344.120
211.704
126.712
71.1120
1.3127
0.8076
0.4834
0.2713
45.923
42.491
38.835
35.737
75
50
35
25
39.08
36.84
35.10
33.84
289.920
217.986
176.112
148.576
1.106
0.831
0.672
0.567
0.070
0.061
0.058
0.054
Table.1
figure 9. Encoding Time vs Bpp Plot for Barbara.jpg (512x512)
15
figure 10. Encoding Time vs Quantization Parameter Plot for Barbara.jpg (512x512)
Note: For WebP Q=100 is loseless and for HEVC QP=0 for loseless.
16
figure 11. PSNR vs Bpp plot for Barbara.jpg(512x512)
Reference picture: lena.jpg (512x512)
HEVC-Main Still Picture Profile
WebP
QP
PSNR in dB
Bit rate in
kbps
Bits per
Pixel
Encoding
time in
seconds
Q
PSNR in dB
Bit rate in
kbps
Bits per
Pixel
Encoding
time in
seconds
22
27
32
37
46.4342
41.7790
38.1066
35.1546
230.176
131.606
68.744
36.512
0.8781
0.5020
0.2622
0.1393
43.767
38.886
36.753
32.886
75
50
35
25
39.08
36.86
35.12
33.86
289.920
217.936
176.112
148.576
1.106
0.831
0.672
0.567
0.069
0.064
0.062
0.058
Table.2.
17
figure. 12 Encoding Time vs Bpp Plot for Lena.jpg (512x512)
18
figure.13 Encoding Time vs Quantization Parameter Plot for Lena.jpg(512x512)
Note: For WebP Q=100 is loseless and for HEVC QP=0 for loseless.
19
figure.14 PSNR vs Bpp plot for Lena.jpg (512x512)
20
8. Test Images:
barbara.jpg(512x512)
Lena512.jpg(512x512)
21
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
22
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.
23
11. Appendix:
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)
24
Internal bit depth
:
PCM sample bit depth
:
Intra reference smoothing
:
diff_cu_chroma_qp_offset_depth
:
extended_precision_processing_flag
:
implicit_rdpcm_enabled_flag
:
explicit_rdpcm_enabled_flag
:
transform_skip_rotation_enabled_flag
:
transform_skip_context_enabled_flag
:
cross_component_prediction_enabled_flag:
high_precision_offsets_enabled_flag
:
persistent_rice_adaptation_enabled_flag:
cabac_bypass_alignment_enabled_flag
:
log2_sao_offset_scale_luma
:
log2_sao_offset_scale_chroma
:
Cost function:
:
RateControl
:
Max Num Merge Candidates
:
(Y:8, C:8)
(Y:8, C:8)
Enabled
-1
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
0
0
Lossy coding (default)
0
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 =
Output (internal) ChromaFormatIDC =
POC
dB
0 TId: 0 ( I-SLICE, nQP 32 QP 32 )
U 999.9900 dB
V 999.9900 dB] [ET
4:2:0
4:2:0
126712 bits [Y 34.4051
39 ] [L0 ] [L1 ]
SUMMARY -------------------------------------------------------Total Frames |
Bitrate
Y-PSNR
U-PSNR
V-PSNR
YUVPSNR
1
a
126.7120
34.4051 999.9900 999.9900
36.1660
I Slices-------------------------------------------------------25
Total Frames |
Bitrate
Y-PSNR
U-PSNR
V-PSNR
999.9900
999.9900
YUV-
PSNR
1
i
126.7120
34.4051
36.1660
P Slices-------------------------------------------------------Total Frames |
Bitrate
Y-PSNR
U-PSNR
V-PSNR
YUVPSNR
0
p
-1.#IND
-1.#IND
-1.#IND
-1.#IND
1.#IND
B Slices-------------------------------------------------------Total Frames |
Bitrate
Y-PSNR
U-PSNR
V-PSNR
YUVPSNR
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.
figure.23 In line command for WebP encoder
26
12. Reference
[1] Joint Collaborative Team On Video Coding Information website- http://www.itu.int/en/ITUT/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-RECH.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.265HEVC-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
[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/HM16.5/
27
[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.
[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.
28
[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.
29
,