4th <Report on MPEG Standard Trends>: Discussions Regarding the Coding Technology
`of the Next Generation Video Coding “HEVC” Move Forward
`Reference Software “Updated to Version 2”
`April 12, 2011 (Tues.)
`
`MPEG (ISO/IEC: Moving Picture Experts Group) held their 95th International Meeting in Daegu
`(Daegu. Has a sister city partnership with Hiroshima, Japan), South Korea from January 24th to
`28th, 2011. In addition, the JCT-VC (Joint Collaborative Team on Video Coding, Joint
`Collaborative Team on Video Coding), which will discuss HEVC (High Efficiency Video
`Coding, High Efficiency Video Coding), met during the same period from January 20th to
`January 28th, 2011. This meeting was held in South Korea, which has been putting in a great
`deal of effort on standardization activities, and of the over 500 attendees, nearly half of them
`were from South Korea. In this article, I will provide a report on the state of the standardization
`discussions regarding HEVC, whose public test model was updated to Version 2.
`
`Komei Ishikawa, Visiting Researcher, Waseda University, University Global Information and
`Telecommunication Institute
`
`4th Report on Standard Trends, Komei Ishikawa (author)
`
`<<1>> Content of Developing Next Generation Video Coding “HEVC”
`
`[1] Creation of HM2
`HEVC (High Efficiency Video Coding, High Efficiency Video Coding) is being discussed as a
`successor format to H.264/AVC.by the JCT-VC (Joint Collaborative Team on Video Coding,
`Joint Collaborative Team on Video Coding). The JCT-VC is a task force jointly established by
`the MPEG (ISO/IEC: Moving Picture Experts Group) and the VCEG (ITU-T: Video Coding
`Experts Group).
`
`During the previous meeting (94th meeting, Guangzhou), the JCT-VC created
`
`(1) WD1 (Working Draft, Working Draft) for HEVC, and
`(2) HM1 (High Efficiency Video Coding Test Model, High Efficiency Video Coding Test
`Model).
`
`They also created reference software compatible with WD1 and HM1. The various coding tools
`used by HEVC will be determined by discussing the results of core experiments (CE: Core
`Experiments), with 13 core experiments being established at the previous 94th meeting based on
`HM1, with an eye toward the 95th meeting. The results of these core experiments, which were
`jointly verified by multiple organizations, were discussed at this last meeting.
`
`Page 1 of 30
`
`SAMSUNG EXHIBIT 1074
`Samsung Electronics Co., Ltd. v. M & K Holdings, Inc.
`IPR2018-00697
`
`

`

`In order to determine the optimal balance based on the tradeoff relationship between coding
`efficiency and computational load for technology already been using in HM1, detailed
`discussions were held.
`
`As a result, certain conclusions were reached regarding a number of coding tools, and a new HM
`that reflected these was created and updated to Version 2. In addition, 14 items were newly
`added as core experiments moving toward the next meeting (96th meeting, Geneva). Several of
`the items were carried over from the previous (94th) core experiments, but there also newly
`added items. More details will be provided later.
`
`[2] Addition of New Test Sequences
`
`At the Dresden meeting (92nd meeting), video for super hi-vision (SHV, Note 1) that will be
`provided by NHK, who decided to adopt it into test sequences (video used in common in
`experiments comparing proposed technology), was formally adopted into HEVC test sequences.
`
`(Note 1) SHV: Super Hi-Vision, has 16 times the number of pixels as HDTV (vertical 4320 x
`horizontal 7680 pixels).
`
`The HEVC test sequences were classified into five classes, from an image resolution of 416 x
`420 [pixels] (number of horizontal pixels: 416 pixels x number of vertical scanning lines: 240) to
`2560 x 1600 (pixels). Meanwhile, the images for super hi-vision had an image resolution of 8K
`to 4K (7680 x 4320 [pixels]), which exceeds the already prescribed test sequence resolution.
`Thus, an image in which a portion has been removed was added as the Class A test sequence.
`The inclusion of camera movement and the fact that this image captured a dark scene were
`significant differences compared to the image already prescribed for Class A. More details on
`the sequences are mentioned in public documents (JCTVC-D034, Specification of cropped Super
`Hi-Vision test sequences) (see the URL below).
`
`[http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=1471]
`
`[3] Addition of New Required Specifications
`
`During the meeting, screen content was incorporated as the new scope (applications assumed to
`use the standards and the application scope that would be the technological target) for the HEV
`standards. Screen content includes various types of images, such as images where the PC screen
`has been captured, images in which text scrolls on the screen, and rendered video (images in
`which information related to drawings and things provided by numerical data have been changed
`into images via computer processing).
`
`Until now, natural images (images captured through a camera) have been established as the main
`target images for MPEG standards, which means that screen content that handles unnatural
`images or processed/generated images will support images with new properties. However,
`discussions have already progressed on HEVC standards focusing on natural images; thus,
`
`Page 2 of 30
`
`

`

`agreements have been reached via discussion to the extent that there are no delays in HEVC
`standardization work or complications in the coding system.
`
`It was decided that new test sequences would be established in order to discuss the coding of
`screen content. Rather than the already established five classes, a new Class F is scheduled to be
`instituted for the test sequences. Test sequences will be collected until March 8, 2011, and then
`investigated at the next meeting (96th Meeting, Geneva). However, proposals after that will still
`be accepted.
`
`An outline for screen content test sequences that has already been proposed has been stated in
`public documents (JCTVC-D252). In addition, a draft of a request for proposals can be found in
`public documents (JCTVC-D501: Request for Video Test Material for “Screen Content” Coding
`Experiments).
`
`<<2>> Debating Coding Tools and Establishing New Core Experiments
`
`At the last (95th) meeting, the results of the core experiments created at the previous meeting
`(94th meeting, Guangzhou) were debated, and an agreement was reached regarding specifically
`installing a portion of the coding tools in HM. In addition, 14 new core experiments were
`established, including further investigating new proposals for coding tools carried over from
`previous discussions, and it was decided that these will be examined until the new meeting (96th
`meeting, Geneva). The newly established core experiments are illustrated in Table 1.
`
`Table 1 – Coding Technology to be Investigated using Core Experiments (14 items)
`
`
`
`Document No.
`Core Experiment
`Description
`
`JCTVC-
`D601
`
`Decoder-Side Motion Vector Derivation
`
`JCTVC-
`D602
`
`JCTVC-
`D603
`
`JCTVC-
`D604
`JCTVC-
`D605
`JCTVC-
`D606
`JCTVC-
`D607
`
`Flexible Motion Partitioning
`
`
`Interpolation for MC (Luma)
`
`Slice Boundary Processing and Fine
`Granularity
`Low Complexity Entropy Coding
`Improvements
`Intra Prediction Improvement
`
`Alternative Transforms
`
`Technology that derives (a
`portion) of the motion vectors
`without coding them on the
`decoder side
`Block partitioning and
`integration technology for
`effective inter prediction
`Optimal interpolation filter
`for motion compensation of
`luminance signals
`Investigates efficient slice
`settings
`Improves low load entropy
`coding
`Improves intra prediction
`performance
`Evaluates usage and
`performance of new
`transform systems
`
`Page 3 of 30
`
`

`

`JCTVC-
`D608
`
`JCTVC-
`D609
`JCTVC-
`D610
`JCTVC-
`D611
`JCTVC-
`D612
`JCTVC-
`D613
`
`JCTVC-
`D614
`
`JNon-deblocking loop filtering
`
`MV Coding and Skip/Merge operations
`
`Core Transform Design
`
`Coefficient scanning and coding
`
`Deblocking filtering
`
`Sample Adaptive Offset
`
`Intra Mode Coding
`
`Improves performance of
`filters (other than deblocking
`filters) in loops
`Improves motion vector
`coding method
`Optimizes transform
`processing
`Optimal scanning method of
`transform coefficients
`Improves deblocking filters
`
`Evaluates performance of
`dynamic interpolation system
`of sample points
`Improves efficiency of mode
`information coding of intra
`coding
`
`
`CE1 (CE: Core Experiments, Core Experiments. In Table 1, CE1 corresponds to JCTVC-D601,
`with the same correspondence being true for the core experiments mentioned below) to CE3, CE
`5 to CE7, CE9, and CE11 are technical items that are substantially the same as for the core
`experiments established at the previous meeting (94th meeting, Guangzhou), and will be carried
`over to the next (96th) meeting. In addition, for CE8 and CE12, an item related to intraloop
`filtering, which was one core experiment at the previous meeting, was divided into individual
`core experiments for deblocking filter (Note 2) and non-deblocking filter processing.
`Meanwhile, CE4, CE10, CE13, and CE14 are newly added core experiments, and were added in
`order to evaluate newly-proposed technology and improved technology.
`
`(Note 2) Deblocking Filters: Filters that decrease warping occurring at block boundaries when
`an image is coded.
`
`
`<<3>> HEVC Block Structure
`The fundamental concepts (performing generation of inter delta information, transformation to
`pixel coefficient information, etc.) to be used in coding for the HEVC currently being discussed
`are substantially the same as for H.264/AVC. However, the assumed input image resolution will
`be different from the standard that has been used until now, and will expand to 8K to 4K
`(number of horizontal pixels: approximately 8000 pixels x number of vertical scanning lines:
`approximately 4000). As a result, a system is being used in HEVC that is able to handle a blocks
`of a larger size than the macro blocks (square pixel blocks of 16 pixels by 16 lines) used in
`H.264/AVC.
`
`The information below is still being discussed in regards to standardization and has not been
`finalized, but has been mentioned in MPEG-approved documents (N11822: Description of High
`Efficiency Video Coding (HEVC)), and it is believed that there is a strong possibility that similar
`specifications will ultimately be used for HEVC.
`
`Page 4 of 30
`
`

`

`
`
` Image input
`
`
`
`
`
`To quantization treatment
`
`Macroblock
`
`16x16 pixels
`
`
`
`Prediction
`Mode Selection
`
`Transformation
`Processing
`
`16x16 pixels
`4x4 pixels
`
`
`The following three processing units are used in HEVC for coding.
`
`(1) A. CU (Coding Unit, Coding Unit)
`(2) B. PU (Prediction Unit, Prediction Unit)
`(3) C. TU (Transform Unit, Transform Unit)
`Each of these units can be matched up to processing systems in H.264/AVC, and completely new
`skimming (systems) have not been implemented in the overall flow of coding processing (see
`FIG. 1). In addition, slices in which several blocks have been lumped together (a strip of
`macroblocks that is 16 lines wide) have reached the stage where new definitions are being
`investigated in order to for the CU (coding units) to be of a variable size, and new core
`experiments have been established moving toward the next meeting. Note that, for HM2, all of
`the input images are divided into square-shaped regions of the same size (maximum of 64 x 64
`pixels) at one time. This is called TB (Treeblock, Treeblock). CU, which will be explained next,
`is processing carried out for each TB.
`
`FIG. 1 Corresponding relationship of treatment units (click to enlarge)
`
`
`
`
`H.264/AVC
`
`
`
`
`
`
`HEVC
`(Under
`Deliberation)
`
`
`Max 64x64 pixels Max 64x64 pixels Depends on CU size
`
`
`Min 8x8 pixels Min 4x4 pixels
` (4x4 to 32x32)
`
`(1) A. Coding Unit (CU)
`
`CU (Coding Unit) is a portion divided into block sizes appropriate for encoding the input image.
`If TB (Treeblock) is a portion corresponding to a macroblock, a CU can be thought of as
`corresponding to a H.264/AVC sub-block.
`
`The difference with H.264/AVC is not the 16x16 pixel macroblock unit, but that a division to a
`more detailed square region is recognized, with a 64x64 pixel square region as the maximum size
`CU. The division to a detailed square region is performed by quadtree division. This is a division
`method that ensures that all CUs are square regions, and specifically a method that divides in two
`horizontally and vertically, dividing into four square regions (See FIG. 2). Since the CU
`minimum size is 8x8 pixels, quadtree division is carried out a maximum of three times. CUs that
`
` Max 16x16 pixels
` Min 4x4 pixels
`
`
`
`
`
`
`
` Image input
`
`
`
`
`
`To quantization treatment
`
`
`
`Page 5 of 30
`
`

`

`do not have prediction processing performed are put in skip mode, and when prediction
`processing is performed, it is assigned to either screen-internal prediction or between-screen
`prediction, and advances to the next PU.
`
`FIG. 2 Coding Unit (click to enlarge)
`
`
`No division (maximum)
`
`1 division
`
`2 divisions
`
`3 divisions (minimum)
`
`When divided as such, it can be
`thought that the upper right is even
`and that somewhat lower left of the
`
`center is a complex area.
`
`
`(2) B. Prediction Unit (PU)
`
` A
`
` PU is a further divided region of a square CU. It corresponds with screen-internal and
`between-screen prediction treatment of H.264/AVC. PU divides a CU into a plurality of
`rectangular regions (See FIG. 3). Screen-internal or between-screen prediction is performed for
`each of these divided regions, and generates a prediction error signal.
`
`Note that with HM2, NxN division of PU is limited to when the CU block size is the minimum
`(for between-screen prediction). This is because, by omitting NxN division, while the encoding
`efficiency drops some, the calculation volume can be significantly reduced. A similar method is
`also being considered for screen-internal prediction, and there is the possibility that is could be
`corrected in the future. The rectangular divisions of FIG. 3 are all symmetrically divided, but
`asymmetrical divisions were also being considered. This was applied in the TMuC (Test Model
`under Consideration) that was being considered before creating HM, but it is not adopted in the
`current HM. The main reason is that the calculation load for improving encoding efficiency
`increases, but improvement suggestions are also being considered.
`
`FIG. 3 Prediction Unit (click to enlarge)
`
`
`Page 6 of 30
`
`

`

`There are also various
`kinds of PU according to
`the CU size by separating
`the CU into multiple types
`of rectangular regions and
`(3) C. Transform Unit (CU)
`prediction processing each.
`
`
`(3) C. Transform Unit (CU)
`
`
`
` A
`
` TU is a transformation treatment for expressing a prediction error signal efficiently. It applies
`to integer transformation or Hadamard transformation in H.264/AVC. The TU block size is
`selected from 4x4 [pixels] to 32x32 [pixels], but various values are conceivable in according to
`the focused CU size, and the TU block size is actually expressed by the number of quadtree
`divisions performed. For example, if a 32x32 pixel CU is divided once by quadtree division, the
`TU is a 16x16 pixel block size. The coefficient information obtained by transformation is
`quantized and is further compressed by VLC (Variable Length Coding) or arithmetic encoding.
`
`
`<<4>> Other MPEG Topics
`
`[1] HTTP Streaming
`
`The DASH [ISO/IEC 23001-6 Dynamic Adaptive Streaming over HTTP (DASH)] for which a
`CD (Committee Draft) was decided at the last assembly (94th Guangzhou Assembly) had a DIS
`(Draft International Standard) decided at this assembly (95th Assembly). Furthermore, Part7,
`which defines compatibility tests and reference software, was newly established, and WD
`creation was started.
`
`[2] MMT
`
`MMT (MPEG Media Transport) is a standard that defines media information transfer of MPEGs
`using an IP network. Since standardization of MPEG media transport by HTTP is already being
`advanced as DASH, it is being considered in MMT as a standard targeting a wider range of
`applications.
`
` A
`
` Call for Proposals [Call for Proposals on MPEG Media Transport (MMT)] on MMT was
`issued at the Geneva Assembly (93rd), and since the last assembly (94th Guangzhou Assembly)
`
`Page 7 of 30
`
`

`

`was the Call for Proposals period, the main action was the establishment of an AHG (Ad Hoc
`Group). This assembly ended the Call for Proposals, evaluated proposals from 10 organizations,
`and started of WD creation.
`
`[3] Deliberation on Royalty-Free Codec
`
`The discussion concerning RFCodec (Royal Free Codec) resulted in newly standardizing a free
`video codec intended for use on the internet. The new standard has a compressibility
`performance sufficiently higher than MPEG-2, and has a goal of achieving similar performance
`as the Baseline Profile of H.264/AVC. The draft for the CfP (Call for Proposals) will be started,
`and it is scheduled to be issued at the end of the next assembly (96th Geneva Assembly). It can be
`confirmed at the MPEG press release.
`
`“MPEG envisages royalty-free MPEG video coding standard”
`http://www.itscj.ipsj.or.jp/sc29/29w02911.pdf
`
`[4] 3DV
`
`In standardization concerning encoding of 3D video (3DV: 3Dimension Video), a Call for
`Proposals draft was created about FTV (Free-viewpoint TV). It is scheduled that a formal Call
`for Proposals will be performed at the next assembly, and that each method proposed at the 98th
`assembly on November 11th will be evaluated.
`
`[5] Visual Search (visual information search technology)
`
`Deliberation is being newly started concerning Visual Search at MPEG. Visual Search is mainly
`for applications that search visual objects in images or video. To realize this, information
`extraction and description in a common format are necessary, and the descriptor extraction
`method and format are subject to standardization.
`
`Since information extracted by a mobile device or the like transmits a descriptor when
`processing on a server, efficient expression and compression of the descriptor are necessary. At
`this assembly, it is scheduled to create and release a Call for Proposals draft and issue a formal
`CfP (Call for Proposals) at the next assembly (96th Geneva Assembly).
`
`<<5>> Future Schedule List
`
`[1] HEVC
`
`The number of entries input has increased to an enormous amount, but deliberation is being
`continued according to schedule at the present time.
`
`Table 2
`
`
`Stage of Standardization
`CD (Committee Draft)
`
`Period
`February 2012
`
`Page 8 of 30
`
`

`

`FCD (Final Committee Draft)
`FDIS (Final Draft International Standard)
`
`July 2012
`January 2013
`
`
`
`[2] DASH
`
`Dynamic Adaptive Streaming over HTTP (DASH), which will be the standard for streaming
`technology by HTTP protocol is scheduled to have an FDIS (Final Draft International Standard)
`issued at the next assembly (96th Geneva Assembly).
`
`Table 3 DASH Standardization Schedule
`
`
`Stage of Standardization
`FDIS (Final Draft International Standard)
`IS (International Standard)
`
`Period
`July 2011
`November 2011
`
`
`[3] Visual Search
`
`The aim for standardization of Visual Search is to issue a Call for Proposals at the next assembly
`(96th Geneva Assembly) and issue a standard in 2013.
`
`Table 4 Visual Search Standardization Schedule
`
`
`Stage of Standardization
`CfP (Call for Proposals)
`WD (Working Draft)
`CD (Committee Draft)
`DIS (Draft International Standard)
`Final Draft International Standard
`
`Period
`March 2011
`February 2012
`July 2012
`January 2013
`105th Assembly (2013)
`
`
`<<6>> Summary
`
`This report reported trends of HEVC standardization wherein deliberations are being steadily
`advanced. HEVC can also efficiently compress high resolution video that was not supported by
`H.264/AVC by introducing a new block structure. Along with that, operation load volume is also
`in a trend of increasing, but the trade-offs of encoding efficiency and operation load volume have
`been optimized through a plurality of core tests, and active discussions are continuing to decide
`on a new standard with a balance of the two. It is expected that a new standard that can be widely
`applied to various applications will ultimately be issued.
`
`<<Reference Site>>
`
`“JCT-VC Document Management System” (http://phenix.int-evry.fr/jct/index.php)
`
`(Each document can be accessed from [All meetings] on the side menu of the top screen. No ID
`is necessary to view documents.)
`
`Page 9 of 30
`
`

`

`
`Back Number
`
`<MPEG Standard Trend Report>
`
`First: H.264/AVC successor standard H.265/HVC toward standardization
`=MPEG Tokyo Assembly: Began deliberations aiming for July 2012 completion=
`
`Second: H.264/AVC successor standard changed to new standard name “HEVC”
`=Subjective evaluation experiment completed and toward selection stage of specific encoding
`tools=
`
`Third: Toward selection of next generation standard “HEVC” reference software
`=Full scale deliberations on HEVC begin=
`
`Fourth: Discussions progress concerning encoding technology of next generation image
`encoding “HEVC”
`=Reference software “updated to version 2”=
`
`
`Profile
`
`
`
`
`
`Mr. Takaaki Ishikawa
`
`Current position:
`Waseda University Global Information and Telecommunication Institute Visiting Researcher
`
`[Brief Biography]
`
`Graduated from Waseda University, School of Science and Engineering, Department of
`Electronics and Telecommunication in 2003. Completed Global Information and
`Telecommunication Studies Master’s program at the same University’s Graduate School 2005.
`Entered Doctoral program in the same year at the same University’s Graduate School. Assistant
`
`Page 10 of 30
`
`

`

`at Global Information and Telecommunication Institute of the same University in 2007. Global
`Information and Telecommunication Institute Visiting Researcher at the same University from
`2011 until the present.
`Mainly engaged in research concerning image encoding. Currently engaged in research on image
`encoding technology having network affinity. Member of IEEE, Information Processing Society
`of Japan, The Institute of Electronics, Information and Communication Engineers, The Institute
`of Image Electronics Engineers of Japan, and Research Institute of Signal Processing. Member
`of ISO/IEC JTC1/SC29 WD11 Video Subcommittee and WD1 Subcommittee.
`
`Contact: takaxp@ieee.org
`
`Page 11 of 30
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`インプレス ビジネスメディア
`
`企業IT Web担当者 EC担当者 ソフト開発
`
`エネルギー
`
`
`
`IoT･AI 製品導入 DCクラウド 調査研究
`
`ITカタログ イベント
`
`エネルギーとIoTの融合時代を拓く
`
`トップ
`
`カテゴリ ニュース 報告書／書籍
`定期購読のご案内
`スマートグリッド エネルギー管理 M2M／IoT 再生可能エネルギー 電気／燃料電池自動車 情報通信（ICT） コラム
`
`
`カテゴリ一覧へ
`
`スマートグリッドフォーラム > カテゴリトップ > 標準化 > 標準化動向 > ＜MPEG標準動向レポート＞第4回：次
`世...
`
`標準化
`[標準化動向]
`
`標準化カテゴリ一覧へ
`
`＜MPEG標準動向レポート＞第4回：次世代動画像符号化
`「HEVC」の符号化技術に関する議論が進む
`参照ソフトウェアを「バージョン2に更新」
`
`2011/04/12 (火)
`
`MPEG（ISO/IEC：Moving Picture Experts Group）は、第95回国際会合を2011年1月24日から28日
`まで、韓国の大邱（テグ。日本の広島市と姉妹都市提携）において開催した。また、HEVC（High
`Efficiency Video Coding、高効率動画像圧縮符号化）を審議するJCT-VC（Joint Collaborative Team
`on Video Coding、共同研究部会）は、2011年1月20日から28日までの日程で同時開催された。今回
`の会合は、標準化活動に力を入れている韓国での開催ということもあり、500名を超える参加者のう
`ち、韓国からの参加者が半数近くを占めていた。今回は、公式テストモデルのバージョンが2に更新され
`たHEVCの標準化審議状況についてレポートする。
`
`早稲田大学大学国際情報通信研究センター招聘研究員 石川 孝明
`
`≪1≫進展する次世代動画像符号化「HEVC」の内容
`
`〔1〕HM2の作成
`
`H.264/AVCの後継規格として、HEVC（High Efficiency Video Coding、高効率動画像圧縮
`符号化）が、JCT-VC（Joint Collaborative Team on Video Coding、共同研究部会）で審
`議されている。JCT-VCは、MPEG（ISO/IEC：Moving Picture Experts Group）と
`VCEG（ITU-T：Video Coding Experts Group）が共同で設立した作業部会である。
`
`JCT-VCは、前回会合（広州会合、第94回）において
`
`https://sgforum.impress.co.jp/article/1279[5/23/2018 12:18:30 PM]
`
`定期購読・Web閲覧のご案内
`
`インプレスSmartGrid
`ニューズレター
`2018年5月号
`
`申し込みページへ
`
`バックナンバー一覧
`
`メルマガ詳細はこちら
`
`お知らせ（2017.08.2）
`[障害]メールマガジンのリンクエラーについて
`
`次号予告
`
`May.5
`
`［特集：インタビュー］
`「すべての攻撃を食い止めること
`など到底できない！」
`SANSシニアインストラクター／InGuardians
`ICSセキュリティ ディレクター
`Justin Searle（ジャスティン・シール）
`氏に聞く！
`
`［特別レポート 1］
`シスコのスマートシティプロジェクト
`ー 新IoT基盤「CIsco Kineticプ
`ラットフォーム」で展開 ー
`
`［特別レポート 2］
`プロックチェーンを活用した再エネ取
`引システム
`― 上海のベンチャー企業「Energo Labs」が開発 ー
`
`※内容は変更になる場合があります
`
`ニュース一覧
`
`イギリスBP、急速充電技
`術を開発するベンチャー
`に2000万ドルを投資ー
`EVへの応用を期待
`
`太陽光の電力のみで水素
`
`Page 12 of 30
`
`Submit Query
`
`Submit Query
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`を製造、旭化成が福島県
`にあるIHIの施設で試験
`運転を開始
`
`「BMW i3」の蓄電池
`パックを利用した蓄電施
`設がウェールズで稼働開
`始、風力発電所に併設
`
`小田急電鉄、電車の回生
`ブレーキからの電力を有
`効活用する貯蔵装置を導
`
`入 中
`
`部電力、長野県の天竜
`川流域で出力5.6MWの水
`力発電所の建設工事を開
`始
`
`もっとニュースを見る
`
`雑誌の発行月から探す
`
`2018年
`
`5月号
`4月号
`3月号
`2月号
`1月号
`2017年
`
`12月号
`11月号
`10月号
`9月号
`8月号
`7月号
`6月号
`
`人気記事
`
`もっと見る
`
`イギリスBP、急速充電技術を開発す
`るベンチャーに2000万ドルを投資ー
`EVへの応用を期待 F
`
`太陽光の電力のみで水素を製造、旭化
`成が福島県にあるIHIの施設で試験運
`転を開始 F
`
`「BMW i3」の蓄電池パックを利用し
`た蓄電施設がウェールズで稼働開始、
`風力発電所に併設 F
`
`小田急電鉄、電車の回生ブレーキから
`の電力を有効活用する貯蔵装置を導入
`
`F 中
`
`部電力、長野県の天竜川流域で出力
`5.6MWの水力発電所の建設工事を開
`始 F
`
`1 2 3 4 5
`
`（1）HEVCのWD1（Working Draft、作業草案）と
`（2）HM1（High Efficiency Video Coding Test Model、高効率動画像圧縮符号化のテスト
`モデル）
`
`を作成している。また、これらに対応する参照ソフトウェアも作成している。HEVCで採用さ
`れる各符号化ツールは、コア実験（CE：Core Experiments）の結果を審議することによって
`決められるが、前回の第94回会合では、HM1に基づく13項目のコア実験を本会合に向けて設
`定した。今回の会合では、複数の団体で互いに検証を済ませたコア実験の結果について審議し
`た。
`
`すでにHM1で採用されていた技術についても、符号化効率と演算負荷のトレードオフ関係か
`ら最適なバランスを決めるため、詳細に議論された。
`
`その結果、いくつかの符号化ツールについては一定の結論が得られ、それらを反映した新たな
`HMを作成し、バージョン2として更新した。また、次会合（ジュネーブ会合、第96回）に向
`けたコア実験として、新たに14項目が設定された。いくつかの項目は、前回（第94回）のコ
`ア実験を引き継いでいるが、新たに追加された項目もある。詳細は後述する。
`
`〔2〕新しいテストシーケンスの追加
`
`ドレスデン会合（第92回）においてテストシーケンス（提案される技術を比較する実験にお
`いて共通して利用する映像）への採用が決められたNHKが提供するスーパーハイビジョン
`（SHV、注1）向けの映像が、正式にHEVCのテストシーケンスに組み込まれた。
`
`（注1）SHV：Super Hi-Vision、HDTVの16倍の画素数「縦4320×横7680画素」。
`
`HEVCのテストシーケンスは、映像の解像度が416×240［画素］（水平画素数:416画素×垂
`直走査線数:240本）から2560×1600［画素］に至る5つのクラスに分類されている。一方で
`スーパーハイビジョン用の映像は、解像度が8K×4K（7680×4320［画素］）であり、すで
`に規定されたテストシーケンスの解像度を上回っている。そのため、一部を切り出した映像が
`NHKのテストシーケンスとしてクラスAに追加された。すでにクラスAに規定された映像と比
`較して、カメラの動きを含むことや暗いシーンを撮影した映像であることが大きな違いであ
`る。シーケンスの詳細は、公開文書（JCTVC-D034、Specification of cropped Super Hi-
`Vision test sequences）に記述されている（下記URL参照）。
`
`〔http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=1471〕
`
`〔3〕新たな要求仕様の追加
`
`本会合では、HEVC標準の新たなスコープ（標準の利用が想定されるアプリケーションや技術
`的にターゲットとする適用範囲）として、スクリーンコンテントが盛り込まれた。スクリーン
`コンテントは、PC画面をキャプチャした映像や、テキストが画面上でスクロールしている映
`像、レンダリングされたビデオ（数値データで与えられた物や図に関する情報を計算処理に
`よって画像化した映像）といった種類の映像である。
`
`これまでのMPEG標準は、主なターゲット映像を自然画像（カメラを通して撮影された映像）
`に定めているため、非自然画像もしくは加工／生成された映像を扱うスクリーンコンテント
`は、新たな特性の映像をサポートすることを意味している。ただし、すでにHEVC標準は自然
`画像を対象として審議が進められているため、HEVC標準化作業の遅れや符号化方式の複雑化
`が生じない範囲で議論することで合意されている。
`
`スクリーンコンテントの符号化を議論するために、新たなテストシーケンスを規定することに
`
`https://sgforum.impress.co.jp/article/1279[5/23/2018 12:18:30 PM]
`
`Page 13 of 30
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`なった。テストシーケンスは、すでに規定されている5つのクラスではなく、新たにクラスF
`を設ける予定である。テストシーケンスの募集は、2011年3月8日までに行われ、次会合
`（ジュネーブ会合、第96回）で検証される。ただし、それ以降の提案も認められている。
`
`特集から探す
`
`公開文書（JCTVC-D252）には、すでに提案されているスクリーンコンテントのテストシー
`ケンスの概要が記述されている。また、提案募集の草案は、公開文書（JCTVC-D501:
`Request for Video Test Material for "Screen Content" Coding Experiments）で確認でき
`る。
`
`≪2≫符号化ツールの審議と新しいコア実験の設定
`
`本会合（第95回）では、前回会合（広州会合、第94回）で作成したコア実験の結果を審議
`し、一部の符号化ツールを具体的にHMに実装することで合意している。また、継続審議と
`なった符号化ツールについては新規提案の更なる検証も含め、新たに14項目のコア実験を設
`定し、次会合（ジュネーブ会合、第96回）までに調査することになった。新たに設定された
`コア実験の項目を、表1に示す。
`
`イベント
`
`表1 コア実験で検証される符号化技術（14項目）
`
`文書番
`号
`JCTVC-
`D601
`JCTVC-
`D602
`JCTVC-
`D603
`JCTVC-
`D604
`JCTVC-
`D605
`JCTVC-
`D606
`JCTVC-
`D607
`JCTVC-
`D608
`JCTVC-
`D609
`JCTVC-
`D610
`JCTVC-
`D611
`
`コア実験
`
`説明
`
`Decoder-Side Motion
`Vector Derivation
`Flexible Motion
`Partitioning
`Interpolation for MC
`(Luma)
`Slice Boundary Processing
`and Fine Granularity
`Low Complexity Entropy
`Coding Improvements
`Intra Prediction
`Improvement
`
`(一部の)動きベクトルを符号化せず
`に復号器側で導出する技術
`効果的な画面間予測のためのブロッ
`ク分割統合技術
`輝度信号の動き補償に最適な補間
`フィルタ
`
`効率的なスライス設定の調査
`
`低負荷なエントロピー符号化の改良
`
`画面内予測の性能改善
`
`Alternative Transforms
`
`新しい変換方式の利用と性能評価
`
`Non-deblocking loop
`filtering
`MV Coding and
`Skip/Merge operations
`
`（デブロッキングフィルタ以外の）
`ループ内フィルタの性能改善
`
`動きベクトル符号化手法の改善
`
`Core Transform Design
`
`変換処理の最適化
`
`Coefficient scanning and
`coding
`
`変換係数の最適なスキャン手法
`
`https://sgforum.impress.co.jp/article/1279[5/23/2018 12:18:30 PM]
`
`次世代ビジネスのパラダ
`イムを変える脱炭素化へ
`の新しい動き
`
`エネルギーIoTで変革を
`めざすNTTスマイルエナ
`ジーの再エネアグリゲー
`タとしての挑戦
`
`【創刊5周年記念】特別
`座談会 IoT時代のサイ
`バーセキュリティにどう
`対処すべきか ≪後編≫
`
`もっと特集を見る
`
`CPS/IoT時代を拓く次世
`代テクノロジーが勢ぞろ
`いした‘CEATEC JAPAN
`2016’
`
`インテルが目指すIoTに
`よる電力・エネルギー戦
`
`略 米
`
`国最大級の電力業界関
`連イベント
`「DistribuTECH 2016」
`特別レポート
`
`もっとイベントを見る
`
`新刊情報
`
`IoT、AIを活用した‘超スマート社会’実現へ
`の道［世界各国の政策と社会基盤技術の最
`新動向］
`
`詳細はこちら
`
`IoT時代の次世代無線通信規格LPWAの全貌
`［NB-IoT/Cat-M1から
`LoRaWAN/SIGFOX/IEEE 802.11ahまで］
`
`詳細はこちら
`
`Page 14 of 30
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`JCTVC-
`D612
`JCTVC-
`D613
`JCTVC-
`D614
`
`Deblocking filtering
`
`デブロッキングフィルタの改良
`
`Sample Adaptive Offset
`
`Intra Mode Coding
`
`サンプル点の動的補正方式の性能評
`価
`画面内符号化のモード情報符号化の
`効率改善
`
`表1中のCE1（CE：Core Experiments、コア実験。表1では、JCTVC-D601に対応、以下同
`じ）からCE3、CE5からCE7、CE9、CE11は、前回会合（広州会合、第94回）で設けられた
`コア実験とほぼ同じ技術項目で、次会合（第96回）についても継続審議される。また、CE8
`とCE12は、前回会合では一つのコア実験であったループ内フィルタ関連の項目を、デブロッ
`キングフィルタ（注2）とそれ以外のフィルタ処理で個別のコア実験に分けた形になってい
`る。一方、新たに追加されたコア実験としては、CE4、CE10、CE13、CE14があり、新たに
`提案された技術や改良技術の評価のために追加されている。
`
`（注2）デブロッキングフィルタ：画像の符号化時に、ブロック境界に発生する歪みを減少さ
`せるフィルタ。
`
`米国のスマートグリッド新標準：
`EnergyIoT/OpenFMB報告書［米国の最新
`動向とDistribuTECH 2016に見る新しい展
`開］
`
`詳細はこちら
`
`ログイン
`
`記事（2014年11月号以降）をお読みになる
`には、購読の申し込みが必要です。
`ログイン
`
`≪3≫HEVCのブロック構造
`
`現在審議中のHEVCは、符号化に使われる基本的な概念（画面間の差分情報の生成や画素の係
`数情報への変換などを行う点）がH.264/AVCとほぼ同じである。ただし、想定する入力映像
`の解像度がこれまでの標準とは異なり、8K×4K（水平画素数:約8000画素×垂直走査線数:約
`4000本）に拡張されている。そのためHEVCでは、H.264/AVCで利用しているマクロブロッ
`ク（16画素×16ラインの正方形の画素ブロック）よりも大きなブロックサイズに対応可能な
`方式を採用している。
`
`以下の情報は、標準化審議中であり決定事項ではないが、MPEGで承認された文書
`（N11822: Description of High Efficiency Video Coding (HEVC)）においても言及されて
`おり、最終的に同様の仕組みがHEVCで利用される可能性が高いと考えられる。
`
`HEVCには、符号化のために新たに次の3つの処理単位が用いられる。
`
`（1）A. CU（Coding Unit、符号化単位）
`（2）B. PU（Prediction Unit、予測単位）
`（3）C. TU（Transform Unit、変換単位）
`
`それぞれは、H.264/AVCでの処理系と対応付けることが可能であり、符号化処理の全体の流
`れに対してまったく新しいスキーム（方式）が導入されたわけではない（図1参照）。また、
`いくつかのマクロブロックをまとめたスライス（16ライン幅のマクロブロックの帯）につい
`ては、CU（符号化単位）が可変サイズであるために、新しい定義を検討している段階であ
`り、次会合に向けてコア実験を設定している。なお、HM2では、入力画像を一度すべてが同
`じサイズ（最大64×64画素）の正方形領域に分けるとしている。これは、TB（Treeblock、
`木構造分割）と呼ばれている。次に説明するCUは、各TBについて実行される処理である。
`
`図1 処理単位の対応関係（クリックで拡大）
`
`https://sgforum.impress.co.jp/article/1279[5/23/2018 12:18:30 PM]
`
`Page 15 of 30
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`（1）A. Coding Unit（CU、符号化単位）
`
`CU（Coding Unit、符号化単位）は、入力画像を符号化に適切したブロックサイズに分割す
`る部分である。TB（Treeblock、木構造分割）をマクロブロックに相当する部分とすれ
`ば、CUは、H.264/AVCのサブマクロブロックに相当すると考えられる。
`
`H.264/AVCとの違いは、16×16画素のマクロブロック単位ではなく、64×64画素の正方形領
`域を最大サイズのCUとして、さらに細かい正方形領域への区分を認めている点である。細か
`い正方形領域への区分は、四分木分割で行われる。これは、すべてのCUが正方形領域である
`ことを保つ分割方法であり、具体的には水平および垂直に2分割し、4つの正方形領域に分割
`する方式である（図2参照）。CUの最小サイズは8×8画素であるため、四分木分割を最大で3
`回実行できる。予測処理を行わないCUはスキップモードとなり、予測処理を行う場合は画面
`内予測か画面間予測のモードに割り振られ、次のPUに進む。
`
`図2 Coding Unit（クリックで拡大）
`
`（2）B. Prediction Unit（PU、予測単位）
`
`PUは、正方形のCUをさらに分割した領域である。H.264/AVCの画面内および画面間の予測
`処理に対応している。PUは、CUを複数の矩形領域に分割する（図3参照）。これらの分割さ
`れた領域ごとに画面内予測もしくは画面間予測を行い、予測誤差信号を生成する。
`
`https://sgforum.impress.co.jp/article/1279[5/23/2018 12:18:30 PM]
`
`Page 16 of 30
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`なお、HM2では、PUのN×N分割はCUのブロックサイズが最小の場合に限定している（画面
`間予測について）。これは、N×N分割を省くことで、符号化効率は若干低下するものの、有
`意に演算量を削減できるためである。同様の方式が、画面内予測に対しても検討されており、
`今後修正される可能性がある。図3の矩形分割はすべてCUを対称的に区分しているが、非対称
`な分割も検討されていた。これは、HMを作成する以前に検討していたTMuC（Test Model
`under Consideration、検討中テストモデル）では利用されていたが、現在のHMでは採用さ
`れていない。符号化効率の改善に対して演算負荷が増大することが主な理由だが、改善案も検
`討されている。
`
`図3 Prediction Unit（クリックで拡大）
`
`（3）C. Transform Unit（CU、変換単位）
`
`TUは、予測誤差信号を効率的に表現するための変換処理である。H.264/AVCにおける整数変
`換やアダマール変換に該当する。TUのブロックサイズは、4×4［画素］〜32×32［画素］の
`範囲で選ばれるが、注目するCUのサイズに応じてさまざまな値が考えられ、実際には四分木
`分割の実行回数によりTUのブロックサイズは表現される。例えば、32×32画素のCUを四分
`木分割で一回分割すれば、TUは16×16画素のブロックサイズになる。変換によって得られた
`係数情報は量子化され、VLC（Variable Length Coding、可変長符号化）や算術符号化でさ
`らに圧縮される。
`
`≪4≫そのほかのMPEGの話題
`
`〔1〕HTTPストリーミング
`
`前回会合（広州会合、第94回）においてCD（Committee Draft、委員会草案）が策定された
`DASH〔ISO/IEC 23001-6 Dynamic Adaptive Streaming over HTTP（DASH）、動的適
`応型HTTPストリーミング〕は、本会合（第95回会合）でDIS（Draft International
`Standard、国際標準草案）を策定した。また、新たに適合性試験と参照ソフトウェアを規定
`するPart7（ISO/IEC 23001-7: Conformance and Reference Software for DASH、DASH
`向け適合性・参照スフトウェア）を定め、WD（Working Draft、作業草案）の作成に着手し
`た。
`
`〔2〕MMT
`
`https://sgforum.impress.co.jp/article/1279[5/23/2018 12:18:30 PM]
`
`Page 17 of 30
`
`

`

`＜MPEG標準動向レポート＞第4回：次世代動画像符号化「HEVC」の符号化技術に関する議論が進む ¦ 標準化 ¦ スマートグリッドフォーラム
`
`MMT（MPEG Media Transport、MPEGメディア転送プロトコル）は、IPネットワークを利
`用したMPEGのメディア情報転送を規定する標準である。HTTPによるMPEGメディアの転送
`は、DASHとしてすでに標準化が進められているため、MMTではより幅広いアプリケーショ
`ンを対象とした標準として審議されている。
`
`MMTは、ジュネーブ会合（第93回）において、提案募集〔Call for Proposals on MPEG
`Media Transport (MMT)〕が発行されており、前回会合（広州会合、第94回）は、提案募集
`期間であったため、主要な活動はAHG（Ad Hoc Group、特別グループ）の設立であった。本
`会合で提案募集を終え、10団体からの提案を評価し、WDの作成に着手した。
`
`〔3〕Royalty-Free Codec（特許料無料コーデック）の審議
`
`RFCodec（Royal Free Codec、ロイヤリティ・フリー・コーデック。特許料無料コーデッ
`ク）に関する議論では、インターネットでの利用を想定した無料のビデオコーデックを新たに
`標準化することになった。新標準は、MPEG-2よりも十分に圧縮性能が高く、H.264/A