维基百科

User:Terry0201/Sandbox

< User:Terry0201

[1] [2] [3] [4]

History

Standardization

歷史

In 2004, the ITU-T Video Coding Experts Group (VCEG) began significant study of technology advances that could enable creation of a new video compression standard (or substantial compression-oriented enhancements of the H.264/MPEG-4 AVC standard).[1] In October 2004, various techniques for potential enhancement of the H.264/MPEG-4 AVC standard were surveyed. In January 2005, at the next meeting of VCEG, VCEG began designating certain topics as "Key Technical Areas" (KTA) for further investigation. A software codebase called the KTA codebase was established for evaluating such proposals.[5] The KTA software was based on the Joint Model (JM) reference software that was developed by the MPEG & VCEG Joint Video Team for H.264/MPEG-4 AVC. Additional proposed technologies were integrated into the KTA software and tested in experiment evaluations over the next four years.[6]

Two approaches for standardizing enhanced compression technology were considered: either creating a new standard or creating extensions of H.264/MPEG-4 AVC.[7] The project had tentative names H.265 and H.NGVC (Next-generation Video Coding), and was a major part of the work of VCEG until its evolution into the HEVC joint project with MPEG in 2010.[7][8][9]

The preliminary requirements for NGVC was the capability to have a bit rate reduction of 50% at the same subjective image quality compared to the H.264/MPEG-4 AVC High profile and computational complexity ranging from 1/2 to 3 times that of the High profile.[9] NGVC would be able to provide 25% bit rate reduction along with 50% reduction in complexity at the same perceived video quality as the High profile, or to provide greater bit rate reduction with somewhat higher complexity.[9][10]

The ISO/IEC Moving Picture Experts Group (MPEG) started a similar project in 2007, tentatively named High-performance Video Coding.[11][12] An agreement of getting a bit rate reduction of 50% had been decided as the goal of the project by July 2007.[11] Early evaluations were performed with modifications of the KTA reference software encoder developed by VCEG.[1] By July 2009, experimental results showed average bit reduction of around 20% compared with AVC High Profile; these results prompted MPEG to initiate its standardization effort in collaboration with VCEG.[12]

A formal joint Call for Proposals (CfP) on video compression technology was issued in January 2010 by VCEG and MPEG, and proposals were evaluated at the first meeting of the MPEG & VCEG Joint Collaborative Team on Video Coding (JCT-VC), which took place in April 2010.[1][7] A total of 27 full proposals were submitted.[7][13] Evaluations showed that some proposals could reach the same visual quality as AVC at only half the bit rate in many of the test cases, at the cost of 2×-10× increase in computational complexity; and some proposals achieved good subjective quality and bit rate results with lower computational complexity than the reference AVC High profile encodings. At that meeting, the name High Efficiency Video Coding (HEVC) was adopted for the joint project.[1][7] Starting at that meeting, the JCT-VC integrated features of some of the best proposals into a single software codebase and a "Test Model under Consideration", and performed further experiments to evaluate various proposed features.[1][14] The first working draft specification of HEVC was produced at the third JCT-VC meeting in October 2010.[1] Many changes in the coding tools and configuration of HEVC were made in later JCT-VC meetings.[1]

時程

  • 2012年2月，基於第六版工作草案（working draft）完成的HEVC委員會草案（Committee Draft）被批准通過。[1][15]
  • 2012年5月25日，JCT-VC發布消息說HEVC proposals for Scalable Video Coding (SVC)的評估將會在2012年10月舉行。[16] This will eventually lead to an amendment to HEVC that will add support for SVC.[17]
  • 2012年6月26日，MPEG LA發布消息說他們將會開始進行製作joint license for HEVC專利的流程。[18][19]
  • 2012年7月，基於第八版工作草案完成的HEVC國際標準草案（Draft International Standard）被批准通過。[1][20] Per Fröjdh, Chairman of the Swedish MPEG delegation, believes that commercial products that support HEVC could be released in 2013.[20]


Versions of the HEVC/H.265 standard using the ITU-T approval dates.[2]

  • Version 1: （2013年4月13日）第一個被批准的HEVC/H.265標準版本，包含了Main、Main 10以Main Still Picture profile。[26][27][28]
  • 2013年4月13日，HEVC/H.265被批准為ITU-T標準，並且在4月18日於ITU-T的網站上預先發表。[26][27][28]
  • 2013年6月7日，HEVC/H.265標準被正式發表在ITU-T網站上，並提供免費下載。[2]
  • 2013年11月25日，HEVC標準被ISO/IEC正式發表。[4]
  • 2014年1月16日，MPEG LA發布了一個HEVC的專利組合（英语：Patent portfolio）授權，目前被25個專利擁有者所支持。MPEG LA預計以每樣HEVC產品US$0.20的價格來做授權。[29]

編碼效能

大部分視訊編碼標準被設計的主要目標，都是要達到最高的編碼效能。 The design of most video coding standards is primarily aimed at having the highest coding efficiency. 編碼效能代表用最低的位元率來編碼一段影片，在同時保留一定的影片品質。 Coding efficiency is the ability to encode video at the lowest possible bit rate while maintaining a certain level of video quality. 通常有兩個標準的方法來衡量一個視訊編碼標準編碼效能，分別為客觀數據（Objective metric）譬如PSNR，及主觀評定（Subjective assessment）。 There are two standard ways to measure the coding efficiency of a video coding standard, which are to use an objective metric, such as peak signal-to-noise ratio (PSNR), or to use subjective assessment of video quality. 由於人類是以主觀感覺來感受一個影片的品質，因此主觀評定被認為是最重要衡量一個視訊壓縮標準的方法。 Subjective assessment of video quality is considered to be the most important way to measure a video coding standard since humans perceive video quality subjectively. [30]

HEVC從編碼樹單元的大小中，得到了很大的好處。 HEVC benefits from the use of larger Coding Tree Unit (CTU) sizes. 使用HM-8.0 HEVC編碼器，在同樣PSNR下，跟使用64x64的編碼樹單元大小比較，所有測試序列（sequence）在強制使用32x32的編碼樹單元大小後增加了2.2%的位元率，強制使用16x16的編碼樹單元大小下則增加了11.0%的位元率。 This has been shown in PSNR tests with a HM-8.0 HEVC encoder where it was forced to use progressively smaller CTU sizes. For all test sequences when compared to a 64x64 CTU size it was shown that the HEVC bit rate increased by 2.2% when forced to use a 32x32 CTU size and increased by 11.0% when forced to use a 16x16 CTU size. 如果單看Class A（解析度2560x1600）的測試序列，跟使用64x64的編碼樹單元大小比較，在強制使用32x32的編碼樹單元大小後增加了5.7%的位元率，強制使用16x16的編碼樹單元大小下則增加了28.2%的位元率。 In the Class A test sequences, where the resolution of the video was 2560x1600, when compared to a 64x64 CTU size it was shown that the HEVC bit rate increased by 5.7% when forced to use a 32x32 CTU size and increased by 28.2% when forced to use a 16x16 CTU size. 並且實驗結果發現，使用較大的編碼樹單元在增加編碼效率時，同時也減少了解碼時間。 The tests showed that large CTU sizes increase coding efficiency while also reducing decoding time. [30]

HEVC Main Profile (MP)與H.264/MPEG-4 AVC High Profile (HP), MPEG-4 Advanced Simple Profile (ASP), H.263 High Latency Profile (HLP), and H.262/MPEG-2 Main Profile (MP)做了比較。 The HEVC Main Profile (MP) has been compared in coding efficiency to H.264/MPEG-4 AVC High Profile (HP), MPEG-4 Advanced Simple Profile (ASP), H.263 High Latency Profile (HLP), and H.262/MPEG-2 Main Profile (MP). 以娛樂應用為目標進行測試，測試了9個影片在12個不同位元率下，使用HM-8.0 HEVC編碼器。9個影片中5個為HD解析度而另外4個為WVGA(800x480)解析度。 The video encoding was done for entertainment applications and twelve different bitrates were made for the nine video test sequences with a HM-8.0 HEVC encoder being used. Of the nine video test sequences five were at HD resolution while four were at WVGA (800x480) resolution. 在同樣的PSNR下比較位元率節省量。 The bit rate reductions for HEVC were determined based on PSNR. [30]

比較不同視訊編碼標準在同PSNR下位元率節省量[30]
視訊編碼標準 平均位元率節省量相較於
H.264/MPEG-4 AVC HP MPEG-4 ASP H.263 HLP H.262/MPEG-2 MP
HEVC MP 35.4% 63.7% 65.1% 70.8%
H.264/MPEG-4 AVC HP – 44.5% 46.6% 55.4%
MPEG-4 ASP – – 3.9% 19.7%
H.263 HLP – – – 16.2%

HEVC MP也與H.264/MPEG-4 AVC HP做了主觀品質的比較。 HEVC MP has also been compared to H.264/MPEG-4 AVC HP for subjective video quality. 以娛樂應用為目標進行測試，測試了9個影片在4個不同位元率下，使用HM-5.0 HEVC編碼器。 The video encoding was done for entertainment applications and four different bitrates were made for nine video test sequences with a HM-5.0 HEVC encoder being used. 這個主觀評定是在較早的時候舉行的，因此使用了較早期版本的HEVC編碼器，編碼效能上稍為差了一點。 The subjective assessment was done at an earlier date than the PSNR comparison and so it used an earlier version of the HEVC encoder that had slightly lower performance. 位元率的節省量是用平均意見分數（英语：mean opinion score）來做計算 The bit rate reductions were determined based on subjective assessment using mean opinion score values. HEVC MP與H.264/MPEG-4 AVC HP相較起來，整體的主觀位元率節省量為49.3%。 The overall subjective bitrate reduction for HEVC MP compared to H.264/MPEG-4 AVC HP was 49.3%. [30]

瑞士的洛桑聯邦理工學院（EPFL）進行了一個研究，來評量HEVC在高於HDTV解析度的主觀視覺品質。 EPFL (EPFL) did a study to evaluate the subjective video quality of HEVC at resolutions higher than HDTV.[31][32][33][34] 用了三段分別為3840x1744@24fps、3840x2048@30fps以及3840x2160@30fps的影片。 The study was done with three videos with resolutions of 3840x1744 at 24 fps, 3840x2048 at 30 fps, and 3840x2160 at 30 fps.[31][32][34] ????? The five second video sequences showed people on a street, traffic, and a scene from the open source computer animated movie Sintel.[31][32][34]

The video sequences were encoded at five different bitrates using the HM-6.1.1 HEVC encoder and the JM-18.3 H.264/MPEG-4 AVC encoder.[31][32]

The subjective bit rate reductions were determined based on subjective assessment using mean opinion score values.[31][32]

The study compared HEVC MP with H.264/MPEG-4 AVC HP and showed that for HEVC MP the average bitrate reduction based on PSNR was 44.4% while the average bitrate reduction based on subjective video quality was 66.5%.[31][32]

In a HEVC performance comparison released in April 2013 the HEVC MP and Main 10 Profile (M10P) were compared to H.264/MPEG-4 AVC HP and High 10 Profile (H10P) using 3840x2160 video sequences.[35] The video sequences were encoded using the HM-10.0 HEVC encoder and the JM-18.4 H.264/MPEG-4 AVC encoder.[35] The average bit rate reduction based on PSNR was 45% for inter frame video.[35]

In a video encoder comparison released in December 2013 the HM-10.0 HEVC encoder was compared to the x264 encoder and the VP9 encoder.[36] The x264 encoder was version r2334 and the VP9 encoder was version v1.2.0-3088-ga81bd12.[36] The comparison used the Bjøntegaard-Delta bit-rate (BD-BR) measurement method in which negative values are how much lower the bit rate is reduced for the same PSNR and positive values are how much the bit rate is increased for the same PSNR.[36] In the comparison the HM-10.0 HEVC encoder had the highest coding efficiency and on average to get the same objective quality the x264 encoder needed to increase the bit rate by 66.4% while the VP9 encoder needed to increase the bit rate by 79.4%.[36]

Comparison of video encoders based on equal PSNR using the BD-BR method[36]
Video encoder How much the bit rate needed to decrease/increase for the same PSNR
HM-10.0 x264 VP9
HM-10.0 - -39.3% -43.3%
x264 66.4% - -6.2%
VP9 79.4% 8.4% -

Features

HEVC was designed to substantially improve coding efficiency compared to H.264/MPEG-4 AVC HP, i.e. to reduce bitrate requirements by half with comparable image quality, at the expense of increased computational complexity.[1] HEVC was designed with the goal of allowing video content to have a data compression ratio of up to 1000:1.[37] Depending on the application requirements HEVC encoders can trade off computational complexity, compression rate, robustness to errors, and encoding delay time.[1] Two of the key features where HEVC was improved compared to H.264/MPEG-4 AVC was support for higher resolution video and improved parallel processing methods.[1]

HEVC is targeted at next-generation HDTV displays and content capture systems which feature progressive scanned frame rates and display resolutions from QVGA (320x240) to 4320p (8192x4320), as well as improved picture quality in terms of noise level, color spaces, and dynamic range.[10][38][39][40]

Video coding layer

The HEVC video coding layer uses the same "hybrid" approach used in all modern video standards, starting from H.261, in that it uses inter-/intra-picture prediction and 2D transform coding.[1] A HEVC encoder first proceeds by splitting a picture into block shaped regions for the first picture, or the first picture of a random access point, which uses intra-picture prediction.[1] Intra-picture prediction is when the prediction of the blocks in the picture is based only on the information in that picture.[1] For all other pictures inter-picture prediction is used in which prediction information is used from other pictures.[1] After the prediction methods are finished and the picture goes through the loop filters the final picture representation is stored in the decoded picture buffer.[1] Pictures stored in the decoded picture buffer can be used for the prediction of other pictures.[1]

HEVC was designed with the idea that progressive scan video would be used and no coding tools were added specifically for interlaced video.[1] Interlace specific coding tools, such as MBAFF and PAFF, are not supported in HEVC.[41] HEVC instead sends meta-stream data that tells how the interlaced video was sent.[1] Interlaced video may be sent either by coding each field as a separate picture or by coding each frame as a separate picture.[1] This allows interlaced video to be sent with HEVC without needing special interlaced decoding processes to be added to HEVC decoders.[1]

Color spaces

The HEVC standard supports color spaces such as generic film, NTSC, PAL, Rec. 601, Rec. 709, Rec. 2020, SMPTE 170M, SMPTE 240M, sRGB, sYCC, xvYCC, XYZ, and externally specified color spaces.[2][42] HEVC supports color encoding representations such as RGB, YCbCr, and YCoCg.[2]

Coding tools

Coding tree unit

主条目：Coding tree unit

HEVC replaces macroblocks, which were used with previous standards, with Coding Tree Units (CTUs) which can use a larger block structures of up to 64x64 pixels and can better sub-partition the picture into variable sized structures.[1][43] HEVC initially divides the picture into CTUs which can be 64x64, 32x32, or 16x16 with a larger pixel block size usually increasing the coding efficiency.[1]

Parallel processing tools

  • Tiles allow for the picture to be divided up into a grid of rectangular regions that can independently be decoded/encoded and the main purpose of tiles is to allow for parallel processing.[1] Tiles can be independently decoded and can even allow for random access to specific regions of a picture in a video stream.[1]
  • Wavefront parallel processing (WPP) is when a slice is divided into rows of CTUs in which the first row is decoded normally but each additional row requires that decisions be made in the previous row.[1] WPP has the entropy encoder use information from the preceding row of CTUs and allows for a method of parallel processing that may allow for better compression than tiles.[1]
  • Tiles and WPP are allowed but are optional.[1][2] If tiles are present they must be at least 64 pixels high and 256 pixels wide with a level specific limit on the number of tiles allowed.[1][2]
  • Slices can for the most part be decoded independently from each other with the main purpose of tiles being re-synchronization in case of data loss in the video stream.[1] Slices can be defined as self-contained in that prediction is not made across slice boundaries.[1] When in-loop filtering is done on a picture though information across slice boundaries may be required.[1] Slices are CTUs decoded in the order of the raster scan and different coding types can be used for slices such as I types, P types, or B types.[1]
  • Dependent slices can allow for data related to tiles or WPP to be accessed more quickly by the system than if the entire slice had to be decoded.[1] The main purpose of dependent slices is to allow for low delay video encoding due to its lower latency.[1]

Other coding tools

Entropy coding

HEVC uses a context-adaptive binary arithmetic coding (CABAC) algorithm that is fundamentally similar to CABAC in H.264/MPEG-4 AVC.[1] CABAC is the only entropy encoder method that is allowed in HEVC while there are two entropy encoder methods allowed by H.264/MPEG-4 AVC.[1] CABAC and the entropy coding of transform coefficients in HEVC were designed for a higher throughput than H.264/MPEG-4 AVC.[44] For instance, the number of context coded bins have been reduced by 8x and the CABAC bypass-mode has been improved in terms of its design to increase throughput.[1][44] Another improvement with HEVC is that the dependencies between the coded data has been changed to further increase throughput.[1][44] Context modeling in HEVC has also been improved so that CABAC can better select a context that increases efficiency when compared to H.264/MPEG-4 AVC.[1]

Intra prediction

HEVC specifies 33 directional modes for intra prediction compared to the 8 directional modes for intra prediction specified by H.264/MPEG-4 AVC.[1] HEVC also specifies planar and DC intra prediction modes.[1] The intra prediction modes use data from neighboring prediction blocks that have been previously decoded.[1]

Motion compensation

For the interpolation of fractional luma sample positions HEVC uses separable application of one-dimensional half-sample interpolation with an 8-tap filter or quarter-sample interpolation with a 7-tap filter while, in comparison, H.264/MPEG-4 AVC uses a two-stage process that first derives values at half-sample positions using separable one-dimensional 6-tap interpolation followed by integer rounding and then applies linear interpolation between values at nearby half-sample positions to generate values at quarter-sample positions.[1] HEVC has improved precision due to the longer interpolation filter and the elimination of the intermediate rounding error.[1] For 4:2:0 video, the chroma samples are interpolated with separable one-dimensional 4-tap filtering to generate eighth-sample precision, while in comparison H.264/MPEG-4 AVC uses only a 2-tap bilinear filter (also with eighth-sample precision).[1]

As in H.264/MPEG-4 AVC, weighted prediction in HEVC can be used either with uni-prediction (in which a single prediction value is used) or bi-prediction (in which the prediction values from two prediction blocks are combined).[1]

Motion vector prediction

HEVC defines a signed 16-bit range for both horizontal and vertical motion vectors (MVs).[2][45][46][47] This was added to HEVC at the July 2012 HEVC meeting with the mvLX variables.[2][45][46][47] HEVC horizontal/vertical MVs have a range of −32768 to 32767 which given the quarter pixel precision used by HEVC allows for a MV range of −8192 to 8191.75 luma samples.[2][45][46][47] This compares to H.264/MPEG-4 AVC which allows for a horizontal MV range of −2048 to 2047.75 luma samples and a vertical MV range of −512 to 511.75 luma samples.[46]

HEVC allows for two MV modes which are Advanced Motion Vector Prediction (AMVP) and merge mode.[1] AMVP uses data from the reference picture and can also use data from adjacent prediction blocks.[1] The merge mode allows for the MVs to be inherited from neighboring prediction blocks.[1] Merge mode in HEVC is similar to "skipped" and "direct" motion inference modes in H.264/MPEG-4 AVC but with two improvements.[1] The first improvement is that HEVC uses index information to select one of several available candidates.[1] The second improvement is that HEVC uses information from the reference picture list and reference picture index.[1]

Inverse transforms

HEVC specifies four transform units (TUs) sizes of 4x4, 8x8, 16x16, and 32x32 to code the prediction residual.[1] A CTB may be recursively partitioned into 4 or more TUs.[1] TUs use integer basis functions that are similar to the discrete cosine transform (DCT).[1] In addition 4x4 luma transform blocks that belong to an intra coded region are transformed using an integer transform that is derived from discrete sine transform (DST).[1] This provides a 1% bit rate reduction but was restricted to 4x4 luma transform blocks due to marginal benefits for the other transform cases.[1] Chroma uses the same TU sizes as luma so there is no 2x2 transform for chroma.[1]

Loop filters

HEVC specifies two loop filters that are applied sequentially, with the deblocking filter (DBF) applied first and the sample adaptive offset (SAO) filter applied afterwards.[1] Both loop filters are applied in the inter-picture prediction loop, i.e. the filtered image is stored in the decoded picture buffer (DPB) as a reference for inter-picture prediction.[1]

Deblocking filter

The DBF is similar to the one used by H.264/MPEG-4 AVC but with a simpler design and better support for parallel processing.[1] In HEVC the DBF only applies to a 8x8 sample grid while with H.264/MPEG-4 AVC the DBF applies to a 4x4 sample grid.[1] DBF uses a 8x8 sample grid since it causes no noticeable degradation and significantly improves parallel processing because the DBF no longer causes cascading interactions with other operations.[1] Another change is that HEVC only allows for three DBF strengths of 0 to 2.[1] HEVC also requires that the DBF first apply horizontal filtering for vertical edges to the picture and only after that does it apply vertical filtering for horizontal edges to the picture.[1] This allows for multiple parallel threads to be used for the DBF.[1]

Sample adaptive offset

The SAO filter is applied after the DBF and is designed to allow for better reconstruction of the original signal amplitudes by applying offsets stored in a lookup table in the bitstream.[1][48] Per CTB the SAO filter can be disabled or applied in one of two modes: edge offset mode or band offset mode.[1][48] The edge offset mode operates by comparing the value of a sample to two of its eight neighbors using one of four directional gradient patterns.[1][48] Based on a comparison with these two neighbors, the sample is classified into one of five categories: minimum, maximum, an edge with the sample having the lower value, an edge with the sample having the higher value, or monotonic.[1][48] For each of the first four categories an offset is applied.[1][48] The band offset mode applies an offset based on the amplitude of a single sample.[1][48] A sample is categorized by its amplitude into one of 32 bands (histogram bins).[1][48] Offsets are specified for four consecutive of the 32 bands, because in flat areas which are prone to banding artifacts, sample amplitudes tend to be clustered in a small range.[1][48] The SAO filter was designed to increase picture quality, reduce banding artifacts, and reduce ringing artifacts.[1][48]

Range extensions

Additional coding tool options have been added in the April 2014 (non-final) draft of the range extensions amendment.[42] These include:

  • Profiles supporting bit depths beyond 10 bits per sample.[42] Profiles that support a range of bit depths can use different bit depths for luma and chroma with YUV color spaces.[2][42]
  • Profiles that support 4:0:0 (monochrome), 4:2:2 (half-horizontal chroma resolution), and 4:4:4 (full chroma resolution) chroma sampling.[42]
  • High precision weighted prediction uses an increased precision for weighted prediction that increases the coding efficiency for fading video scenes at high bit depths.[49]
  • Minimum compression ratio (MinCR) constraint is reduced to half its base value for the 4:2:2 and 4:4:4 chroma sampling profiles.[42] The base value for MinCR varies from 2 to 8 depending on the level.[2][42]
  • Cross-component prediction uses prediction between the chroma/luma components to improve coding efficiency.[42] The reduction in bit rate can be up to 7% for YCbCr 4:4:4 video and up to 26% for RGB video.[49] RGB video has a larger reduction in bit rate due to the greater correlation between the components.[42]
  • Fast rice adaptation uses a fast adaptation method for rice parameter derivation.[42]
  • Intra smoothing disabling allows the neighbor region filtering process ordinarily applied in intra prediction to be disabled.[42]
  • Residual DPCM (RPDCM) allows a vertical or horizontal spatial-predictive coding of residual data in transform skip and lossless transform bypass blocks (can be selected for use in intra blocks, inter blocks, or both).[42]
  • Transform skip support for block sizes larger than 4x4.[42] Allows for transform skip block sizes of up to 32x32.[42]
  • Transform skip rotation performs rotation of residual data for 4x4 transform skip blocks.[42]
  • Transform skip context uses a separate context for entropy coding to be used for indicating which blocks are coded using transform skipping.[42]
  • Extended precision processing uses an extended dynamic range for inter prediction interpolation and inverse transform.[42]
  • CABAC bypass alignment allows for the alignment of the data before bypass decoding (not supported in range extensions profiles).[42]
  • Intra block copy allows for intra prediction by copying a preceding block region of the picture (not supported in range extensions profiles).[42]
  • Separate color plane allows for the three color planes to be processed independently as three monochrome pictures when using 4:4:4 chroma sampling (not supported in range extensions profiles).[42]
  • The Still Picture profiles can use an unbounded level, level 8.5, for which no limit is imposed on the picture size.[42] Decoders for level 8.5 are not required to decode all level 8.5 bitstreams, since some may exceed their picture size capability.[42]

Profiles

The HEVC standard defines three profiles: Main, Main 10, and Main Still Picture.[2] The April 2014 draft of the range extensions amendment defines nineteen additional profiles: Monochrome 12, Monochrome 16, Main 12, Main 4:2:2 10, Main 4:2:2 12, Main 4:4:4, Main 4:4:4 10, Main 4:4:4 12, Monochrome 12 Intra, Monochrome 16 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 Intra, Main 4:4:4 10 Intra, Main 4:4:4 12 Intra, Main 4:4:4 16 Intra, Main 4:4:4 Still Picture, and Main 4:4:4 16 Still Picture.[42] HEVC also contains provisions for additional profiles.[2] Future extensions that are being discussed for HEVC include increased bit depth, 4:2:2/4:4:4 chroma sampling, Multiview Video Coding (MVC), and Scalable Video Coding (SVC).[1][50] The amendment to add HEVC range extensions will be released in April 2014 and the amendment to add HEVC scalable extensions will be released in July 2014.[51][52][52] In July 2014 a second version of HEVC will be released containing the new amendments.[52]

A profile is a defined set of coding tools that can be used to create a bitstream that conforms to that profile.[1] An encoder for a profile may choose which coding tools to use as long as it generates a conforming bitstream while a decoder for a profile must support all coding tools that can be used in that profile.[1]

Feature support in some of the video profiles[2][42]
Feature Version 1 Range extensions
Main Main 10 Main 12 Main 4:2:2 10 Main 4:2:2 12 Main 4:4:4 Main 4:4:4 10 Main 4:4:4 12 Main 4:4:4 16 Intra
Bit depth 8 8 to 10 8 to 12 8 to 10 8 to 12 8 8 to 10 8 to 12 8 to 16
Chroma sampling formats 4:2:0 4:2:0 4:2:0 4:2:0/4:2:2 4:2:0/4:2:2 4:2:0/4:2:2/4:4:4 4:2:0/4:2:2/4:4:4 4:2:0/4:2:2/4:4:4 4:2:0/4:2:2/4:4:4
4:0:0 (Monochrome) 否 否 是 是 是 是 是 是 是
High precision weighted prediction 否 否 是 是 是 是 是 是 是
MinCR reduced to half its base value 否 否 否 是 是 是 是 是 是
Cross-component prediction 否 否 否 否 否 是 是 是 是
Fast rice adaptation 否 否 否 否 否 是 是 是 是
Intra smoothing disabling 否 否 否 否 否 是 是 是 是
RPDCM implicit/explicit 否 否 否 否 否 是 是 是 是
Transform skip block sizes larger than 4x4 否 否 否 否 否 是 是 是 是
Transform skip context/rotation 否 否 否 否 否 是 是 是 是
Extended precision processing 否 否 否 否 否 否 否 否 是

Version 1 profiles

Main

The Main profile allows for a bit depth of 8-bits per sample with 4:2:0 chroma sampling, which is the most common type of video used with consumer devices.[1][2][51]

Main 10

The Main 10 profile allows for a bit depth of 8-bits to 10-bits per sample with 4:2:0 chroma sampling.[1][2] HEVC decoders that conform to the Main 10 profile must be capable of decoding bitstreams made with the following profiles: Main and Main 10.[2] A higher bit depth allows for a greater number of colors.[53][54] 8-bits per sample allows for 256 shades per primary color (a total of 16.78 million colors) while 10-bits per sample allows for 1024 shades per primary color (a total of 1.07 billion colors).[53][54] A higher bit depth allows for a smoother transition of color which resolves the problem known as color banding.[53][54] The Main 10 profile allows for improved video quality since it can support video with a higher bit depth than what is supported by the Main profile.[55] Additionally, in the Main 10 profile 8-bit video can be coded with a higher bit depth of 10-bits, which allows improved coding efficiency compared to the Main profile.[35][56][57][58]

Ericsson has stated that the Main 10 profile will bring the benefits of 10-bits per sample video to consumer TV.[53] They also state that for higher resolutions there is no bit rate penalty for encoding video at 10-bits per sample.[53] Imagination Technologies states that 10-bits per sample video will allow for larger color spaces and is required for the Rec. 2020 color space that will be used by UHDTV.[54][59] They also state that the Rec. 2020 color space will drive the widespread adoption of 10-bits per sample video.[54][59]

In a PSNR based performance comparison released in April 2013 the Main 10 profile was compared to the Main profile using a set of 3840x2160 10-bit video sequences.[35] The 10-bit video sequences were converted to 8-bits for the Main profile and remained at 10-bits for the Main 10 profile.[35] The reference PSNR was based on the original 10-bit video sequences.[35] In the performance comparison the Main 10 profile provided a 5% bit rate reduction for inter frame video coding compared to the Main profile.[35] The performance comparison states that for the tested video sequences the Main 10 profile outperformed the Main profile.[35]

The Main 10 profile was added at the October 2012 HEVC meeting based on proposal JCTVC-K0109 which proposed that a 10-bit profile be added to HEVC for consumer applications.[55] The proposal stated that this was to allow for improved video quality and to support the Rec. 2020 color space that will be used by UHDTV.[55] A variety of companies supported the proposal which included ATEME, BBC, BSkyB, CISCO, DirecTV, Ericsson, Motorola Mobility, NGCodec, NHK, RAI, ST, SVT, Thomson Video Networks, Technicolor, and ViXS Systems.[55]

Main Still Picture

The Main Still Picture profile allows for a single still picture to be encoded with the same constraints as the Main profile.[2] As a subset of the Main profile the Main Still Picture profile allows for a bit depth of 8-bits per sample with 4:2:0 chroma sampling.[1][2][51] An objective performance comparison was done in April 2012 in which HEVC reduced the average bit rate for images by 56% compared to JPEG.[60] A PSNR based performance comparison for still image compression was done in May 2012 using the HEVC HM 6.0 encoder and the reference software encoders for the other standards.[61] For still images HEVC reduced the average bit rate by 15.8% compared to H.264/MPEG-4 AVC, 22.6% compared to JPEG 2000, 30.0% compared to JPEG XR, 31.0% compared to WebP, and 43.0% compared to JPEG.[61]

A performance comparison for still image compression was done in January 2013 using the HEVC HM 8.0rc2 encoder, Kakadu version 6.0 for JPEG 2000, and IJG version 6b for JPEG.[62] The performance comparison used PSNR for the objective assessment and mean opinion score (MOS) values for the subjective assessment.[62] The subjective assessment used the same test methodology and images as those used by the JPEG committee when it evaluated JPEG XR.[62] For 4:2:0 chroma sampled images the average bit rate reduction for HEVC compared to JPEG 2000 was 20.26% for PSNR and 30.96% for MOS while compared to JPEG it was 61.63% for PSNR and 43.10% for MOS.[62]

Comparison of standards for still image compression based on equal PSNR and MOS[62]
Still image coding
standard (test method) 		Average bit rate reduction compared to
JPEG 2000 JPEG
HEVC (PSNR) 20.26% 61.63%
HEVC (MOS) 30.96% 43.10%

A PSNR based HEVC performance comparison for still image compression was done in April 2013 by Nokia.[63] HEVC has a larger performance improvement for higher resolution images than lower resolution images and a larger performance improvement for lower bit rates than higher bit rates.[63] For lossy compression to get the same PSNR as HEVC took on average 1.4× more bits with JPEG 2000, 1.6× more bits with JPEG-XR, and 2.3× more bits with JPEG.[63]

A compression efficiency study of HEVC, JPEG, JPEG XR, and WebP was done in October 2013 by Mozilla.[64][65] The study showed that HEVC was significantly better at compression than the other image formats that were tested.[64][65] Four different methods for comparing image quality were used in the study which were Y-SSIM, RGB-SSIM, IW-SSIM, and PSNR-HVS-M.[64][65]

Range extensions profiles

The April 2013 draft of the range extensions amendment defines nineteen additional profiles.[42] All of the inter frame range extensions profiles have an Intra profile.[42]

Monochrome 12

The Monochrome 12 profile allows for a bit depth of 8-bits to 12-bits per sample with support for 4:0:0 chroma sampling.[42]

Monochrome 16

The Monochrome 16 profile allows for a bit depth of 8-bits to 16-bits per sample with support for 4:0:0 chroma sampling.[42] HEVC decoders that conform to the Monochrome 16 profile must be capable of decoding bitstreams made with the following profiles: Monochrome 12 and Monochrome 16.[42]

Main 12

The Main 12 profile allows for a bit depth of 8-bits to 12-bits per sample with support for 4:0:0 and 4:2:0 chroma sampling.[42] HEVC decoders that conform to the Main 12 profile must be capable of decoding bitstreams made with the following profiles: Main, Main 10, Main 12, and Monochrome 12.[42]

Main 4Template:!:2Template:!:2 10

The Main 4:2:2 10 profile allows for a bit depth of 8-bits to 10-bits per sample with support for 4:0:0, 4:2:0, and 4:2:2 chroma sampling.[42] HEVC decoders that conform to the Main 4:2:2 10 profile must be capable of decoding bitstreams made with the following profiles: Main, Main 10, and Main 4:2:2 10.[42]

Main 4Template:!:2Template:!:2 12

The Main 4:2:2 12 profile allows for a bit depth of 8-bits to 12-bits per sample with support for 4:0:0, 4:2:0, and 4:2:2 chroma sampling.[42] HEVC decoders that conform to the Main 4:2:2 12 profile must be capable of decoding bitstreams made with the following profiles: Main, Main 10, Main 12, Main 4:2:2 10, Main 4:2:2 12, and Monochrome 12.[42]

Main 4Template:!:4Template:!:4

The Main 4:4:4 profile allows for a bit depth of 8-bits per sample with support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling.[42] HEVC decoders that conform to the Main 4:4:4 profile must be capable of decoding bitstreams made with the following profiles: Main, Main 4:2:2 10, and Main 4:4:4.[42]

Main 4Template:!:4Template:!:4 10

The Main 4:4:4 10 profile allows for a bit depth of 8-bits to 10-bits per sample with support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling.[42] HEVC decoders that conform to the Main 4:4:4 10 profile must be capable of decoding bitstreams made with the following profiles: Main, Main 10, Main 4:2:2 10, Main 4:4:4, and Main 4:4:4 10.[42]

Main 4Template:!:4Template:!:4 12

The Main 4:4:4 12 profile allows for a bit depth of 8-bits to 12-bits per sample with support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling.[42] HEVC decoders that conform to the Main 4:4:4 12 profile must be capable of decoding bitstreams made with the following profiles: Main, Main 10, Main 12, Main 4:2:2 10, Main 4:2:2 12, Main 4:4:4, Main 4:4:4 10, Main 4:4:4 12, and Monochrome 12.[42]

Main 4Template:!:4Template:!:4 16 Intra

The Main 4:4:4 16 Intra profile allows for a bit depth of 8-bits to 16-bits per sample with support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling.[42] HEVC decoders that conform to the Main 4:4:4 16 Intra profile must be capable of decoding bitstreams made with the following profiles: Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 Intra, Main 4:4:4 10 Intra, Main 4:4:4 12 Intra, Monochrome 12 Intra, and Monochrome 16 Intra.[42]

Main 4Template:!:4Template:!:4 Still Picture

The Main 4:4:4 Still Picture profile allows for a single still picture to be encoded with the same constraints as the Main 4:4:4 profile.[42] As a subset of the Main 4:4:4 profile the Main 4:4:4 Still Picture profile allows for a bit depth of 8-bits per sample with support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling.[42]

Main 4Template:!:4Template:!:4 16 Still Picture

The Main 4:4:4 16 Still Picture profile allows for a single still picture to be encoded with the same constraints as the Main 4:4:4 16 Intra profile.[42] As a subset of the Main 4:4:4 16 Intra profile the Main 4:4:4 16 Still Picture profile allows for a bit depth of 8-bits to 16-bits per sample with support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling.[42]

Scalable extensions profiles

The April 2013 draft of the scalable extensions amendment defines two additional profiles.[66]

Scalable Main

The Scalable Main profile allows for a base layer that conforms to the Main profile of HEVC.[66]

Scalable Main 10

The Scalable Main 10 profile allows for a base layer that conforms to the Main 10 profile of HEVC.[66]

Decoded picture buffer

Previously decoded pictures are stored in a decoded picture buffer (DPB), and are used by HEVC encoders to form predictions for subsequent pictures.[1][2] The maximum number of pictures that can be stored in the DPB, called the DPB capacity, is 6 (including the current picture) for all HEVC levels when operating at the maximum picture size supported by the level.[1][2] The DPB capacity (in units of pictures) increases from 6 to 8, 12, or 16 as the picture size decreases from the maximum picture size supported by the level.[1][2] The encoder selects which specific pictures are retained in the DPB on a picture-by-picture basis, so the encoder has the flexibility to determine for itself the best way to use the DPB capacity when encoding the video content.[1][2]

Containers

MPEG has published an amendment which added HEVC support to the MPEG transport stream used by ATSC, DVB, and Blu-ray Disc; MPEG decided not to update the MPEG program stream used by DVD-Video.[67][68] MPEG is also planning to add HEVC support to the ISO base media file format.[69][70] HEVC will also be supported by the MPEG media transport standard that is under development.[67][71] DivX has proposed a method to add HEVC support to Matroska and provides a patched release of the MKVToolNix v6.2.0 binaries on their website.[72][73] A draft document has been submitted to the Internet Engineering Task Force which describes a method to add HEVC support to the Real-time Transport Protocol.[74]

See also

References

  1. ^ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 1.24 1.25 1.26 1.27 1.28 1.29 1.30 1.31 1.32 1.33 1.34 1.35 1.36 1.37 1.38 1.39 1.40 1.41 1.42 1.43 1.44 1.45 1.46 1.47 1.48 1.49 1.50 1.51 1.52 1.53 1.54 1.55 1.56 1.57 1.58 1.59 1.60 1.61 1.62 1.63 1.64 1.65 1.66 1.67 1.68 1.69 1.70 1.71 1.72 1.73 1.74 1.75 1.76 1.77 1.78 1.79 1.80 1.81 1.82 1.83 1.84 1.85 1.86 1.87 G.J. Sullivan; J.-R. Ohm; W.-J. Han; T. Wiegand. Overview of the High Efficiency Video Coding (HEVC) Standard (PDF). IEEE Transactions on Circuits and Systems for Video Technology. 2012-05-25 [2012-09-14]. 
  2. ^ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 H.265 : High efficiency video coding. ITU. 2013-06-07 [2013-06-07]. 
  3. ^ ITU TSB. Joint Collaborative Team on Video Coding. ITU-T. 2010-05-21 [2012-08-24]. 
  4. ^ 4.0 4.1 ISO/IEC 23008-2:2013. International Organization for Standardization. 2013-11-25 [2013-11-29]. 
  5. ^ T. Wedi and T.K. Tan, AHG report – Coding Efficiency Improvements, VCEG document VCEG-AA06, 17–18 October 2005.
  6. ^ Meeting Report for 31st VCEG Meeting VCEG document VCEG-AE01r1, Marrakech, MA, 15–16 January 2007
  7. ^ 7.0 7.1 7.2 7.3 7.4 Jie Dong. The First JCT-VC Meeting, Dresden, DE. H265.net. 2010-06-19 [2012-11-25]. 
  8. ^ Jie Dong. Current Status of H.265 (as at July 2008). H265.net. 2008-07-01 [2012-11-25]. 
  9. ^ 9.0 9.1 9.2 Yu Liu. The Preliminary Requirements for NGVC. H265.net. 2009-04-15 [2012-11-25]. 
  10. ^ 10.0 10.1 Draft requirements for "EPVC" enhanced performance video coding project. ITU-T VCEG. 2009-07-10 [2012-08-24]. 
  11. ^ 11.0 11.1 An Interview With Dr. Thomas Wiegand. in-cites. 2007-07-01 [2012-08-18]. 
  12. ^ 12.0 12.1 Yu Liu. Current Status of HVC (High-Performance Video Coding) in MPEG. H265.net. 2009-07-03 [2012-11-25]. 
  13. ^ Dresden Meeting – Document Register. ITU-T. [2012-11-24]. 
  14. ^ Documents of the first meeting of the Joint Collaborative Team on Video Coding (JCT-VC) – Dresden, Germany, 15–23 April 2010. ITU-T. 2010-04-23 [2012-08-24]. 
  15. ^ High Efficiency Video Coding (HEVC) achieves first formal milestone toward completion. JCT-VC. 2012-02-10 [2012-08-06]. 
  16. ^ Joint Call for Proposals on Scalable Video Coding Extensions of High Efficiency Video Coding (HEVC). JCT-VC. [2012-11-25]. 
  17. ^ MPEG Media Transport reaches committee draft milestone. MPEG. 2012-07-20 [2012-11-25]. 
  18. ^ MPEG LA Announces Call for Patents Essential to High Efficiency Video Coding (HEVC) (PDF). MPEG LA. 2012-06-26 [2012-11-25]. 
  19. ^ MPEG LA Announces Call for Patents Essential to High Efficiency Video Coding (HEVC). Yahoo Finance. 2012-06-26 [2012-08-06]. 
  20. ^ 20.0 20.1 MPEG issues video compression draft. Ericsson. 2012-08-13 [2012-08-16]. 
  21. ^ 21.0 21.1 New video codec to ease pressure on global networks. ITU. 2013-01-25 [2013-01-25]. 
  22. ^ 22.0 22.1 Todd Spangler. ITU OKs Next-Generation Video Codec Standard. Multichannel News. 2013-01-25 [2013-01-25]. 
  23. ^ ITU-T Work Programme. ITU. [2013-01-27]. 
  24. ^ MPEG HEVC – The next major milestone in MPEG video history is achieved (DOC). MPEG. 2013-01-25 [2013-01-27]. 
  25. ^ MPEG Basics. MPEG. [2013-01-28]. 
  26. ^ 26.0 26.1 ITU-T Home : Study groups : ITU-T Recommendations : ITU-T H.265 (04/2013). ITU. 2013-04-13 [2013-04-16]. 
  27. ^ 27.0 27.1 AAP Recommendation: H.265. ITU. 2013-04-13 [2013-04-16]. 
  28. ^ 28.0 28.1 AAP Announcement No. 09. ITU. 2013-04-15 [2013-04-16]. 
  29. ^ MPEG LA Announces License Terms for High Efficiency Video Coding (HEVC/H.265). Business Wire. 2014-01-16 [2014-01-16]. 
  30. ^ 30.0 30.1 30.2 30.3 30.4 G.J. Sullivan; Heiko Schwarz; Thiow Keng Tan; Thomas Wiegand. Comparison of the Coding Efficiency of Video Coding Standards – Including High Efficiency Video Coding (HEVC) (PDF). IEEE Trans. on Circuits and Systems for Video Technology. 2012-08-22 [2012-09-22]. 
  31. ^ 31.0 31.1 31.2 31.3 31.4 31.5 Philippe Hanhart; Martin Rerabek; Francesca De Simone; Touradj Ebrahimi. Subjective quality evaluation of the upcoming HEVC video compression standard (PDF). École Polytechnique Fédérale de Lausanne (EPFL). 2012-08-13 [2012-11-08]. 
  32. ^ 32.0 32.1 32.2 32.3 32.4 32.5 Philippe Hanhart; Martin Rerabek; Francesca De Simone; Touradj Ebrahimi. Subjective quality evaluation of the upcoming HEVC video compression standard. slideshare.com. 2012-08-15 [2012-11-08]. 
  33. ^ Subjective quality evaluation of the upcoming HEVC video compression standard. École Polytechnique Fédérale de Lausanne (EPFL). [2012-11-08]. 
  34. ^ 34.0 34.1 34.2 Nic Healey. HEVC video compression could be the next step for 4K. cnet. 2012-08-29 [2012-11-08]. 
  35. ^ 35.0 35.1 35.2 35.3 35.4 35.5 35.6 35.7 35.8 Pierre Andrivon; Marco Arena; Philippe Salmon; Philippe Bordes; Paola Sunna. Comparison of Compression Performance of HEVC Draft 10 with AVC for UHD-1 material. JCT-VC. 2013-04-08 [2013-04-28]. 
  36. ^ 36.0 36.1 36.2 36.3 36.4 Dan Grois; Detlev Marpe; Amit Mulayoff; Benaya Itzhaky; Ofer Hadar. Performance Comparison of H.265/MPEG-HEVC, VP9, and H.264/MPEG-AVC Encoders (PDF). Fraunhofer Heinrich Hertz Institute. 2013-12-08 [2012-12-14]. 
  37. ^ Gary Sullivan; Jens-Rainer Ohm. Meeting report of the 13th meeting of the Joint Collaborative Team on Video Coding (JCT-VC), Incheon, KR, 18–26 Apr. 2013. JCT-VC. 2013-07-27 [2013-09-01]. 
  38. ^ Highlights of the 88th Meeting. MPEG. 2009-04-24 [2012-08-24]. 
  39. ^ Vision, Applications and Requirements for High Efficiency Video Coding (HEVC). ISO/IEC JTC1/SC29/WG11/N11872. ISO/IEC. January 2011 [2012-08-24]. 
  40. ^ Christian Timmerer. Vision and Requirements for High-Performance Video Coding (HVC). ISO/IEC JTC1/SC29/WG11/N10361. ISO/IEC. 2009-02-09 [2012-08-24]. 
  41. ^ Jérôme VIERON. HEVC: High-Efficiency Video Coding Next generation video compression (PDF). Ateme. 2012-11-27 [2013-05-21]. 
  42. ^ 42.00 42.01 42.02 42.03 42.04 42.05 42.06 42.07 42.08 42.09 42.10 42.11 42.12 42.13 42.14 42.15 42.16 42.17 42.18 42.19 42.20 42.21 42.22 42.23 42.24 42.25 42.26 42.27 42.28 42.29 42.30 42.31 42.32 42.33 42.34 42.35 42.36 42.37 42.38 42.39 42.40 42.41 42.42 42.43 42.44 42.45 42.46 David Flynn; Matteo Naccari; Chris Rosewarne; Karl Sharman; Joel Sole; Gary Sullivan; Teruhiko Suzuki. High Efficiency Video Coding (HEVC) Range Extensions text specification: Draft 7. JCT-VC. 2014-04-06 [2014-04-06]. 
  43. ^ Description of High Efficiency Video Coding (HEVC). JCT-VC. 2011-01-01 [2012-09-15]. 
  44. ^ 44.0 44.1 44.2 V. Sze; M. Budagavi. High Throughput CABAC Entropy Coding in HEVC (PDF). IEEE Transactions on Circuits and Systems for Video Technology. 2013-01-13 [2013-01-13]. 
  45. ^ 45.0 45.1 45.2 Gary Sullivan; Jens-Rainer Ohm. Meeting report of the 10th meeting of the Joint Collaborative Team on Video Coding (JCT-VC), Stockholm, SE, 11–20 July 2012. JCT-VC. 2012-10-13 [2013-04-28]. 
  46. ^ 46.0 46.1 46.2 46.3 Alistair Goudie. Restrictions to the maximum motion vector range. JCT-VC. 2012-07-02 [2012-11-26]. 
  47. ^ 47.0 47.1 47.2 Keiichi Chono; Minhua Zhou. BoG on miscellaneous limits. JCT-VC. 2012-07-19 [2012-11-26]. 
  48. ^ 48.0 48.1 48.2 48.3 48.4 48.5 48.6 48.7 48.8 Chih-Ming Fu; Elena Alshina; Alexander Alshin; Yu-Wen Huang; Ching-Yeh Chen; Chia-Yang Tsai; Chih-Wei Hsu; Shaw-Min Lei; Jeong-Hoon Park; Woo-Jin Han. Sample adaptive offset in the HEVC standard (PDF). IEEE Transactions on Circuits and Systems for Video Technology. 2012-12-25 [2013-01-24]. 
  49. ^ 49.0 49.1 Meeting report of the 15th meeting of the Joint Collaborative Team on Video Coding (JCT-VC), Geneva, CH, 23 Oct. – 1 Nov. 2013 (DOC). ITU-T. 2013-11-03 [2013-11-09]. 
  50. ^ Adrian Pennington. Ultra HD: Standards and broadcasters align. www.tvbeurope.com. 2012-08-01: 45 [2012-11-25]. 
  51. ^ 51.0 51.1 51.2 Per Fröjdh; Andrey Norkin; Rickard Sjöberg. Next generation video compression (PDF). Ericsson. 2013-04-23 [2013-04-24]. 
  52. ^ 52.0 52.1 52.2 Jens-Rainer Ohm. Recent MPEG/JCT-VC/JCT-3V Video Coding Standardization (PDF). MPEG. 2014-01-28 [2014-04-18]. 
  53. ^ 53.0 53.1 53.2 53.3 53.4 Carl Furgusson. Focus on...HEVC: The background behind the game-changing standard- Ericsson. Ericsson. 2013-06-11 [2013-06-21]. 
  54. ^ 54.0 54.1 54.2 54.3 54.4 Simon Forrest. The emergence of HEVC and 10-bit colour formats. Imagination Technologies. 2013-06-20 [2013-06-21]. 
  55. ^ 55.0 55.1 55.2 55.3 Alberto Dueñas; Adam Malamy. On a 10-bit consumer-oriented profile in High Efficiency Video Coding (HEVC). JCT-VC. 2012-10-18 [2012-11-03]. 
  56. ^ Philippe Bordes; Gordon Clare; Félix Henry; Mickaël Raulet; Jérôme Viéron. An overview of the emerging HEVC standard (PDF). Technicolor. 2012-07-20 [2012-10-05]. 
  57. ^ Rennes Research & Innovation Center: Publication. Technicolor. 2012-07-20 [2012-10-05]. 
  58. ^ Detlev Marpe; Heiko Schwarz; Sebastian Bosse; Benjamin Bross; Philipp Helle; Tobias Hinz; Heiner Kirchhoffer; Haricharan Lakshman; Tung Nguyen. Video Compression Using Nested Quadtree Structures, Leaf Merging and Improved Techniques for Motion Representation and Entropy Coding (PDF). IEEE Transactions on Circuits and Systems for Video Technology. [2012-11-08]. 
  59. ^ 59.0 59.1 Alexandru Voica. Decoding HEVC in 10-bit colours at 4K resolutions: PowerVR D5500, a Rosetta Stone for video decode. Imagination Technologies. 2013-06-20 [2013-06-21]. 
  60. ^ Jani Lainema; Kemal Ugur. On HEVC still picture coding performance. JCT-VC. 2012-04-20 [2013-01-22]. 
  61. ^ 61.0 61.1 T. Nguyen; D. Marpe. Performance Comparison of HM 6.0 with Existing Still Image Compression Schemes Using a Test Set of Popular Still Images. JCT-VC. 2012-05-03 [2012-12-31]. 
  62. ^ 62.0 62.1 62.2 62.3 62.4 Philippe Hanhart; Martin Rerabek; Pavel Korshunov; Touradj Ebrahimi. AhG4: Subjective evaluation of HEVC intra coding for still image compression. JCT-VC. 2013-01-09 [2013-01-11]. 
  63. ^ 63.0 63.1 63.2 Kemal Ugur; Jani Lainema. Updated results on HEVC still picture coding performance. JCT-VC. 2013-04-04 [2013-04-04]. 
  64. ^ 64.0 64.1 64.2 Studying Lossy Image Compression Efficiency. Mozilla. 2013-10-17 [2013-10-19]. 
  65. ^ 65.0 65.1 65.2 Lossy Compressed Image Formats Study. Mozilla. 2013-10-17 [2013-10-19]. 
  66. ^ 66.0 66.1 66.2 Jianle Chen; Jill Boyce; Yan Ye; Miska M. Hannuksela; Gary J. Sullivan; Ye-kui Wang. Preliminary version of High efficiency video coding (HEVC) scalable extension Draft 6. JCT-VC. 2014-04-15 [2014-04-18]. 
  67. ^ 67.0 67.1 Work plan and time line. MPEG. [2013-05-31]. 
  68. ^ ISO/IEC 13818-1:2013/Amd 3:2014. International Organization for Standardization. 2014-04-10 [2014-04-20]. 
  69. ^ ISO/IEC FDIS 14496-15. International Organization for Standardization. 2013-12-09 [2013-12-14]. 
  70. ^ Text of ISO/IEC 14496-15:2013/DCOR 1. MPEG. 2013-11-05 [2013-12-14]. 
  71. ^ ISO/IEC DIS 23008-1. International Organization for Standardization. 2013-05-13 [2013-06-02]. 
  72. ^ DivX HEVC Support in MKV. DivX. [2013-06-05]. 
  73. ^ Using MKVToolNix. DivX. [2013-06-05]. 
  74. ^ RTP Payload Format for High Efficiency Video Coding. Internet Engineering Task Force. 2013-09-06 [2013-12-15]. 

Official websites

Videos

Websites

检索自“https://zh.wikipedia.org/w/index.php?title=User:Terry0201/Sandbox&oldid=32677007”