JCT-VC - ITU

... reporting process for ITU-T standards, as follows, per SG 16 TD 327 (GEN/16): ...... These parameters are calculated using leaky bucket model of operation for ...

part of the document

Joint Collaborative Team on Video Coding (JCT-VC)
of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11
11th Meeting: Shanghai, CN, 1019 Oct 2012Document: JCTVC-K_Notes_d43
Title:Meeting report of the 11th meeting of the Joint Collaborative Team on Video Coding (JCT-VC), Shanghai, CN, 10-19 Oct 2012Status:Report Document from Chairs of JCT-VCPurpose:ReportAuthor(s) orContact(s):Gary SullivanMicrosoft Corp.1 Microsoft WayRedmond, WA 98052 USA
Jens-Rainer OhmInstitute of Communications EngineeringRWTH Aachen UniversityMelatener Straße 23D-52074 AachenTel:Email:
Tel:Email:+1 425 703 5308HYPERLINK "mailto:garysull@microsoft.com"garysull@microsoft.com
+49 241 80 27671HYPERLINK "mailto:ohm@ient.rwth-aachen.de"ohm@ient.rwth-aachen.deSource:Chairs_____________________________
Summary
The Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T WP3/16 and ISO/IEC JTC 1/ SC 29/ WG 11 held its eleventh meeting during 10-19 Oct 2012 at the Zhangjiang Riverfront Business Hotel, in Shanghai, CN. The JCT-VC meeting was held under the chairmanship of Dr Gary Sullivan (Microsoft/USA) and Dr Jens-Rainer Ohm (RWTH Aachen/Germany). For rapid access to particular topics in this report, a subject categorization is found (with hyperlinks) in section REF _Ref298716123 \r \h 1.14 of this document.
A meeting of AHG 9 (high level syntax) was held on Tuesday 09 Oct 2012. Discussions and recommendations of this AHG are in included in section REF _Ref329535306 \r \h 5.12, where decisions on these issues were made by the JCT plenary.
The JCT-VC meeting sessions began at approximately 900 hours on Wednesday 10 Oct 2012. Meeting sessions were held on all days (including weekend days) until the meeting was closed at approximately XXXX hours on Friday 19 Oct. Approximately XXX people attended the JCT-VC meeting, and approximately XXX input documents were discussed. The meeting took place in a co-located fashion with a meeting of ISO/IEC WG 11 one of the two parent bodies of the JCT-VC. The subject matter of the JCT-VC meeting activities consisted of work on the new next-generation video coding standardization project known as High Efficiency Video Coding (HEVC).
The primary goals of the meeting were to review the work that was performed in the interim period since the tenth JCT-VC meeting in producing the 8th HEVC Test Model (HM8) software and text and editing the 8th HEVC specification Draft (which was issued as an ISO/IEC Draft International Standard document), review the results from an interim Core Experiment (CE), review technical input documents, establish the 9th draft of the HEVC specification and the ninth version of the HEVC Test Model (HM9). An important topic of the meeting was the review of responses received upon the joint Call for Proposals on Scalable Video Coding Technology, and review of technical inputs towards the definition of HEVC extensions into higher bit-depth and non-4:2:0 color sampling. A set of Core Experiments (CEs) was planned for further investigation of proposed technology.
The JCT-VC produced XX particularly important output documents from the meeting: the HEVC Test Model 9 (HM9), the HEVC specification draft 9 a.k.a. Study of Draft International Standard (SoDIS), and a document specifying common conditions and software reference configurations for HEVC coding experiments. ... extension related docs ... Moreover, plans were established to conduct X future CEs in the interim period until the next meeting.
For the organization and planning of its future work, the JCT-VC established XX "Ad Hoc Groups" (AHGs) to progress the work on particular subject areas. The next four JCT-VC meetings are planned for 1423 January 2013 under ITU-T auspices in Geneva, CH, 17-26 April 2013 under WG 11 auspices in Incheon, KR, XX July 02 Aug 2013 under WG 11 auspices in Vienna, AT and XX-30 Oct 2013 under ITU-T auspices in Geneva, CH.
The document distribution site HYPERLINK "http://phenix.it-sudparis.eu/jct/" http://phenix.it-sudparis.eu/jct/ was used for distribution of all documents.
The reflector to be used for discussions by the JCT-VC and all of its AHGs is the JCT-VC reflector:jct-vc@lists.rwth-aachen.de. For subscription to this list, see HYPERLINK "http://mailman.rwth-aachen.de/mailman/listinfo/jct-vc" http://mailman.rwth-aachen.de/mailman/listinfo/jct-vc.
Administrative topics
Organization
The ITU-T/ISO/IEC Joint Collaborative Team on Video Coding (JCT-VC) is a group of video coding experts from the ITU-T Study Group 16 Visual Coding Experts Group (VCEG) and the ISO/IEC JTC 1/ SC 29/ WG 11 Moving Picture Experts Group (MPEG). The parent bodies of the JCT-VC are ITU-T WP3/16 and ISO/IEC JTC 1/SC 29/WG 11.
The Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T WP3/16 and ISO/IEC JTC 1/ SC 29/ WG 11 held its eleventh meeting during 10-19 Oct 2012 at the Zhangjiang Riverfront Business Hotel, in Shanghai, CN. The JCT-VC meeting was held under the chairmanship of Dr Gary Sullivan (Microsoft/USA) and Dr Jens-Rainer Ohm (RWTH Aachen/Germany).
A meeting of AHG 9 (high level syntax) was held on Tuesday 09 Oct 2012, the day before the JCT-VC meeting started, at the same meeting site.

Meeting logistics
The JCT-VC meeting sessions began at approximately 900 hours on Wednesday 10 Oct 2012. Meeting sessions were held on all days (including weekend days) until the meeting was closed at approximately XXXX hours on Friday 19 Oct. Approximately XXX people attended the JCT-VC meeting, and approximately XXX input documents were discussed. The meeting took place in a co-located fashion with a meeting of ISO/IEC WG 11 one of the two parent bodies of the JCT-VC. The subject matter of the JCT-VC meeting activities consisted of work on the new next-generation video coding standardization project known as High Efficiency Video Coding (HEVC) and its extensions.

Some statistics are provided below for historical reference purposes:
1st "A" meeting (Dresden, 2010-04): 188 people, 40 input documents
2nd "B" meeting (Geneva, 2010-07): 221 people, 120 input documents
3rd "C" meeting (Guangzhou, 2010-10): 244 people, 300 input documents
4th "D" meeting (Daegu, 2011-01): 248 people, 400 input documents
5th "E" meeting (Geneva, 2011-03): 226 people, 500 input documents
6th "F" meeting (Torino, 2011-07): 254 people, 700 input documents
7th "G" meeting (Geneva, 2011-11) 284 people, 1000 input documents
8th "H" meeting (San Jose, 2012-02) 255 people, 700 input documents
9th "I" meeting (Geneva, 2012-04/05) 241 people, 550 input documents
10th "J" meeting (Stockholm, 2012-07) 214 people, 550 input documents
11th "K" meeting (Shanghai, 2012-10) XXX people, XXX input documents

Information regarding logistics arrangements for the meeting had been provided at http://wftp3.itu.int/av-arch/ HYPERLINK "http://wftp3.itu.int/av-arch/jctvc-site/2012_10_K_Shanghai/" jctvc-site/2012_10_K_Shanghai/.

Primary goals
were to review the work that was performed in the interim period since the tenth JCT-VC meeting in producing the 8th HEVC Test Model (HM8) software and text and editing the 8th HEVC specification Draft (which was issued as an ISO/IEC Draft International Standard document), review the results from an interim Core Experiment (CE), review technical input documents, establish the 9th draft of the HEVC specification and the ninth version of the HEVC Test Model (HM9). An important topic of the meeting was the review of responses received upon the joint Call for Proposals on Scalable Video Coding Technology, and review of technical inputs towards the definition of HEVC extensions into higher bit-depth and non-4:2:0 color sampling. A set of Core Experiments (CEs) was planned for further investigation of proposed technology.
Documents and document handling considerations
General
The documents of the JCT-VC meeting are listed in Annex A of this report. The documents can be found at HYPERLINK "http://phenix.it-sudparis.eu/jct/" http://phenix.it-sudparis.eu/jct/.
Registration timestamps, initial upload timestamps, and final upload timestamps are listed in Annex A of this report.
Document registration and upload times and dates listed in Annex A and in headings for documents in this report are in Paris/Geneva time. Dates mentioned for purposes of describing events at the meeting (rather than as contribution registration and upload times) follow the local time at the meeting facility.
Highlighting of recorded decisions in this report:
Decisions made by the group that affect the normative content of the draft standard are identified in this report by prefixing the description of the decision with the string "Decision:".
Decisions that affect the reference software but have no normative effect on the text are marked by the string "Decision (SW):".
Decisions that fix a bug in the specification (an error, oversight, or messiness) are marked by the string "Decision (BF):".
Decisions regarding things that correct the text to properly reflect the design intent, add supplemental remarks to the text, or clarify the text are marked by the string "Decision (Ed.):".
Decisions regarding simplification or improvement of design consistency are marked by the string "Decision (Simp.):".
Decisions regarding complexity reduction (in terms of processing cycles, memory capacity, memory bandwidth, line buffers, number of contexts, number of context-coded bins, etc.) "Decision (Compl.):"
This meeting report is based primarily on notes taken by the chairs and projected for real-time review by the participants during the meeting discussions. The preliminary notes were also circulated publicly by ftp during the meeting on a daily basis. Considering the high workload of this meeting and the large number of contributions, it should be understood by the reader that 1) some notes may appear in abbreviated form, 2) summaries of the content of contributions are often based on abstracts provided by contributing proponents without an intent to imply endorsement of the views expressed therein, and 3) the depth of discussion of the content of the various contributions in this report is not uniform. Generally, the report is written to include as much discussion of the contributions and discussions as is feasible in the interest of aiding study, although this approach may not result in the most polished output report.
Late and incomplete document considerations
The formal deadline for registering and uploading non-administrative contributions had been announced as Monday, 1 Oct 2012.
Non-administrative documents uploaded after 2359 hours in Paris/Geneva time Tuesday 2 Oct 2012 were considered "officially late".
Responses on the CfP on scalable coding technology (documents JCTVC-K0031 through JCTVC-K0052 were considered late when description documents, bitstreams and decoder binaries would not have been uploaded by Monday 1 Oct 2012 Pacific time (Paris/Geneva + 9 hours), since the joint CfP mentioned an upload deadine of Oct 1 without mentioning a time zone.
Most documents in the late category were CE reports or cross-verification reports, which are somewhat less problematic than late proposals for new action (and especially for new normative standardization action).
At this meeting, we again had a substantial amount of late document activity, but in general the early document deadline gave us a significantly better chance for thorough study of documents that were delivered in a timely fashion. The group strived to be conservative when discussing and considering the content of late documents, although no objections were raised regarding allowing some discussion in such cases.
All contribution documents with registration numbers JCTVC-K0290 to JCTVC-K0XXX were registered after the "officially late" deadline (and therefore were also uploaded late). However, some documents in the "K0290+" range include break-out activity reports that were generated during the meeting and are therefore considered report documents rather than late contributions.
In many cases, contributions were also revised after the initial version was uploaded. The contribution document archive website retains publicly-accessible prior versions in such cases. The timing of late document availability for contributions is generally noted in the section discussing each contribution in this report.
One suggestion to assist with this issue was to require the submitters of late contributions and late revisions to describe the characteristics of the late or revised (or missing) material at the beginning of discussion of the contribution. This was agreed to be a helpful approach to be followed at the meeting.
The following other technical proposal contributions were registered on time but were uploaded late:
JCTVC-K0XXX ... (a technical proposal from XXX) [available 10-XX]
...
The following other documents not proposing normative technical content were registered in time but uploaded late:
JCTVC-K0XXX (a contribution ...)
...
The following cross-verification reports were uploaded late: JCTVC-K0XXX, ... .
The following document registrations were later cancelled or otherwise never provided or never discussed due to lack of availability or registration errors: JCTVC-K0XXX, ... .
Ad hoc group interim activity reports, CE summary results reports, break-out activity reports, and information documents containing the results of experiments requested during the meeting are not included in the above list, as these are considered administrative report documents to which the uploading deadline is not applied.
As a general policy, missing documents were not to be presented, and late documents (and substantial revisions) could only be presented when sufficient time for studying was given after the upload. Again, an exception is applied for AHG reports, CE summaries, and other such reports which can only be produced after the availability of other input documents. There were no objections raised by the group regarding presentation of late contributions, although there was some expression of annoyance and remarks on the difficulty of dealing with late contributions and late revisions.
It was remarked that documents that are substantially revised after the initial upload are also a problem, as this becomes confusing, interferes with study, and puts an extra burden on synchronization of the discussion. This is especially a problem in cases where the initial upload is clearly incomplete, and in cases where it is difficult to figure out what parts were changed in a revision. For document contributions, revision marking is very helpful to indicate what has been changed. Also, the "comments" field on the web site can be used to indicate what is different in a revision.
"Placeholder" contribution documents that were basically empty of content, with perhaps only a brief abstract and some expression of an intent to provide a more complete submission as a revision, were considered unacceptable and were rejected in the document management system, as has been agreed since the third meeting.
The initial uploads of the following contribution documents were rejected as "placeholders" without any significant content and were not corrected until after the upload deadline:
JCTVC-K0XXX (a ... document, corrected by ...)
...
A few contributions had some problems relating to IPR declarations in the initial uploaded versions (missing declarations, declarations saying they were from the wrong companies, etc.). These issues were corrected by later uploaded versions in all cases (to the extent of the awareness of the chairs).
Some other errors were noticed in other initial document uploads (wrong document numbers in headers, etc.) which were generally sorted out in a reasonably timely fashion. The document web site contains an archive of each upload.
Measures to facilitate the consideration of contributions
It was agreed that, due to the continuingly high workload for this meeting, the group would try to rely more extensively on summary CE reports. For other contributions, it was agreed that generally presentations should not exceed 5 minutes to achieve a basic understanding of a proposal with further review only if requested by the group. For cross-verification contributions, it was agreed that the group would ordinarily only review cross-checks for proposals that appear promising.
When considering cross-check contributions, it was agreed that, to the extent feasible, the following data should be collected:
Subject (including document number).
Whether common conditions were followed.
Whether the results are complete.
Whether the results match those reported by the contributor (within reasonable limits, such as minor compiler/platform differences).
Whether the contributor studied the algorithm and software closely and has demonstrated adequate knowledge of the technology.
Whether the contributor independently implemented the proposed technology feature, or at least compiled the software themselves.
Any special comments and observations made by the cross-check contributor.
Outputs of the preceding meeting
The report documents of the previous meeting, particularly the meeting report JCTVC-J1000, the HEVC Test Model (HM) JCTVC-J1002, the Draft Specification JCTVC-J1003, and the Disposition of Comments JCTVC-J1004 were approved. The HM reference software produced by the AHG on software development and HM software technical evaluation was also approved.
The group was asked to review the prior meeting report for finalization. The meeting report was later approved without modification.
All output documents of the previous meeting and the software had been made available in a reasonably timely fashion.
The chairs asked if there were any issues regarding potential mismatches between perceived technical content prior to adoption and later integration efforts. It was also asked whether there was adequate clarity of precise description of the technology in the associated proposal contributions.
It was remarked that, in regard to software development efforts for cases where "code cleanup" is a goal as well as integration of some intentional functional modification, it was emphasized that these two efforts should be conducted in separate integrations, so that it is possible to understand what is happening and to inspect the intentional functional modifications.
The need for establishing good communication with the software coordinators was also emphasized.
At previous meetings, it had been remarked that in some cases the software implementation of adopted proposals revealed that the description that had been the basis of the adoption apparently was not precise enough, so that the software unveiled details that were not known before (except possibly for CE participants who had studied the software). Also, there should be time to study combinations of different adopted tools with more detail prior to adoption.
CE descriptions need to be fully precise this is intended as a method of enabling full study and testing of a specific technology.
Greater discipline in terms of what can be established as a CE may be an approach to helping with such issues. CEs should be more focused on testing just a few specific things, and the description should precisely define what is intended to be tested (available by the end of the meeting when the CE plan is approved).
It was noted that sometimes there is a problem of needing to look up other referenced documents, sometimes through multiple levels of linked references, to understand what technology is being discussed in a contribution and that this often seems to happen with CE documents. It was emphasized that we need to have some reasonably understandable description, within a document, of what it is talking about.
Software study can be a useful and important element of adequate study; however, software availability is not a proper substitute for document clarity.
Software shared for CE purposes needs to be available with adequate time for study. Software of CEs should be available early, to enable close study by cross-checkers (not just provided shortly before the document upload deadline).
Issues of combinations between different features (e.g., different adopted features) also tend to sometimes arise in the work.
Attendance
The list of participants in the JCT-VC meeting can be found in Annex B of this report.
The meeting was open to those qualified to participate either in ITU-T WP3/16 or ISO/IEC JTC 1/ SC 29/ WG 11 (including experts who had been personally invited by the Chairs as permitted by ITU-T or ISO/IEC policies).
Participants had been reminded of the need to be properly qualified to attend. Those seeking further information regarding qualifications to attend future meetings may contact the Chairs.
Agenda
The agenda for the meeting was as follows:
IPR policy reminder and declarations
Contribution document allocation
Reports of ad hoc group activities
Reports of Core Experiment activities
Review of results of previous meeting
Consideration of contributions and communications on HEVC project guidance
Consideration of HEVC technology proposal contributions
Consideration of information contributions
Coordination activities
Future planning: Determination of next steps, discussion of working methods, communication practices, establishment of coordinated experiments, establishment of AHGs, meeting planning, refinement of expected standardization timeline, other planning issues
Other business as appropriate for consideration
IPR policy reminder
Participants were reminded of the IPR policy established by the parent organizations of the JCT-VC and were referred to the parent body websites for further information. The IPR policy was summarized for the participants.
The ITU-T/ITU-R/ISO/IEC common patent policy shall apply. Participants were particularly reminded that contributions proposing normative technical content shall contain a non-binding informal notice of whether the submitter may have patent rights that would be necessary for implementation of the resulting standard. The notice shall indicate the category of anticipated licensing terms according to the ITU-T/ITU-R/ISO/IEC patent statement and licensing declaration form.
This obligation is supplemental to, and does not replace, any existing obligations of parties to submit formal IPR declarations to ITU-T/ITU-R/ISO/IEC.
Participants were also reminded of the need to formally report patent rights to the top-level parent bodies (using the common reporting form found on the database listed below) and to make verbal and/or document IPR reports within the JCT-VC as necessary in the event that they are aware of unreported patents that are essential to implementation of a standard or of a draft standard under development.
Some relevant links for organizational and IPR policy information are provided below:
HYPERLINK "http://www.itu.int/ITU-T/ipr/index.html"http://www.itu.int/ITU-T/ipr/index.html (common patent policy for ITU-T, ITU-R, ISO, and IEC, and guidelines and forms for formal reporting to the parent bodies)
HYPERLINK "http://ftp3.itu.int/av-arch/jctvc-site"http://ftp3.itu.int/av-arch/jctvc-site (JCT-VC contribution templates)
HYPERLINK "http://www.itu.int/ITU-T/studygroups/com16/jct-vc/index.html"http://www.itu.int/ITU-T/studygroups/com16/jct-vc/index.html (JCT-VC general information and founding charter)
HYPERLINK "http://www.itu.int/ITU-T/dbase/patent/index.html"http://www.itu.int/ITU-T/dbase/patent/index.html (ITU-T IPR database)
HYPERLINK "http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm"http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm (JTC 1/ SC 29 Procedures)
It is noted that the ITU TSB director's AHG on IPR had issued a clarification of the IPR reporting process for ITU-T standards, as follows, per SG 16 TD 327 (GEN/16):
"TSB has reported to the TSB Directors IPR Ad Hoc Group that they are receiving Patent Statement and Licensing Declaration forms regarding technology submitted in Contributions that may not yet be incorporated in a draft new or revised Recommendation. The IPR Ad Hoc Group observes that, while disclosure of patent information is strongly encouraged as early as possible, the premature submission of Patent Statement and Licensing Declaration forms is not an appropriate tool for such purpose.
In cases where a contributor wishes to disclose patents related to technology in Contributions, this can be done in the Contributions themselves, or informed verbally or otherwise in written form to the technical group (e.g. a Rapporteurs group), disclosure which should then be duly noted in the meeting report for future reference and record keeping.
It should be noted that the TSB may not be able to meaningfully classify Patent Statement and Licensing Declaration forms for technology in Contributions, since sometimes there are no means to identify the exact work item to which the disclosure applies, or there is no way to ascertain whether the proposal in a Contribution would be adopted into a draft Recommendation.
Therefore, patent holders should submit the Patent Statement and Licensing Declaration form at the time the patent holder believes that the patent is essential to the implementation of a draft or approved Recommendation."
The chairs invited participants to make any necessary verbal reports of previously-unreported IPR in draft standards under preparation, and opened the floor for such reports: No such verbal reports were made.
Software copyright disclaimer header reminder
It was noted that, as had been agreed at the 5th meeting of the JCT-VC and approved by both parent bodies at their collocated meetings at that time, the HEVC reference software copyright license header language is the BSD license with preceding sentence declaring that contributor or third party rights are not granted, as recorded in N10791 of the 89th meeting of ISO/IEC JTC 1/ SC 29/ WG 11. Both ITU and ISO/IEC will be identified in the and tags in the header. This software is used in the process of designing the new HEVC standard and for evaluating proposals for technology to be included in this design. Additionally, after development of the coding technology, the software will be published by ITU-T and ISO/IEC as an example implementation of the HEVC standard and for use as the basis of products to promote adoption of the technology.
Different copyright statements shall not be committed to the committee software repository (in the absence of subsequent review and approval of any such actions). As noted previously, it must be further understood that any initially-adopted such copyright header statement language could further change in response to new information and guidance on the subject in the future.
Communication practices
The documents for the meeting can be found at HYPERLINK "http://phenix.it-sudparis.eu/jct/" http://phenix.it-sudparis.eu/jct/. For the first two JCT-VC meetings, the JCT-VC documents had been made available at HYPERLINK "http://ftp3.itu.int/av-arch/jctvc-site"http://ftp3.itu.int/av-arch/jctvc-site, and documents for the first two JCT-VC meetings remain archived there. That site was also used for distribution of the contribution document template and circulation of drafts of this meeting report.
JCT-VC email lists are managed through the site HYPERLINK "http://mailman.rwth-aachen.de/mailman/options/jct-vc"http://mailman.rwth-aachen.de/mailman/options/jct-vc, and to send email to the reflector, the email address is HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de"jct-vc@lists.rwth-aachen.de. Only members of the reflector can send email to the list. However, membership of the reflector is not limited to qualified JCT-VC participants.
It was emphasized that reflector subscriptions and email sent to the reflector must use their real names when subscribing and sending messages and must respond to inquiries regarding their type of interest in the work.
It was emphasized that usually discussions concerning CEs and AHGs should be performed using the reflector. CE internal discussions should primarily be concerned with organizational issues. Substantial technical issues that are not reflected by the original CE plan should be openly discussed on the reflector. Any new developments that are result of private communication cannot be considered to be the result of the CE.
For the case of CE documents and AHG reports, email addresses of participants and contributors may be obscured or absent (and will be on request), although these will be available (in human readable format possibly with some "obscurification") for primary CE coordinators and AHG chairs.
Terminology
Some terminology used in this report is explained below:
AHG: Ad hoc group.
AI: All-intra.
AIF: Adaptive interpolation filtering.
ALF: Adaptive loop filter.
AMP: Asymmetric motion partitioning.
AMVP: Adaptive motion vector prediction.
AMVR: Adaptive motion vector resolution.
APS: Adaptation parameter set.
ARC: Adaptive resolution coding.
AU: Access unit.
AUD: Access unit delimiter.
AVC: Advanced video coding the video coding standard formally published as ITU-T Recommendation H.264 and ISO/IEC 14496-10.
BA: Block adaptive.
BD: Bjøntegaard-delta a method for measuring percentage bit rate savings at equal PSNR or decibels of PSNR benefit at equal bit rate (e.g., as described in document VCEG-M33 of April 2001).
BoG: Break-out group.
BR: Bit rate.
CABAC: Context-adaptive binary arithmetic coding.
CBF: Coded block flag(s).
CD: Committee draft the first formal ballot stage of the approval process in ISO/IEC.
CE: Core experiment a coordinated experiment conducted after the 3rd or subsequent JCT-VC meeting and approved to be considered a CE by the group.
Consent: A step taken in ITU-T to formally consider a text as a candidate for final approval (the primary stage of the ITU-T "alternative approval process").
CTC: Common test conditions.
CVS: Coded video sequence.
DCT: Discrete cosine transform (sometimes used loosely to refer to other transforms with conceptually similar characteristics).
DCTIF: DCT-derived interpolation filter.
DIS: Draft international standard the second formal ballot stage of the approval process in ISO/IEC.
DF: Deblocking filter.
DT: Decoding time.
EPB: Emulation prevention byte (as in the emulation_prevention_byte syntax element).
ET: Encoding time.
GPB: Generalized P/B a not-particularly-well-chosen name for B pictures in which the two reference picture lists are identical.
HE: High efficiency a set of coding capabilities designed for enhanced compression performance (contrast with LC). Often loosely associated with RA.
HEVC: High Efficiency Video Coding the video coding standardization initiative under way in the JCT-VC.
HLS: High-level syntax.
HM: HEVC Test Model a video coding design containing selected coding tools that constitutes our draft standard design now also used especially in reference to the (non-normative) encoder algorithms (see WD and TM).
IBDI: Internal bit-depth increase a technique by which lower bit depth (8 bits per sample) source video is encoded using higher bit depth signal processing, ordinarily including higher bit depth reference picture storage (ordinarily 12 bits per sample).
IPCM: Intra pulse-code modulation (similar in spirit to IPCM in AVC).
JM: Joint model the primary software codebase that has been developed for the AVC standard.
JSVM: Joint scalable video model another software codebase that has been developed for the AVC standard, which includes support for scalable video coding extensions.
LB or LDB: Low-delay B the variant of the LD conditions that uses B pictures.
LC: Low complexity a set of coding capabilities designed for reduced implementation complexity (contrast with HE). Often loosely associated with LD.
LD: Low delay one of two sets of coding conditions designed to enable interactive real-time communication, with less emphasis on ease of random access (contrast with RA). Often loosely associated with LC. Typically refers to LB, although also applies to LP.
LM: Linear model.
LP or LDP: Low-delay P the variant of the LD conditions that uses P frames.
LUT: Look-up table.
MANE: Media-aware network elements.
MC: Motion compensation.
MPEG: Moving picture experts group (WG 11, the parent body working group in ISO/IEC JTC 1/ SC 29, one of the two parent bodies of the JCT-VC).
MV: Motion vector.
NAL: Network abstraction layer (as in AVC).
NB: National body (usually used in reference to NBs of the WG 11 parent body).
NSQT: Non-square quadtree.
NUH: NAL unit header.
NUT: NAL unit type (as in AVC).
OBMC: Overlapped block motion compensation.
PCP: Parallelization of context processing.
POC: Picture order count.
PPS: Picture parameter set (as in AVC).
QM: Quantization matrix (as in AVC).
QP: Quantization parameter (as in AVC, sometimes confused with quantization step size).
QT: Quadtree.
RA: Random access a set of coding conditions designed to enable relatively-frequent random access points in the coded video data, with less emphasis on minimization of delay (contrast with LD). Often loosely associated with HE.
R-D: Rate-distortion.
RDO: Rate-distortion optimization.
RDOQ: Rate-distortion optimized quantization.
ROT: Rotation operation for low-frequency transform coefficients.
RQT: Residual quadtree.
RRU: Reduced-resolution update (e.g. as in H.263 Annex Q).
RVM: Rate variation measure.
SAO: Sample-adaptive offset.
SDIP: Short-distance intra prediction.
SEI: Supplemental enhancement information (as in AVC).
SD: Slice data; alternatively, standard-definition.
SH: Slice header.
SPS: Sequence parameter set (as in AVC).
TE: Tool Experiment a coordinated experiment conducted between the 1st and 2nd or 2nd and 3rd JCT-VC meeting.
Unit types:
CTB: code tree block (synonymous with LCU or TB).
CU: coding unit.
LCU: (formerly LCTU) largest coding unit (synonymous with CTB or TB).
PU: prediction unit, with four shape possibilities.
2Nx2N: having the full width and height of the CU.
2NxN: having two areas that each have the full width and half the height of the CU.
Nx2N: having two areas that each have half the width and the full height of the CU.
NxN: having four areas that each have half the width and half the height of the CU.
TB: tree block (synonymous with LCU LCU seems preferred).
TU: transform unit.
VCEG: Visual coding experts group (ITU-T Q.6/16, the relevant rapporteur group in ITU-T WP3/16, which is one of the two parent bodies of the JCT-VC).
VPS: Video parameter set a parameter set that describes the overall characteristics of a coded video sequence conceptually sitting above the SPS in the syntax hierarchy.
WD: Working draft the draft HEVC standard corresponding to the HM.
WG: Working group (usually used in reference to WG 11, a.k.a. MPEG).
Liaison activity
The JCT-VC did not send or receive formal liaison communications at this meeting.
Opening remarks
The status of the HEVC draft text in ISO/IEC and ITU-T was noted. A DIS ballot had been issued in ISO/IEC and had not yet closed. In ITU-T, the text status remains as preparation for Consent.

Scheduling of discussions
Scheduling: Generally 0800 2200, coffee available 10301130 & 15301630, lunch available 12001400.
First day (Wed 10 Oct): 09001900, morning plenary. Lunch break 13001400. Afternoon SVC proposal reviews and BoG activities on deblocking, high-level parallelism, and general HLS.
Second day: 0800
Mon + Wed morning not meet as JCT-VC during MPEG plenary.
Fri 19 end by lunchtime.

Contribution topic overview
The approximate subject categories and quantity of contributions per category for the meeting were summarized and categorized into "tracks" (A, B, or P) for "parallel session A", "parallel session B", or "Plenary" review, as follows. Discussions on topics categorized as "Track A" were primarily chaired by Gary Sullivan, and discussions on topic categorized as "Track B" were primarily chaired by Jens-Rainer Ohm. Some plenary sessions were chaired by both co-chairmen, and others were chaired by Gary Sullivan. (Note: allocation to tracks may be subject to changes)
AHG reports (9) Track P (section REF _Ref298681007 \r \h 2)
Project development, status, and guidance (8) Track P (section REF _Ref298681010 \r \h 3 and section REF _Ref329616948 \r \h 5.1)
BoG on Conformance (T. Suzuki)
CE1: Deblocking filter (9) Track B (section REF _Ref315459013 \r \h \* MERGEFORMAT 4.1)
BoG: Subjective viewing (T. Yamakage)
Clarifications and bug fix issues (0) Track P (section REF _Ref330192639 \r \h 5.2)
HM settings and common test conditions (0) Track P (section REF _Ref315459091 \r \h 5.3)
HM coding performance (3) Track P (section REF _Ref315459105 \r \h 5.4)
Profile/level definitions (5) Track P (section REF _Ref315459112 \r \h 5.5)
Source video test material (3) Track A (section REF _Ref315459119 \r \h 5.6)
Scalable video coding (25) Track P (section REF _Ref337191567 \r \h 5.7)
BoG (A. Segall)
Extended colour component sampling (17) Track A (section REF _Ref337191593 \r \h 5.8)
BoG (D. Flynn)
Higher bit-depth (3) Track A (section REF _Ref337191611 \r \h 5.9)
Interlaced scan and field-based video coding (14) Track A (section REF _Ref337191632 \r \h 5.10)
Deblocking filter (10) Track B (section REF _Ref298625381 \r \h \* MERGEFORMAT 5.11)
Sample adaptive offset (5) Track B (section REF _Ref337191661 \r \h 5.12)
Other loop and interpolation filters (4) Track B (section REF _Ref337191682 \r \h 5.13)
Block structures and partitioning (1) Track B (section)
Motion and mode coding (3) Track B (section REF _Ref315459191 \r \h \* MERGEFORMAT 5.15)
High-level syntax and tile/slice structures (81) Track A (section REF _Ref337191773 \r \h 5.16)
NAL unit header (3 ( 1) (section REF _Ref330015151 \r \h 5.16.1)
Random access and adaptation (8 (36) (section REF _Ref337850385 \r \h 5.16.2 REF _Ref330015157 \r \h 5.16.1)
Slices and slice header parameters (9 ( 35) (section REF _Ref330015159 \r \h 5.16.3)
Reference picture signalling (10) (section REF _Ref337191807 \r \h 5.16.4)
Parameter sets in version 1 (6) (section REF _Ref330015177 \r \h 5.16.5)
High-level syntax cleanups (9) (section REF _Ref337191837 \r \h 5.16.6)
BoG on general HLS (M. Hannuksela, then Y.-K. Wang) Topic #1
High-level parallelism (10) (section REF _Ref337191868 \r \h 5.16.7)
BoG on high-level parallelism (M. Horowitz and/or C. A. Segall)
HRD (5) (section REF _Ref330015196 \r \h 5.16.8)
VUI and SEI (17) (section REF _Ref330015198 \r \h 5.16.9)
BoG on general HLS (M. Hannuksela, then Y.-K. Wang) Topic #2
Parameter sets in scalable and 3D extensions (10) (section REF _Ref330272825 \r \h 5.16.10) Track P
BoG (Y.-K. Wang)
Quantization (5) Track B (section REF _Ref323154343 \n \h \* MERGEFORMAT 5.17)
Entropy coding (0) Track B (section REF _Ref298681721 \r \h \* MERGEFORMAT 5.18)
Transform coefficient coding (4) Track B (section REF _Ref330214990 \r \h 5.19)
Intra prediction and mode coding (5) Track B (section REF _Ref315459263 \r \h \* MERGEFORMAT 5.20)
BoG (A. Tabatabai) for informal viewing for JCTVC-K0139
Transforms (0) Track B (section REF _Ref315459278 \r \h \* MERGEFORMAT 5.21) With CE1
Memory bandwidth reduction (3) Track B (section REF _Ref315459290 \r \h 5.22)
Alternative coding modes (13) Track B (section REF _Ref315459298 \r \h 5.23)
Non-normative (7) Track B (section REF _Ref315459311 \r \h 5.24)
Outputs & planning: AHG & CE plans, Conformance, Chroma format BoG, CTC. (section REF _Ref330498123 \r \h 9)
NOTE The number of contributions noted in each category, as shown in parenthesis above, may not be 100% precise.
Overall approximate contribution allocations: Track P: 50; Track A: 112; Track B: 69.
AHG reports
The activities of ad hoc groups that had been established at the prior meeting are discussed in this section.

JCT-VC project management (AHG1) [G. J. Sullivan, J.-R. Ohm (cochairs)]
Discussed verbally. State of drafting reviewed. CfP responses.
work deliverables:
HEVC standard
Reference software
Conformance
SVC extensions
Prof Prof extensions

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6724" JCTVC-K0002 JCT-VC AHG report: HEVC Draft and Test Model editing (AHG2) [B. Bross, K. McCann (co-chairs), W.-J. Han, I.-K. Kim, J.-R. Ohm, K. Sugimoto, G. J. Sullivan, T. Wiegand (vice-chairs)]
One version of JCTVC-J1002 and eight successive versions of JCTVC-J1003 were published by the Editing AHG following the 10th JCT-VC meeting in Stockholm. The text of the final draft of JCTVC-J1003 (revision 7) was submitted for the ISO/IEC Draft International Standard ballot.

Both documents were approved as recommended by the AHG.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6699" JCTVC-K0003 JCT-VC AHG report: Software development and HM software technical evaluation (AHG3) [F. Bossen, D. Flynn, K. Suehring] [miss]
HM 8.0 delivered earlier than planned
HM 8.1 was slightly delayed
Performance:
- Small loss 0.1-0.2% in intra (likely due to DST simplification)
- Gain 0.4% in RA due to changes in SAO
- Gain in class F generally due to transform skipping (around 5%)
Bug tracker BBC has announced that they will not be able to continue after spring 2013 (may continue mirror of HM software)
HHI has offered to take over the service
Another possibility would be Paris Tech (who indicated intention to offer bug tracking service)
It was asked in the plenary whether other companies would be interested. So far, nobody indicated interest.
Bug tracker Who should host that in the future? HHI has offered.
Mirroring is also a current practice, and can continue.
BBC is thanked for its prior hosting, and may continue to mirror for some time.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6696" JCTVC-K0004 JCT-VC AHG report: High-level parallelism (AHG4) [M. Horowitz (eBrisk), M. Zhou (TI)]
Email discussions had taken place on email reflector regarding decoder parallelism indication and whether it is desirable to require fixed tile partitioning for a coded video sequence instead of allowing it to change from picture to picture. This was mentioned at the JCT-VC meeting, with no need for action identified.
In addition, a message was posted noting that a WPP transcoder based on contribution J0032 had been migrated to HM8.
The following input documents have been identified as relevant to AHG4. The contributions, listed in this section, have been organized into five categories:
General (not specific to tiles or WPP)
Tiles
WPP (wavefront parallel processing)
Entry points
Profile and level

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6723" JCTVC-K0005 HEVC conformance test development (AHG5) [T. Suzuki, C. Fogg, W. Wan]
Plan for meeting:
- Identify clusters of tools to be tested, and volunteers who take over responsibility for the bitstreams (list of volunteers existed from the previous meeting, but no assignments made so far)
- Draft of conformance spec (including list of responsibilities) as output from meeting
It is suggested by one expert (and no objection is raised against that) to remove tools from the standard that would not be covered by conformance testing
BOG (T. Suzuki) to work on this (from Wednesday)
Two relevant contributions were identified: K0111 and K0162.
More progress is needed on this topic. A desire was expressed to identify particular volunteers to work on conformance testing of specific feature areas. Timeline clarification is also needed.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6697" JCTVC-K0006 JCT-VC AHG report: In-loop filtering (AHG6) [T. Yamakage, A. Norkin]
The relevant contributions were reviewed in the AHG report. These fell into the following categories:
Deblocking (including CE1)
SAO
Other in-loop filtering (K0172 zero-delay non-local means filter and K0273 ALF)
BoG (T Yamakage) to identify the proposals (CE with priority, non-CE if deemed interesting) to undergo subjective viewing BoG Tuesday afternoon, report plan later
Viewing to start Tuesday evening or Wednesday morning

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6767" JCTVC-K0007 JCT-VC AHG report: Support for range extensions (AHG 7) [David Flynn, Pierre Andrivon, Eduard Francois, Marta Mrak, Ken McCann, Karl Sharman]
TBA.
Lossless coding? Needs clarification about requirement for an unconstrained lossless mode/profile (which may not necessarily need to support real-time decoding)
BoG on range extensions (D Flynn)

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6721" JCTVC-K0008 JCT-VC AHG report: Reference picture buffering and list construction (AHG8) [R. Sjöberg, Y. Chen, Y.-K. Wang, Hendry, T.K. Tan]
The test recommendation for reference picture buffering and list construction proposals is available in JCTVC-J0513. A table in the AHG report shows the 13 different pictures structures defined in this document.
Anchor source code supporting all test cases was made available on Oct 4 in the HM-8.1-dev-ahg8 branch. A config file for each test case is available in HM-8.1-dev-ahg8/cfg/ JCTVC-J0513/. Most test cases are supported by only config file changes but cases 2.6, 3.3 and 3.4 contain source code changes as well. The code does not yet support long-term reference picture coding in the SPS. Due to lack of time anchors were not generated.
The HM-8.1-dev-ahg8 source code contains bit count functionality. It reports the number of bits spent on reference picture set and reference picture lists in a bit stream. This includes SPS, PPS and slice header syntax. A problem with the bit-counting code was found and reported as Ticket #645. The code assumed that all slices were parsed two times when in fact it is only the first slice for each picture that is parsed twice. This does not affect random-access test cases since one slice per picture is used there. A fix for ticket #645 was committed on October 8. RPS costs in the tables in the report show the average percentage of bits that are spent on RPS related syntax.
The report listed the relevant input contributions (approximately 9 contributions).
The JCT-VC discussed how to transition the relevant aspects from this "side branch" into the main branch of the reference software development effort.
Software development of AHG to be moved to main branch of software in HM9. Some elements may be hard coded (LT reference pictures). One issue about LT pictures in the SPS still needs to be resolved, but this should be doable shortly (volunteer exists according to AHG chair).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6731" JCTVC-K0009 JCT-VC AHG report: High-level syntax (AHG9) [Y.-K. Wang, G. J. Sullivan (co-chairs)]
A face-to-face AHG meeting was held from 0900 1800 on October 9, 2012, at the same meeting venue as the 11th JCT-VC meeting. Roughly 100 persons attended that meeting. The AHG meeting was chaired by Gary Sullivan and Ye-Kui Wang. Meeting minutes and AHG recommendations made during the face-to-face meeting were included in the report. Relevant contributions were also listed.
There was a discussion on the relationship of profile, tier and level information included in the active VPS and the active SPS for the base layer.
Currently, it is stated in a note in HEVC draft 8 that the maximum level signalled in the video parameter set may be higher than the level signalled for a coded video sequence in the sequence parameter set. There was a suggestion made by Mathias Wien to explicitly require the profile_tier_level() syntax structures present in both the VPS and the SPS to be identical for a coded video sequence, and to add a note to explain the envisioned usage in the potential scalable and/or 3DV extensions.
There were some followup discussions between Jill Boyce, Ye-Kui Wang, and Ajay Luthra on this syntax hierarchy relationship. Luthra and Wang generally discussed the relationship between system-layer and video-layer functionalities in various system environments. No conclusion was made.
The JCT-VC discussed this issue during review of the AHG report.
Decision (Ed.): It was agreed that the profile/tier/level capabilities expressed at the VPS level may be a superset of those expressed at the SPS level.

The AHG requests the JCT-VC to consider and resolve the above issue at this meeting.
Due to lack of time, the AHG only reviewed contributions in the following four topic areas during:
NAL unit header (3 contributions)
Random access and adaptation (6 contributions)
Slices (6 of the 8 contributions; 2 contributions in this category were not reviewed due to the absence of presenters)
Misc. SEI messages (1 of the 7 contributions)
Detailed notes of the discussion in each of these areas are found in the following sections. Certain key aspects are highlighted with yellow highlighting for the review and attention of the JCT-VC.
[Add notes from the BoG report into document-specific notes sections]

Project development, status, and guidance
Communication by parent bodies
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6728" JCTVC-K0328 Liaison Statement from DVB to SC 29/WG 11 [DVB via SC 29 Secretariat]

for information
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6764" JCTVC-K0355 Liaison Statement from EBU to SC 29/WG 11 [EBU via SC 29 Secretariat]
for information

Conformance test set development
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6768" JCTVC-K0358 BoG report on conformance testing [T. Suzuki]
Initial draft selected based on K0111 see notes in that section.
Work done to begin identifying desired bitstreams and plan logistics for bitstream exchange.
Bitstream exchange directory created at HYPERLINK "ftp://ftp3.itu.int" ftp3.itu.int in av-arch/jctvc-site/bitstream_exchange directory.
It was agreed to consider removing tools from the standard if no bitstreams are volunteered to test the tool.
BoG recommendations were agreed by the JCT-VC.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6481" JCTVC-K0111 AHG5: On HEVC conformance testing [T. Suzuki, A. Tabatabai (Sony)]
(BoG discussion chaired by W. Wan)
This contribution proposes the followings as a starting point of the discussion on HEVC conformance testing,
- Define conformance testing similar to AVC conformance testing
- Clarify what should be tested by using excel spread sheet
- Set up a repository for conformance/bitstream exchange
More detail parameters of bitstream should be discussed during the Shanghai meeting
An initial draft is provided using the AVC conformance testing document as its initial basis.
The BoG recommended using this draft as a starting point for HEVC conformance.
Decision: Agreed.
A question was asked about both the static and dynamic tests being included and if they were included in the AVC conformance specification. It was confirmed that both tests were included in the AVC conformance specification but also noted that it may not be used in practice due to difficult in testing. The BoG recommends that the decision to include or remove the dynamic test should be further studied.
Decision: Agreed.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6533" JCTVC-K0162 Corner case conformance bitstreams [C. Fogg, A. Wells (??)]
With the aim of improving the chances of interoperability, a list of conformance bitstreams is proposed that test corner cases the authors feel are likely to lead to behaviour mismatch among decoders. Suggested bitstream features are included in the candidate of conformance bitstream list.
Draft text specification
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6470" JCTVC-K0030 Proposed Editorial Improvements for High efficiency video coding (HEVC) Text Specification Draft 8 [B. Bross, G. J. Sullivan, T. K. Tan, Y.-K. Wang]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6534" JCTVC-K0163 Updated figures for HEVC specification [C. Fogg (??)]

Core experiments
CE1: Deblocking Filter
CE1 sSummary and general discussion
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6710" JCTVC-K0021 CE1: Summary report of Core Experiment on deblocking filtering [A. Norkin, T. Suzuki, M. Budagavi, G. Van der Auwera] [miss]
This contribution is a summary report of Core Experiment 1 on deblocking filtering. Based on the results of the subjective test, it has been decided to further study separate components of proposals JCTVC-J0181 (new CE1 doc JCTVC-K0149) and JCTVC-J0286 (new CE1 doc JCTVC-K0186) and their combinations in the CE1 as well as the TU based decisions from JCTVC-J0189 and JCTVC-J0096. It has been decided to study performance of the proposals on critical sequences (i.e. those showing blocking artifacts in the default operating mode) as well as studying the performance on sequences from the common test conditions in order to ensure there is no degradation of subjective quality. All the tests are based on HM8.0. The experiments are performed according to the common test conditions provided in JCTVC-J1100. Additionally, all the proposals provide results for LD-P configurations and the results on additional sequences from CE1.
Also selected for subj. viewing was the combination test 1+4 = test 5.
CE results unveil no significant change in rate or PSNR.
From the preliminary assessment of cross-checkers, differencs are mainly visible in QP ranges where the picture quality is low and sometimes assessed unacceptable for the anchor, artifacts are less visible for proposed technology.
(Refer to JCTVC-K0342 for test plans.)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6751" JCTVC-K0342 BoG report on subjective viewing set up for delocking filter [T. Yamakage]
This report described plans for subjective viewing for proposals (both CE1 and non-CE1/AHG6 proposals) on deblocking filter whose technical modifications are considered to affect subjective picture quality. Approximately 20 people (proponents, cross-checkers and non-proponents) participated in the BoG discussion held at Banquet Hall 3 at 2pm to 7pm on Oct. 10, 2012.
Eight proposals were recommended by the BoG for subjective viewing by ABAB scoring.
Test 1 from CE: K0149 (Sony)
Test 4 from CE: K0186 (Ericsson)
Test 5 from CE: K0149 (Sony)
JCTVC-K0138 [Qualcomm] Non-CE1: Deblocking of Large Block Artifacts
To increase the normal filter clipping bounds for edges of the maximum transform blocks and to restrict boundary filtering for DC, horizontal and vertical intra modes.
JCTVC-K0150 [Sony] NonCE1: Simple improvement of Deblocking filter
An adaption on thresholds usage to address severe block noise in some sequences without changes on the current filter design (i.e., use (Bs+1)*² and (Bs+1)*tc instead of using table-derived ² and tc values directly).
JCTVC-K0269 [TI] Non-CE1: Suppression of blocking artifacts at large TU boundaries
Blocking artifacts at large TU boundaries suppressed by applying the largest values of beta_offset_div2 and tc_offset_div2 to the maximum TU boundaries and disabling intra-prediction boundary filtering at 32x32 blocks at the cost of marginal BD-rate loss. To apply beta and tc offsets only to the largest TU boundary, it is proposed to signal in PPS and slice header a new syntax element max_tu_offset_flag to specify whether the signaled beta and tc offsets are applied to all block boundaries or maximum TU boundaries only.
JCTVC-K0289 variations 1 and 2 [Ericsson] Non-CE1: Non-normative improvement to deblocking filtering
Non-normative
Sending deblocking parameters tc_offset for the pictures (slices) at different GOP positions (i.e. having different "depth" in coding hierarchy). (i.e., depth 0: tc_offset_div2 = 0, depth 1: tc_offset_div2 = 2, depth 2: tc_offset_div2 = 3, depth 3: tc_offset_div2 = 4)
Variation 1: HM8 + JCTVC-K0289
Variation 2: CE1 Test4 + JCTVC-K0289
Further discussion in plenary:
No test on K0138; as no one except proponents confirms that it has benefit, and we need to avoid viewer fatigue caused by needing an excessively-long test session.
It should be confirmed that the data rates are similar
Tests round 1 to be run Thursday, further discussion Friday

CE1 primary cContributions
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6520" JCTVC-K0149 CE1: On deblocking filter [S. Lu, O. Nakagami, T. Suzuki (Sony)]
See prior contribution JCTVC-J0181, S. Lu, O. Nakagami, M. Ikeda, T. Suzuki (Sony).
It is proposed to replace the ² values with Table. The value is determined by the principle that the changing rate of ² should have similar trend with the changing rate of tc to reflect quantization change. Since the changes lie at QP bigger than 41, there is no impact on common test conditions (provided the QP values in CTC do not change).
The tool is used by sending the deblocking beta_offset to the decoder, so that modified part of the beta table is used.
Selected for subj. viewing (test 1)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6557" JCTVC-K0186 CE1: Reduction of block artifacts in HEVC [A. Norkin (Ericsson)]
See prior contribution JCTVC-J0286, A. Norkin (Ericsson).
It is proposed to remove the intra-boundary smoothing (applied in HEVC for DC, vertical and horizontal prediction modes) from the larger intra-block sizes (32x32 and possibly 16x16). This reportedly avoids forming irregularities on left and/or top boundaries of intra-blocks. Two conditions in strong filter decision are modified to enable application of the HEVC strong filter on inclined surfaces (current HEVC strong filter is applied to the flat surfaces). Strong filter also changed
Selected for subj. viewing (test 4): Strong filter decision + strong filter, intra_tc_offset changed from 2 to 3, BS value changed for 32x32 TU.
CE1 cCross checks
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6522" JCTVC-K0151 CE1:Cross check of test7 in CE1 [S. Lu, O. Nakagami (Sony)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6558" JCTVC-K0187 CE1: Cross-check of Test 3 (K-149, Sony) by Ericcson [A. Norkin (Ericsson)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6584" JCTVC-K0212 CE1: Cross-check of Test 4 [W. Wan, P. Chen (Broadcom)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6624" JCTVC-K0243 CE1: Cross-check of JCTVC-K0149 and JCTVC-K0186 [G. Van der Auwera (Qualcomm)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6654" JCTVC-K0266 CE1: Cross-check for test 2. [E. Alshina (Samsung)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6655" JCTVC-K0267 CE1: Cross-check for test 6 [E. Alshina (Samsung)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6671" JCTVC-K0281 CE1: Cross-check of Test 8, Test 9, Test 5 [M. Budagavi, D.-K. Kwon (TI)]

Non-CE Technical Contributions
HEVC Standard Development
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6677" JCTVC-K0287 CANNB comments on HEVC and HEVC profiles [G. Martin-Cocher (RIM)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6694" JCTVC-K0304 UKNB Comment on HEVC Extensions [UK National Body] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6693" JCTVC-K0303 UKNB Comment on Interlaced support in HEVC [UK National Body] [late]

Clarification and Bug Fix Issues
HM settings and common test conditions
Coding performance
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6480" JCTVC-K0110 Comparison of Compression Performance of HEVC with AVC at different resolutions [P. Sunna (RAI), M. Arena (RAI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6660" JCTVC-K0272 Compression performance comparison of HEVC with AVC at cfp target bitrates [J. Zheng, Y. Lin (HiSilicon)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6669" JCTVC-K0279 Comparison of Compression Performance of HEVC Draft 8 with AVC High Profile and Performance of HM8.0 with Different Delay Characteristics [B. Li (USTC), G.J. Sullivan, J. Xu (Microsoft)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6725" JCTVC-K0327 On software complexity: decoding 1080p content on a smartphone [F. Bossen (Docomo Innovations)] [late]

Profile, level, and constraint definitions (for version 1 of HEVC)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6675" JCTVC-K0285 In Support Of A Still Frame Profile of HEVC v1 [W. Dai, M. Krishnan, P. Topiwala (FastVDO)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6479" JCTVC-K0109 On 10 bit Profile on High efficiency video coding (HEVC) [Alberto Duenas (NGcodec)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6547" JCTVC-K0176 AHG9: On LCU bit size limit [K. Chono (NEC)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6572" JCTVC-K0201 AHG9: on number of slices constraint [M. Zhou (TI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6573" JCTVC-K0202 AHG9: on number of tiles constraint [M. Zhou(TI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6560" JCTVC-K0189 On Annex A [TK Tan (NTT Docomo)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6706" JCTVC-K0313 Weak profile compatibility signalling (was K0297) [David Flynn, Gaelle Martin-Cocher, Lowell Winger] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6599" JCTVC-K0225 On DPB Extension [L. Kerofsky, S. Deshpande (Sharp)]
(Reviewed in Track A.)
The HEVC design includes a decoded picture buffer (DPB) for holding pictures for reference and reordering. The value of MaxDpbSize influences memory needs of a decoder and is defined through level parameters. Given a maximum DPB size parameter (MaxDpbPicBuf), maximum luma picture size (MaxLumaPS), and size of a picture in the current sequence (PicSizeInSamplesY), the maximum number of reference pictures supported (MaxDpbSize) is determined. The current calculation in HEVC Draft 8 for MaxDpbSize is invariant to bit-depth or chroma subsampling other than 8-bit 4:2:0. This proposal describes changing the buffering requirements as a function of bit-depth and alternate chroma subsampling formats.
It was noted that this does not affect Main profile.
It was noted that in AVC there is (intentionally) no modification of buffering capacity in units of frames as a function of chroma format or bit depth. The group opinion was that the AVC approach was the better approach. No action.
Source video test material
(all related to chroma extensions)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6578" JCTVC-K0207 AHG7: Update on full-chroma (YUV444) screen content test sequences of JCTVC-H0294 [Shuhui Wang, Tao Lin, Kailun Zhou (Tongji U)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6778" JCTVC-K0368 Impact of transform skip on screen content sequences from JCTVC-K0207 [R. Cohen (MERL), T. Lin (Tongji Univ.)] [late]
[mis-categorized?]
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6627" JCTVC-K0246 AHG7: The need for screen-content/graphics test material for extended chroma formats [R. Cohen, A. Vetro (MERL)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6686" JCTVC-K0296 AHG7: Additional test sequences (computer graphics) [M. Mrak, G. Thomas] [late]

Scalable video coding
Scalable coding general discussions
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6763" JCTVC-K0354 BoG report on HEVC scalable extensions (draft) [Andrew Segall]
Status reviewed Saturday p.m.:
Tools summarized
Bitstream verification spot-checking
Informal viewing planned for a few representative proposals
Five software basis candidates were offered associated with K0345, K0348, K0362, K0364, K0366 these candidates can be discussed and commented on (verbally or in document submissions).
It was suggested to begin planning for "tool experiments" (without necessarily entangling that with the software basis selection question).
Performance comparison: Would be interesting to include an analysis not only about gain against simulcast, but also loss against single layer (i.e. simulcast high-only)
Subjective viewing: Three proposals from categories a) prediction from co-located base layer texture, b) a plus additional motion/mode/difference prediction, c) b plus additional EL tools
To proceed:
Establish a list of tools to be further investigated in (tool) experiments
Decide about a common reference for comparison
Investigate which software is best fulfilling that purpose
Best comparison point is an intra BL method (i.e. upsampling and method of signaling base-layer prediction)
Does it matter which method of upsampling and base-layer prediction is used (likely not)
How to design this element? Eventually combine elements from different proposals?

CfP submissions
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6661" JCTVC-K0031 Description of scalable video coding technology proposal by Sharp (proposal 1) [K. Misra, J. Zhao, S. H. Kim, S. Deshpande, A. Segall (Sharp)]
This proposal is Sharps response to the Call for Proposals (CfP) on Scalable Video Coding Extensions for High Efficiency Video Coding jointly issued by ISO/IEC JTC 1/ SC 29/WG 11 and ITU-T SG 16 WP 3. The proposal provides a description of a scalable video coding extension for HEVC with higher coding efficiency compared to simulcast transmission of video data using HEVC.

The proposed scalable design is asserted to be a straightforward extension of the current HEVC system, and it contains the following features. First, up-sampled base layer pictures are available as additional reference frames during by the motion compensation process. Second, multiple up-samplers are supported and also managed through the prediction process. Third, base layer motion data is incorporated into the merge and motion vector prediction processes at the enhancement layer. Fourth, high frequency inter- and intra-prediction operations are allowed in the pixel difference domain. Fifth, additional tables are made available for CABAC initialization. Finally, we mention that the design does not incorporate additional single layer coding tools, such as adaptive loop filtering (ALF) or internal bit-depth increase (IBDI).

The resulting system achieves the following average BD rate improvement relative to simulcast anchors provided in the joint call for proposal:
EL-only actual rate:RA HEVC 2x -30.4%(Y) -18.4%(U) -18.1%(V)RA HEVC 1.5x -47.8%(Y) -41.0%(U) -40.1%(V)EL-only target rate:RA HEVC 2x -28.4%(Y) -16.0%(U) -15.7%(V)RA HEVC 1.5x -45.8%(Y) -38.7%(U) -37.8%(V)EL+BL actual rate:RA HEVC 2x -20.5%(Y) -10.2%(U) -9.9%(V)RA HEVC 1.5x -28.4%(Y) -22.0%(U) -21.3%(V)EL+BL target rate:RA HEVC 2x -19.0%(Y) -8.5%(U) -8.2%(V)RA HEVC 1.5x -27.0%(Y) -20.5%(U) -19.8%(V)
Category: Only HEVC RA SS.
Double loop approach using co-located upsampled base-layer
Motion vector candidates scaled up from base layer, modified merge list and AMVP
Adaptive upsampler (switched on PU basis)
Difference mode which uses low frequency information from upsampled base layer, where the upsampled base layer of the reference picture is subtracted from the enhancement layer reference picture to compute a high-detail prediction component; low detail is predicted from the up-sampled base layer of the current picture; difference mode is switchable on CU basis.
Difference mode requires additional motion comp of base layer with full-pel accuracy (if computed on the fly) with subsequent quarter pel on the difference, or duplicating the DPB when difference is computed in advance.

The proposed scalable design is asserted to be a straightforward extension of the current HEVC system, and it contains the following features.
Up-sampled base layer pictures are available as additional reference frames during by the motion compensation process.
Multiple up-samplers are supported and also managed through the prediction process.
Base layer motion data is incorporated into the merge and motion vector prediction processes at the enhancement layer.
High frequency inter- and intra-prediction operations are allowed in the pixel difference domain (with motion compensation in the difference domain).
Additional tables are made available for CABAC initialization.
The design does not incorporate additional single layer coding tools, such as adaptive loop filtering (ALF) or internal bit-depth increase (IBDI).
Highlights:
Not a lot of added tools
Adaptive upsampler, switched on PU basis
Multi-loop
Motion comp in a difference domain (difference between reference enhancement-layer picture and upsampled reference base-layer picture).
Number of pictures in DPB is basically doubled by storing both a base layer and enhanced frame for each picture in the DPB.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6642" JCTVC-K0032 Description of scalable video coding technology proposal by SHARP (proposal 2) [T. Yamamoto, Y. Yasugi, H. Kumai, M. Takahashi (Sharp)]
This contribution presents SHARP propoal in response to Call for Proposal on Scalable Video Coding Extension of HEVC. One significant characteristics of the proposed codec is that it only uses base-layer reconstruction data as inter-layer information. Thus it is capable of producing scalable bitstream in which base layer is encoded with non-HEVC codec such as MPEG-2 and AVC. The luma enhancement layer bd-rate reductions for HEVC 2x scalability are 34.1% and 26.5% for intra only and random access configuration respectively compared to HEVC higher layer anchor. For HEVC 1.5x scalability, they are 53.7% and 44.3%. For Hybrid 2.0x scalability, in which AVC base layer is used, the bd-rate reduction is 23.0% compared to HEVC higher layer anchor, and 49.4% compared to AVC higher layer anchor. For Hybrid 1.5x scalability, the one is 37.3% compared to HEVC, and 61.9% compared to AVC.

Category: All except SNR
Double-loop approach
hybrid intra and inter layer prediction DC component inferred from upsampled base layer for each 4x4 block in case of intra pred.
No motion or mode inference
secondary adaptive upsampling filter with additional quad-tree structure that is independent of LCU structure. Has different coefficients on diagonals (ALF-like approach)
additionally ALF and AMP in EL

Highlights:
Multi-loop
Only the collocated base layer decoded picture is used for ILP (can therefore easily support any base layer format)
Hybrid intra and inter-layer prediction mode (intra prediction as in HEVC, with 4x4 DC from base layer)
Adaptive filter for inter-layer prediction with quadtree control
Temporal prediction MC is full-band prediction
ALF in enhancement layer

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6592" JCTVC-K0033 Description of scalable video coding technology proposal by LG Electronics and MediaTek (differential coding mode on) [C. Kim, J. Park, J. Kim, Hendry, B. Jeon (LG Electronics), S. Liu, X. Zhang, M. Guo, Z. Chen, T.-D. Chuang, S.-T. Hsiang, C.-Y. Chen, C.-Y. Tsai, C.-M. Fu, C.W. Hsu, Y.-W. Huang, S. Lei (MediaTek)]
This contribution is the LG Electronics and MediaTek response to the Joint Call for Proposals (CfP) on Scalable Video Coding Extensions of High Efficiency Video Coding (HEVC) issued by ISO/IEC JTC1/SC29/WG11 (MPEG) and ITU-T SG16 WP3 (VCEG). The goal of this proposal is to provide scalable coding technologies on top of the new HEVC draft standard. In order to achieve this goal, a number of coding tools are proposed with respect to several aspects of scalable video coding mechanism. These include inter-layer (IL) coding modules such as IL up-sampling filters, IL sample adaptive offset, IL adaptive loop filter, IL texture prediction, IL differential coding, IL motion vector prediction, and IL mode prediction, as well as enhancement layer (EL) coding modules such as EL inter prediction, EL intra prediction, EL sample adaptive offset, EL adaptive loop filter, EL deblocking filter, EL rate distortion optimized quantization, and EL internal bit-depth increase. With all proposed tools enabled, the proposed scalable video codec reportedly achieves 35%, 52%, 38%, 57%, and 43% BD-rate savings for category 1 2x spatial scalability (namely RA-2x, where RA means random access), category 1 1.5x spatial scalability (namely RA-1.5x), category 1 2x intra-only spatial scalability (namely AI-2x, where AI means all intra), category 1 1.5x intra-only spatial scalability (namely AI-1.5x), and category 1 SNR scalability (namely RA-SNR), respectively, when compared with the CfP EL-only actual rate anchors. When compared with the CfP EL+BL actual rate anchors, the corresponding BD-rate savings are 24%, 32%, 27%, 35%, and 30%. For each test point, the actual rate is within 0.4% variation of the target rate. The average encoding time increases for the proposed scalable encoder compared with HM6.1 single layer encoder using EL spatial resolution are 136%, 157%, 190%, 203%, and 224% for RA-2x, RA-1.5x, AI-2x, AI-1.5x, and RA-SNR, respectively. The corresponding average decoding time increases are 141%, 134%, 97%, 107%, and 199%.
Categories: All except hybrid
Double-loop approach
Upsampling filter DCT-IF
Additional inter-layer SAO (modified) and ALF
Inter-layer differential coding (similar to JCTVC-K0031) not used in the alternative proposal JCTVC-K0050.
Use upsampled co-located BL motion vectors in EL MV coding (merge, AMVP)
additionally ALF and IBDI used in EL
Use up-sampled BL samples in intra prediction when EL samples are not available
IBDI was used in EL, and PSNR was computed in 10 bits (could this give around 1.5%?)
Q: Is upsampling done in 10 bits? (A: internally 14, truncated to 10)
Chroma improvement could that be due to specific RDOQ?

Features include
inter-layer (IL) coding modules such as
IL up-sampling filters
IL sample adaptive offset
IL adaptive loop filter
IL texture prediction
IL differential coding (similar to element of Sharp proposal K0031, disabled for K0050)
IL motion vector prediction
IL mode prediction
enhancement layer (EL) coding modules such as:
EL inter prediction
EL intra prediction
EL sample adaptive offset
EL adaptive loop filter
EL deblocking filter
EL rate distortion optimized quantization (non-normative improvement)
EL internal bit-depth increase
A participant questioned the PSNR measurement for the bit-depth increase aspect.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6601" JCTVC-K0050 Description of scalable video coding technology proposal by LG Electronics and MediaTek (differential coding mode off) [C. Kim, J. Park, J. Kim, Hendry, B. Jeon (LG Electronics), S. Liu, X. Zhang, M. Guo, Z. Chen, T.-D. Chuang, S.-T. Hsiang, C.-Y. Chen, C.-Y. Tsai, C.-M. Fu, C.W. Hsu, Y.-W. Huang, S. Lei (MediaTek)]
See discussion of K0033.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6612" JCTVC-K0034 Description of scalable video coding technology proposal by InterDigital Communications [Jie Dong, Yong He, Yuwen He, George McCllelan, Eun-Seok Ryu, Xiaoyu Xiu, Yan Ye (InterDigital Communications)]
This proposal is InterDigital Communications response to the Call for Proposals (CfP) on scalable video coding extensions of HEVC, jointly issued by ITU-T SG16 Q.6 (VCEG) and ISO/IEC JTC1/SC29/WG11 (MPEG). The goal of this proposal is to provide a scalable video compression technology which has significantly higher compression capability than a simulcast solution which simply compresses the two or more layers of video inputs separately. To achieve this goal, a number of new algorithmic tools are proposed, primarily focusing on improving inter layer prediction at the picture level. The picture level inter layer prediction tools include selectable upsampling filters, intra mode dependent directional filters, motion field mapping, enhancement layer skipped slice, and adaptive reference picture placement. The inter layer reference is then used together with the temporal reference pictures to predict the enhancement layer picture. The enhancement layer encoder and decoder are kept primarily the same as the single layer HEVC codec, with only one additional in-loop filter, called edge enhancement filter, applied at the picture level, whereas block level operations in the enhancement layer are kept exactly the same as the single layer HEVC codec. The proposed video codec achieves approximately {34%, 55%, 25%, 45%, 33%} bit rate savings in the enhancement layer for {AI 2x, AI 1.5x, RA 2x, RA 1.5x, RA SNR} scalability case in category 1, and {24%, 41%} bit rate savings for {RA 2x, RA 1.5x} scalability case in category 2. The average decoding time for the proposed system was measured to be between about 1.2 and 3.1 times that of the corresponding anchors for category 1, and between about 2.6 and 4.6 times that of the corresponding anchors for category 2.
Categories:All
Three up-sampling filters: Default, selectable (4 filter sets with relevant subsampling phases, filter sizes 6x6, 6x7, 7x7 each), intra mode dependent (with directional properties, fixed filters 7x7, 7x8, 8x8)
Co-located BL Motion vectors are scaled and block structure up-sampled and used for MV prediction in EL
EL skip mode, applied for the whole slice / picture
Edge enhancement filter (16 edge classes based on Canny edge detector) operated in EL loop (would likely also improve single-layer coding) EEF is not switched, always used (or switchable per slice?) (said to be best performing for Cactus and BQ Square)
Adaptive reference picture placement (position of inter-layer reference in the list)
Multi-pass encoding (3 passes at worst) for selecting filters

Highlights:
The picture level inter layer prediction tools:
selectable upsampling filters
intra mode dependent directional filters (IMDDF)
motion field mapping
enhancement layer skipped slice (actually, skipping the EL coding of the whole picture)
adaptive reference picture placement (can be an encoder-only trick)
The inter layer reference is then used together with the temporal reference pictures to predict the enhancement layer picture
Block level operations in the enhancement layer are the same as in single layer HEVC
Additional in-loop filter, called edge enhancement filter, applied at the picture level
The proponent suggested that the scheme is primarily an "MVC-like" approach to scalability

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6638" JCTVC-K0035 Description of scalable video coding technology proposal by Qualcomm (configuration 1) [Jianle Chen, Krishna Rapaka, Xiang Li, Vadim Seregin, Liwei Guo, Marta Karczewicz, Geert Van Der Auwera, Joel Sole, Xianglin Wang, Chengjie Tu, Ying Chen (Qualcomm)]
This proposal is Qualcomms response to the joint call-for-proposal on scalable video coding extension of HEVC issued by MPEG and ITU-T. The proposed solution is developed based on HM6.1 and the base layer coding is kept unchanged. Under multi-loop decoding framework, coding tools are proposed to improve the coding efficiency of the enhancement layer by utilizing base layer information, including reconstructed pixel samples.
Compared to HEVC simulcast, the luma BD-rate saving (based on actual total rate) is 25.6%, 33.5%, 23.0%, 31.1%, and 28.2 %, respectively, for all intra 2x, all intra 1.5x, random access 2x, random access 1.5x, and random access SNR cases.
The luma BD-rate saving (based on actual enhancement layer rate) is 36.7%, 55.5%, 33.0%, 50.2%, and 41.4 %, respectively, for all intra 2x, all intra 1.5x, random access 2x, random access 1.5x, and random access SNR cases.
Categories: All except hybrid
Fixed or adaptive filter (separable)
Intra prediction with DC modified in EL: Generated from up-sampled base
Intra residual prediction where up-sampled residual from base layer is added to the EL prediction signal
Same with inter residual prediction, but using weight 0, 0.5 or 1 in the addition (using same MV as in EL)
Inter-layer MV and CU split prediction
Intra mode from base layer in MPM list
Some changes in de-blocking
2 Additional transforms for Intra BL prediction (Each one DCT and DST types)
Scanning of 4x4 and 8x8 EL TBs based on gradient of reconstructed base layer (several experts comment: This could be dangerous in error propagation)
Several tricks in encoder optimization

Highlights:
Up-sampling filters: generate full EL resolution picture by up-sampling or filtering the reconstructed BL picture
Intra-BL prediction: uses collocated BL block to predict EL samples
Filtering of BL data is also applied for SNR scalability not just for spatial
EL DC mode uses average of collocated BL block
Inter-layer residual prediction: predicts EL prediction residues based on base layer information. This method is applied to both intra and inter CUs. A weighting factor of 0.5 can be applied to the residual prediction.
Inter-layer syntax prediction: employs BL syntax elements, such as CU-split, motion parameter, and prediction mode, to predict EL syntax elements.
Switchable DCT/DST: employs additional transforms (variations of DCT and DST types) to improve the transform efficiency of inter-layer predicted residues.
Encoder lambda selection to adjust for QP hierarchy relationship
In "high efficiency" variation (K0036), application of "multi-hypothesis" motion using MVs of base and enhancement layers.
In "high efficiency" variation (K0036), a combination of intra-BL and EL intra/inter prediction
In "high efficiency" variaiton (K0036), ALF
A participant remarked that the scan order deriviation would have a parsing dependency on decoded picture values which would have undesirable loss reslience behaviour.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6641" JCTVC-K0036 Description of scalable video coding technology proposal by Qualcomm (configuration 2) [Jianle Chen, Krishna Rapaka, Xiang Li, Vadim Seregin, Liwei Guo, Marta Karczewicz, Geert Van der Auwera, Joel Sole, Xianglin Wang, Chengjie Tu, Ying Chen]
In addition:
Inter prediction multi-hypothesis (4 references)
Combined prediction
Inferred base layer mode (signalling that
ALF
AMP
Yet another 2 transforms (DCT/DST types)
See notes in discussion of K0035.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6615" JCTVC-K0037 Description of scalable video coding technology proposal by ETRI and Kwangwoon Univ. [Jung Won Kang, Hahyun Lee, Jiho Lee, Jin Soo Choi, Jin Woong Kim, Junghak Nam, Hyomin Choi, Donggyu Sim]
This document describes the scalable video coding technology proposal by ETRI and Kwangwoon Univ. The proposal is based on multiple loop decoding process which fully reconstructs the picture of all the layers with motion compensation for each layer. The proposal is developed to support mainly spatial scalability and SNR scalability. However, it is reported that the proposal can be extended to support multi-view scalability and coding standard scalability because of multiple loop decoding structure.
The proposal contains tools for enhancement layer. For inter-layer texture prediction, the reconstructed picture of the reference layer is added into the reference picture lists L0 and L1 for the corresponding picture of the enhancement layer. The construction process and positions of merge/skip and motion vector prediction candidates are modified to consider the corresponding PU on the reference layer in ME/MC of the enhancement layer. DCT-IF filters are developed for up-sampling the reconstructed picture of the reference layer. In addition, ALF is applied to the enhancement layer.
For spatial scalability, compared to HEVC enhanced resolution single layer anchor, average BD-rate improvements are 28.8%(Y), 16.6%(U), and 15.2%(V) in case of spatial resolution of 2, and average BD-rate improvements are 44.8%(Y), 35.5%(U), and 33.3%(V) in case of spatial resolution of 1.5. For intra-only spatial scalability, compared to HEVC enhanced resolution single layer anchor, average BD-rate improvements are 35.0%(Y), 32.8%(U), and 32.5%(V) in case of spatial resolution of 2, and average BD-rate improvements are 52.0%(Y), 51.5%(U), and 51.6%(V) in case of spatial resolution of 1.5. For SNR scalability, compared to HEVC enhanced SNR single layer anchor, average BD-rate improvements are 37.2%(Y), 25.6%(U), and 22.2%(V).

Categories: All except hybrid
Multi-loop
Fixed upsampling filters, DCT-IF
Derivation of EL merge, skip and MV prediction candidates from BL
No mode inheritance for intra

The proposal is based on multiple loop decoding process which fully reconstructs the picture of all the layers with motion compensation for each layer.
Highlights:
The reconstructed picture of the reference layer is added into the reference picture lists L0 and L1 for the corresponding picture of the enhancement layer.
The construction process and positions of merge/skip and motion vector prediction candidates are modified to consider the corresponding PU on the reference layer in ME/MC of the enhancement layer.
DCT-IF filters are developed for up-sampling the reconstructed picture of the reference layer.
ALF is applied to the enhancement layer.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6616" JCTVC-K0038 Description of scalable video coding technology proposal by Texas Instruments [D.-K. Kwon, M. Budagavi, M. Zhou (TI)]
This proposal describes a tool for scalable extension of HEVC that was submitted in response to Joint Call for Proposals on Scalable Video Coding Extensions of High Efficiency Video Coding (HEVC). A CU-level inter-layer prediction tool is proposed under multi-loop scalable codec architecture. Base-layer pictures that are referred to by the enhancement layer are fully reconstructed. A CU in the enhancement layer is allowed to be predicted from the scaled base-layer reconstruction using a CU-level inter-layer prediction flag. All other coding tools in Main configuration of HM-6.1 HEVC are used for enhancement layer coding without modification. So the only changes on top of HEVC are asserted to be base-layer reconstructed picture up-sampling and inter-layer sample prediction at CU level. It is reported that for Category 1, the proposed tool provides BL + EL (actual rate) BD-rate gain of (Y: 23.6%, Cb: 21.5%, Cr: 21.8%), (Y: 32.2%, Cb: 31.3%, 31.5%), (Y: 16.5%, Cb: 6.5%, 5.9%), (Y: 25.5%, Cb: 17.8%, 16.5%) and (Y: 21.3%, Cb: 11.5%, 9.5%) for AI 2x, AI 1.5x, RA 2x, RA 1.5x and RA SNR scalabilities, respectively. For Category 2, it is reported that the proposed tool provides BL + EL (actual rate) BD-rate gain of (Y: 15.4%, Cb: 5.9%, Cr: 5.6%), (Y: 22.1%, Cb: 15.7%, Cr: 14.3%), (Y: 37.3%, Cb: 29.0%, Cr: 29.0%) and (Y: 43.8%, Cb: 39.5%, Cr: 37.8%) for HEVC 2x, HEVC 1.5x, AVC 2x and AVC 1.5x, respectively.
Categories: All
Multi-loop approach
Use of up-sampled BL as additional reference in EL (DCT-IF), signalled by a flag at CU level (except for skipped CU)
No inference of MV or modes
Document was updated on 10-09 with corrected to come closer to the target rate, slightly different (0.x% less gain) results (no new bitstreams uploaded)
It is pointed out by one expert that some RD graphs in the original contribution showed a strange behaviour, which seems to be fixed with the new data.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6519" JCTVC-K0039 Description of scalable video coding technology proposal by Intel [Y. Chiu, W. Zhang, L. Xu, Y. Han, Z. Deng, X. Cai, H. Jiang (Intel)]
This contribution presents a scalable video codec proposal from Intel in response to the Joint Call for Proposals on Scalable Video Coding Extensions of High Efficiency Video Coding issued by ISO/IEC JTC1/SC 29/WG 11 (MPEG) and ITU-T SG16 Q.6 (VCEG). This proposal is implemented in a multi-layered coding structure based on HM6.1 Reference software of HEVC coder, and the test result is provided for the scenario of SNR Scalability specified by the Call for Proposal. It contains a collection of inter-layer coding tools to improve the coding efficiency: inter-layer pixel prediction, inter-layer motion prediction, inter-layer residual refinement, inter-layer pattern/mode prediction and inter-layer refining filter. Together with the existing coding tool in HM 6.1, these inter-layer coding tools report the reduced-bit-rate bitstream under the RA_HEVC_SNR test configuration of Call for Proposal. The proposed tools achieve 36.3% BD-bitrate reduction on average on the EL-only actual rate testing case, 21.6% of BD-bitrate reduction on the EL-only target rate testing case, 20.5% of BD-bitrate reduction on the EL+BL actual rate testing case and 11.8% of BD-bitrate reduction on the EL+BL target rate testing case.
Category: SNR scalability
Multi-loop approach, single-loop constraint can be applied? (only for all-intra)
Inter-layer pixel prediction with refinement filter (7-tap 5x5 diamond shape / ALF-like)
Inter-layer residual refinement
Inter layer motion/mode/partition prediction
New inter layer skip and direct flags
Results indicate large deviation between actual rate and target rate calculations
Separate results reported on benefits of inter-layer motion prediction (4%) and partition prediction (5%).
At some data points, the target rate was violated

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6619" JCTVC-K0040 Description of scalable video coding technology proposal by Nokia (encoder configuration 1) [O. Bici, D. Bugdayci, A. Aminlou, A. Hallapuro, M. Hannuksela, J. Lainema, K. Ugur (Nokia)]
This document presents the details of the Nokia scalable video coding extension to HEVC technology (NSHEVC).
The main goal of the NSHEVC codec is to achieve scalability with high coding efficiency but with as small changes to HEVC design as possible. In order to achieve this, following HEVC tools are modified so that base layer information could be utilized to improve coding efficiency. Those tools could be summarized as:
Enhancing the temporal and spatial prediction using base layer samples.
Block based inter-layer prediction of samples.
Using base layer intra prediction mode and motion vectors in coding the enhancement layer.

NSHEVC software will be made available to interested parties to enable studying of developed algorithms in more detail.
An additional contribution is also submitted (JCTVC-K0047) using a longer GOP length for encoding the enhancement layer, whereas this contribution shows results using a GOP length of 8 (same GOP length as in base layer bitstreams). Other than this change in encoding structure, both proposals have identical tools and encoder configurations.

Categories: RA and AI SS
Multi-loop approach
Add base-layer component to EL prediction: Intra enhancement prediction based on BL gradient for hor/vert directions, the base layer DC is used to modify the EL prediction such that DC is the same.
For inter, similar method as in K0035 inter residual prediction (additional motion comp required, as it uses a scaled-down version of the enhancement layer MV)
Block based inter-layer prediction (use reconstructed BL samples as additional prediction reference, using the partitioning from BL) additional CABAC contexts
Re-use motion and intra mode info from BL to EL similar to other proposals, additional candidates from BL
K0040 uses same GOP structure as base layer, K0047 uses a different temporal hierarchy with longer GOP in enhancement

Highlights:
Enhancing the temporal and spatial prediction using base layer samples (somewhat similar in spirit to the difference-domain MC proposals in the temporal case)
Block based inter-layer prediction of samples.
Using base layer intra prediction mode and motion vectors in coding the enhancement layer.
In K0047 version, EL can have a different GOP structure than the base layer.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6620" JCTVC-K0047 Description of scalable video coding technology proposal by Nokia (encoder configuration 2) [O. Bici, D. Bugdayci, A. Aminlou, A. Hallapuro, M. Hannuksela, J. Lainema, K. Ugur (Nokia)]

See notes in discussion of K0040.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6583" JCTVC-K0041 Description of the scalable video coding technology proposal by Canon Research Centre France [S. Lasserre, F. Le Léannec, E. Nassor, J. Taquet, N. Ouedraogo, S. Pautet, C. Gisquet, G. Laroche, T. Poirier, Y. Verdavaine, E. François (Canon)]
This document describes Canons response to the Joint Call for Proposals for the scalable video coding extensions of HEVC. The proposed codec responds to the HEVC base layer categories of the CfP: Spatial, Intra-only and SNR scalability.
This document describes the coding tools added to HEVC coding tools for scalability: an inter-layer intra coding technology for intra frames and Inter-layer prediction tools for Inter frames.
In terms of coding efficiency, it is reported that the proposed codec shows scalable performance with a mean overhead of about 8.5% in All Intra configurations, 6.7% in Random Access spatial configurations and 3.1% in random Access SNR configuration compared to the monocast (single layer) HM6.1. Overall, a gain of 44.3% over the simulcast enhancement layer is obtained with the proposed scalability layer coding system. This corresponds to a gain of roughly 29% compared to the simulcast HM6.1, in the coding of the base plus the enhancement layer.
Categories: All except hybrid
Intra: Only use prediction from upsampled BL, no prediction from neighboring EL blocks
Model DCT coefficients by generalized Gaussian distribution, this is used to assign block types with similar RD slope and same quantizer
Non-uniform quantization with tables computed offline, around 500 tables
Post filtering in intra? DBF, SAO, ALF
Inter: base mode inter-layer prediction uses Intra BL like approach for intra PUs, motion vectors and partitioning, residual prediction, similar to AVC-SVC. (reported results do not refer to that configuration)
Partitioning inheritance uses 4x4 blocks in case of 1.5x, dyadic in case of 2x
Another advanced type of residual prediction requires multi-loop (re-computes residual from reconstructed base layer using enhancement layer MVs, similar to K0040)
AMVP uses 3 candidates (co-located base layer additionally)
ALF and IBDI also used in inter loop of EL
Results reported with 8-bit and 10-bit PSNR (latter approx. 1% better)

More TBA
For all-intra picture coding
Low complexity
Only one coding mode in EL: equivalent to I_BL mode
Selection among (about 500) R-D optimized quantizers (CLG design)
Non-adaptive entropy coding
For inter coding
Intra BL
General
EL bit depth increase

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6632" JCTVC-K0042 Description of scalable video coding technology proposal by Fraunhofer HHI (Configuration A) [H. Schwarz, C. Bartnik, P. Helle, T. Hinz, A. Khairat, H. Kirchhoffer, H. Lakshman, D. Marpe, M. Siekmann, J. Stegemann, K. Suehring, T. Wiegand]
This document describes the Fraunhofer HHI proposal as response to the Call for Scalable Video Coding Extensions of HEVC. The proposed coding scheme represents an extension of HEVC. It includes additional concepts for inter-layer prediction using already decoded or reconstructed base layer data. The proposal uses the same coding tools for both spatial and SNR scalability as well as for both AVC and HEVC base layers.
The proposal described in this document is similar to the proposal in JCTVC-K0043. The only difference is that the proposal described in this document does not include an adaptive loop filter for enhancement layer, while the proposal in document JCTVC-K0043 uses the adaptive loop filter as specified in version 6 of the HEVC draft. The bitstreams for both proposals have been generated using the same software.
Categories: All
Multi-loop
Upsampling filters for 1/16 pel phases (fixed)
Intra (could be used in EL also in cases where BL is inter): Upsampled BL, Upsampled and lowpass (121) filtered BL, EL intra prediction invoking residual from base layer, same with frequency weighting (done in DCT domain), prediction of intra prediction modes
Inter: Residual prediction (bilinear upsampling), Prediction based on BL/EL difference which is motion compensated afterwards (similar to K0031?), usage of BL MV as candidates in AMVP (extended list of candidates), merge (no extended list, but BL vector in 1st position), infer motion and CU partitioning
Additional hor and vert scans for 16x16 and 32x32 (not using 4x4 sub-blocks), different contexts
Modification of de-blocking filter (boundary strength) in EL
Selection of lambda in EL RDO depends on BL QP
ALF (0043) is better by around 1.5-2%
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6634" JCTVC-K0043 Description of scalable video coding technology proposal by Fraunhofer HHI (Configuration B) [H. Schwarz, C. Bartnik, P. Helle, T. Hinz, A. Khairat, H. Kirchhoffer, H. Lakshman, D. Marpe, M. Siekmann, J. Stegemann, K. Suehring, T. Wiegand]
TBA
See notes in discussion of K0042. This variant has ALF (12% benefit).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6591" JCTVC-K0044 Description of high efficiency scalable video coding technology proposal by Samsung and Vidyo [K. McCann, J. H. Park, J. Kim, C. Kim, J.-H. Min, E. Alshina, A. Alshin, I.-K. Kim, T. Lee, B. Choi, Y. Piao, S. Jeong, S. Lee, Y Cho, J. Y. Choi, F. C. A. Fernandes, Z. Ma (Samsung), J. Boyce, D. Hong, W. Jang, A. Abbas, S. Reddy (Vidyo)]
This proposal is a response to the Call for Proposals on Scalable Video Coding Extensions of High Efficiency Video Coding (HEVC), jointly produced by Samsung and Vidyo. It includes responses to all categories included in the CfP: spatial scalability, intra-only scalability, SNR scalability, and coded scalability. Comparing the scalable enhancement layer to the simulcast high resolution anchor, the proposal reports average luma BD-rate gains of 34.5% for RA HEVC 2x spatial scalability, 50.5% for RA HEVC 1.5x spatial scalability, 36.9% for All Intra HEVC 2x spatial scalability, 55.2% for All Intra HEVC 1.5x spatial scalability, and 41.2% for HEVC SNR scalability. For hybrid codec scalability with a base AVC layer, the proposal reports average BD-rate gains vs HEVC simulcast high-resolution anchors of 33.4% for 2x and 47.1% for 1.5x. Additional coding tools are proposed for the enhancement layer, which are claimed to exploit the texture, the motion information, and the intra prediction modes of the base layer. Other tools include modified deblocking filter, pixel-wise motion refinement for bi-prediction, additional motion compensation filter, inter-layer SAO, asymmetric motion partitions, TU based implicit delta QP, improved entropy coder and inter-layer Intra MPM. A lower complexity trade-off point for this coding framework is presented in the companion proposal described in JCTVC-K0045.
Categories: all
Multi-loop
Upsampling filters for 1/2 and 1/4 pel same as MC comp filters, new filters for 1/3 phases
Intra: Intra_BL mode and difference coding mode
Inter: Inter_BL mode (re-use MVs and compute residual) and difference coding mode (similar to Sharp and HHI)
MV prediction from BL when Inter_BL is not used
Modified de-blocking in EL
Inter-layer MPM
Inter-layer SAO
(following tools only in 044 not in 045)
AMP in EL (note: AMP is in main profile, but was not in BL streams which were using HM6.1 style main profile)
Bi-directional optical flow
Implicit dQP refinement
ALF in EL

Highlights:
Intra_BL mode
Intra_BL Skip mode
Inter_BL mode
Difference mode
Bilinear MC filter for difference mode
Deblocking filter consideration of difference mode
Inter-layer spatial MPM prediction
Inter-layer MV prediction
Inter-layer SAO
Bi-directional optical flow
Multi-parameter probability estimation in enhancement layer CABAC
Asymmetric motion partitions in enhancement layer
TU-based implicit dQP refinement
Adaptive loop filter in enhancement layer

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6614" JCTVC-K0045 Description of low complexity scalable video coding technology proposal by Vidyo and Samsung [J. Boyce, D. Hong, W. Jang, A. Abbas, S.Reddy(Vidyo), K. McCann, J.-H. Park, J. Kim, C. Kim, J.-H. Min, E. Alshina, A. Alshina, I.-K. Kim, T. Lee, B. Choi, Y. Piao, S. Jeong, S. Lee, Y. Cho, J.Y. Choi (Samsung)]
(include abstract)
See notes in discussion of K0044.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6650" JCTVC-K0046 Description of scalable video coding technology proposal by Huawei Technologies [H.Yang, J. Zan, X. Wei, W. Gao, H. Yu (Huawei), L. Li, J. Zhang, B. Li, H. Li (USTC), L. Feng (USC)]
This contribution proposes a video coding solution that will add spatial scalability feature to the design of HEVC. The proposed solution uses HEVC to encode the base-layer and consists of inter-layer texture prediction, inter-layer mode prediction, inter-layer texture skip mode, etc., and these tools are developed jointly by Huawei and University of Science and Technology of China. In average, the proposed HEVC scalable solution can achieve 27.5% BD rate saving when comparing the enhancement layer only bitstreams vs the simulcast HEVC SVC CfP Category 1 (HEVC base layer) anchor bitstreams, and 18.2% BD rate saving when comparing the combined scalable base and enhancement layer bistreams vs. the same set of simulcast HEVC anchor bitstreams.
Category: RA SS
Multi-loop
Upsampling uses DCT-IF
Inter-layer texture pred (prediction from up-sampled base layer reconstruction)
Inter-layer texture skip (use prediction from base layer, no residual)
Inter-layer motion (AMVP/merge/skip); padding is used when no MV is available; base layer candidate added to merge candidate list. AMVP with BL and one more (spatial/temporal/zero) cand.
Inter-layer intra mode
EL deblocking filter modified (strength)

Highlights:
inter-layer texture prediction
inter-layer texture skip
inter-layer motion copy
scalable extension of merge and AMVP
inter-layer intra mode copy

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6628" JCTVC-K0049 Description of scalable video coding technology proposal by Ghent University IBBT [Glenn Van Wallendael, Sebastiaan Van Leuven, Jan De Cock, Rik Van de Walle] [late]
This document provides a description of the scalable video coding technology proposal by Ghent University IBBT. This submission is a response to the CfP in category 1 (intra-only, spatial, and SNR scalability). The proposed technology extends HEVC with scalable enhancement layer coding; inter-layer prediction for motion, residual, and pixel data is used to exploit redundancy between the layers. The design is closely bound to single-layer HEVC, and tries to reuse as many building blocks from the single-layer specification as possible. As such, hardware or software implementation is facilitated. Average BD-rate luminance gains are reported of 42.7% (AI, 1.5x), 33.0% (RA, 1.5x) and 35.8% (RA, SNR).

Categories: All except hybrid
Multi-loop approach
Inter-layer pixel prediction: Upsampling filter as in AVC-SVC (4-tap/2-tap)
Inter-layer residual prediction: Bilinear upsampling
Inter-layer motion prediction: Add BL MV to merge candidate list
No results for 2x upsampling
Bitrate constraints were violated in some cases

Highlights:
Inter-layer sample prediction (upsampling as in SVC)
Inter-layer residual prediction (bilinear upsampling)
Inter-layer motion prediction (BL candidate included in merge list)
It was remarked that some bit rate constraints were not met by the proposal, and some test cases were not reported.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6663" JCTVC-K0052 Description of scalable video coding technology proposal by KDDI [K. Kawamura, T. Yoshino, S. Naito (KDDI)]
This contribution is the KDDIs response to the Joint Call for Proposals on Scalable Video Coding Extensions of High Efficiency Video Coding (HEVC), jointly issued by ITU-T SG16 Q.6 (VCEG) and ISO/IEC JTC1/SC29/WG11 (MPEG). The goal of this contribution is to provide scalable video coding extensions of HEVC which has significantly higher compression capability than the state-of-the-art H.264/AVC standard, especially for high-definition (HD) video contents. A further goal is to obtain these gains with minimal increase in complexity over HEVC. To achieve these goals, three modified tools are proposed covering several aspects of scalable video coding technology. These include inter-layer intra prediction, inter-layer prediction mode and motion prediction, and inter-layer residual prediction. When all the proposed tools are used, the proposed scalable video codec achieve approximately 28% and 46% bit-saving on average compared to HEVC single layer in both RA x2.0 and RA x1.5 configurations.
Categories: All except SNR
No MC in base layer
Use up-sampling filters from AVC-SVC
No inference of CU partitioning
Intra_BL like
Inter-layer motion prediction (up-scaling)
Extend merge candidate list to 6
Extend AMVP candidate list to 3
Inter-layer intra mode prediction
Inter-layer residual prediction

Highlights:
inter-layer intra prediction
inter-layer prediction mode and motion prediction
inter-layer residual prediction
encoding technique for lambda value adjustment
Single loop? Yes.

General
As a starting basis, we will assume a multi-loop design with inter-layer texture prediction. (Multi-loop could be an issue with multiple layers of SNR scalability.)
There is a desire to start with a simple extension of the HM with a minimal set of enhancements, and build and refine from there using the CE process.
One suggestions was a "high-level-syntax-only" "MVC-like" approach, where the BL picture is simply upsampled and becomes an additional reference frame in the DPB that is available for referencing.
An alternative suggestion was to have only CU-based upsampling (sort of like the preceding case restricted to zero motion vectors).
Elements of SVC that were included in several proposals:
Upsampling of intra samples
MV prediction
Residual prediction
Some things beyond SVC that have been suggested:
Upsampling of inter samples (multi-loop)
MC in difference domain
Inter-layer SAO
Inter-layer intra mode prediction

First conclusions for starting basis:
Multi-loop design, enabling temporally-collocated inter-layer texture prediction for regions coded either as intra or inter in the base layer
Hybrid/multi-standard base layer capability
Things to study, and to provide software "hooks" for in the software:
Inter-layer residual prediction (e.g. as in SVC est. 02% benefit relative to "first conclusions" above)
Inter-layer motion/mode prediction
It was remarked that whether some features are used may depend on the base layer type, or on profile constraints.
It was noted that we do not currently actually have tool-by-tool benefit estimates.
It was remarked that in multi-standard case, it may be difficult to provide the hooks for inter-layer residual and inter-layer motion/mode prediction (unless a common HRD is designed).
It was noted that there is the potential to have different profiles of a standard

The version of the software to be used as the basis of further work was discussed (HM 6.1 vs. HM 8.1 vs. HM 8.2 vs. HM 9). Revisit.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6754" JCTVC-K0345 Suggested design of initial software model for scalable HEVC extension proposal by Fraunhofer HHI, Vidyo and Samsung [T. Wiegand, H. Schwarz, C. Bartnik, P. Helle, T. Hinz, A. Khairat, H. Kirchhoffer, H. Laksman, D. Marpe, M. Siekmann, J. Stegemann, K. Sühring (HHI), K. McCann, J. H. Park, J. Kim, C. Kim, J.-H. Min, E. Alshina, A. Alshin, I.-K. Kim, T. Lee, B. Choi, Y. Piao, S. Jeong, S. Lee, Y Cho, J. Y. Choi, F. C. A. Fernandes, Z. Ma (Samsung), J. Boyce, D. Hong, W. Jang, A. Abbas, S. Reddy (Vidyo)] [late]
This proposal provides a suggestion for an initial software model for the scalability extension of HEVC. It was based on merging subsets of the software implementations from Fraunhofer HHI, Samsung and Vidyo.
Some principles reportedly followed for developing this proposal:
All test cases have reportedly been verified by the source software implementations (HEVC-BL and AVC-BL)
Only inter-layer coding tools for improved enhancement layer coding efficiency are included
All suggested tools were proposed in a large number of responses to the CfP
Multi-loop decoding design is assumed
The software reporedtly has high commonality with the regular single-layer HM software, and can be merged and maintained with it.
The following inter-layer tools were suggested in the contribution:
Upsampling of reconstructed BL samples (i.e. Intra_BL mode)
Inter-layer motion and partition prediction
Difference-domain inter prediction mode (coding the difference between EL and coded BL)
The first item above has the largest gain. Some participants suggested only including this item as a starting basis.
A participant suggested not having one particular proposal's variant of the 2nd and 3rd topic features.
It is emphasized that bullets 2 and 3 are meant as example hooks for further experimentation and this does not mean establishing a test model these aspects could also be drawn from other proposals
Disciussion/opinions/suggestions expressed by other experts:
Start only with high-level syntax
Only with bullet 1 as starting point
Data for detailed benefit of the single tools in any proposals are not available
Most of the gain (approx. 20%) comes by multi-loop with colocated-base-to-enhancement texture reference (which could become the basis of a first test model, with upsampling filters and the way how to perform the prediction from BL to be defined)
Benefits of other suggested tools (including bullets 2 and 3 above) to be investigated in CE.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6757" JCTVC-K0348 A proposal for Scalable HEVC Test Model [K. Ugur(Nokia), E. Nassor (Canon), J. Chen (Qualcomm), B. Jeon (LGE), S. Lei (Mediatek), A. Segall (Sharp), M. Zhou (TI), Y. Ye (InterDigital), A. Tabatabi (Sony), J. W. Kang (ETRI)] [late]
It is observed that the responses to the Scalable HEVC extension share the following characteristics:
Many tools are identical or very similar in spirit.
Coding efficiency results are quite close to each other.
Almost all the proposals are multi-loop and implemented on top of HM6.1
Based on these observations, the contributors proposed to start with an initial test model as follows and define CEs on top of that software.
Inter-layer texture prediction as described in K0038
Software has interface to access information from base layer, such as:
Motion field (motion vectors, reference indexes)
CU/TU partitions
Intra mode information
Base layer reconstructed samples (upsampled to enh. layer reconstruction)
Base layer reference pictures (upsampled to enh. layer reconstruction)
Define Tool/Core Experiments on top of the above software
Define Experimental Framework that compares performance of Scalable extensions with the following:
Texture-only tools (not using base layer modes and motion vectors)
High Level Syntax only changes ("MVC-like" approach)
BoG (A. Segall) to
Provide a summary about the various proposals in terms of performance, tools included, etc.
Study suggested software starting points investigating whether any of the suggested software frameworks fulfills the needs for further experimentation e.g. in providing suitable hooks for inter-layer motion/mode/partition coding, inter-layer processing, EL difference coding etc.
Whether the hooks are empty or are equipped with meat needs further discussion.
The status of the BoG work was discussed on Friday morning. Additional topics mentioned included checking provided bitstreams and informal viewing. A participant suggested to focus on the lowest rate point(s) for viewing.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6755" JCTVC-K0346 Summary of tools and performance of scalable video coding technology proposals [P. Lai, T.-D. Chuang, S. Liu, Y.-W.Huang, S. Lei (MediaTek), E. Nassor, E. Francois, F. Le Leannec, P. Onno (Cannon), C.-K. Kim, B.-M. Jeon, J.-Y. Park (LG), J. Chen, X. Li (Qualcomm)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6758" JCTVC-K0349 Summary and performance comparison of scalable coding CfP responses [T Wiegand, H Schwarz, H Kirchhoffer, H Lakshman] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6761" JCTVC-K0352 Summary of CfP results on scalable video coding technologies [J. Lainema, K. Ugur (Nokia)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6766" JCTVC-K0357 Comments on Suggested Initial Software Models [J. Chen (Qualcomm), K. Ugur (Nokia), E. Nassor (Canon), M. Zhou (TI), B. Joen (LGE), S. Lei (Mediatek), Y. Ye (InterDigital), A. Tabatabai (Sony), H. Yu (Huawei), Y. Chiu (Intel), K. Kawamura (KDDI), J.W. Kang (ETRI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6772" JCTVC-K0362 Canon proposal for initial software model for scalable HEVC [S. Lasserre, F. Le Léannec, E. Nassor, J. Taquet, N. Ouedraogo, S. Pautet, C. Gisquet, G. Laroche, T. Poirier, Y. Verdavaine, E. François, P. Onno (Canon)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6773" JCTVC-K0363 Study of Software Model for Scalable HEVC Extension in JCTVC-K0345 [P. Lai, S. Liu, S. Lei (MediaTek)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6774" JCTVC-K0364 A suggested initial software model for HEVC scalable video coding [J. Chen, K. Rapaka, X. Li, V. Seregin, L. Guo, M. Karczewicz, G. Van der Auwera, J. Sole, X. Wang, C. J. Tu, Y. Chen (Qualcomm)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6776" JCTVC-K0366 Proposal of scalable HEVC initial test model [Y. Ye (InterDigital), A. Fuldseth (Cisco), P. Yin (Dolby), C. Cui (ASTRI)] [late]

Other
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6477" JCTVC-K0107 Simplification of differential coding in JCTVC-K0033 [X. Zhang, S. Liu, M. Guo, Z. Chen, T.-D. Chuang, Y.-W. Huang, S. Lei (MediaTek), C. Kim, J. Park, J. Kim, Hendry, B. Jeon (LG)]
Inter-layer difference-domain predictive coding has been proposed as a coding tool in JCTVC-K0033 to respond to the Call for Proposals (CfP) on Scalable Video Coding Extensions of High Efficiency Video Coding (HEVC). This contribution proposes to simplify the inter-layer differential coding as follows. When the inter-layer differential coding mode is selected, bi-prediction, multiple reference pictures, and intra NxN partitions are disabled. It is reported that when JCTVC-K0033 is used as the anchor, encoding time reductions of 1/10 short length test are 18.9%, 17.4%, 12.4%, 11.4%, and 14.1% for RA-2x, RA-1.5x, AI-2x, AI-1.5x, and RA-SNR, respectively, and the corresponding EL-only actual rate BD-rates are 0.06%, 0.22%, "0.01%, "0.02%, and "0.08%.
Still requires additional motion compensation.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6546" JCTVC-K0175 On inter-layer prediction enabling/disabling for HEVC scalable extensions [K Sato (Sony)]
This document contains two topics on inter-layer prediction for HEVC scalable extension as follows:
Topic #1: Inter-layer Prediction and Temporal-layer Depth
In HEVC scalable extension inter-layer prediction enabling/disabling will be associated with trade-off between coding efficiency and complexity: it will improve coding efficiency but will cause increase in complexity.
With lower temporal layers distance in time domain between the current and reference frames are rather long and performance of inter-frame prediction is not so high. In this case more CUs are coded as intra, and with scalable extension, inter-layer prediction will improve coding efficiency.
Therefore this contribution proposes to have some inter-layer prediction on/off mechanism in association with temporal layer depth.
Topic #2: Consideration on Hybrid-codec Scalability and Inter-layer Prediction
In the CfP document of HEVC scalable extensions, experiment of codec standard scalability (Base-layer: AVC, Enhancement-layer: HEVC) is included as an option. In addition, it is proposed by the proposal m25749 that H.262/MPEG2-HEVC scalability be supported with BLR (Base-Layer Reconstructed samples). It might be possible that a proprietary codec be also included in hybrid-codec scalable bitstreams.
It was suggested that HEVC version 2 will have flexibility that any layer can be any codec_type, but the problem is that scalability like H.262/MPEG2-AVC does not exist in the past codec standard.
This contribution proposes to restrict the considered combinations of hybrid-codec scalability for inter-layer prediction.

About topic #1: Contains proposal for VPS in scalable coding which could be further considered in REF _Ref337733259 \r \h \* MERGEFORMAT 5.16.10. It is however unclear whether the intention would rather be a general restriction in profile/level than signaling in VPS
About topic #2: Configurations like the ones denoted as undesirable (like MPEG-2 AVC HEVC scalability) have not been suggested so far. Are these cases realistic?

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6617" JCTVC-K0238 Inter-layer intra prediction mode coding for the scalable extension of HEVC [Zhijie Zhao, Junyong Si, Joern Ostermann (Leibniz Univ. Hannover)]
This contribution presents two approaches for the inter-layer intra coding of the scalable extension of HEVC. In the scalable extension of H.264/AVC, inter-layer intra prediction (ILIP) is used to reduce the redundancy between two spatial layers of intra pictures. Except the blocks coded using ILIP, other blocks are coded as a single layer coding. In this contribution, two approaches are proposed to utilize the base layer intra prediction mode to improve the coding efficiency of the CUs not being coded by ILIP in the context of the scalable HEVC coding. The first approach directly utilizes the intra prediction mode from the corresponding base layer PU as the intra prediction mode of the enhancement layer PU, while the second approach uses the intra prediction mode of the corresponding base layer PU as an additional MPM candidate. ILIP and the two proposed approaches are implemented based on HM 6.1. The implemented scheme achieves an average luma BD-rate reduction of 31.9% for class B sequences relative to the simulcast high resolution reference used by Joint Call for Proposals on Scalable Video Coding Extensions of High Efficiency Video Coding in dyadic all intra spatial scalability. Explicit signalling that the intra mode of BL is re-used in EL is used (rather than using it as additional MPM which was also investigated). Relative to Intra_BL, about 0.3% average bit rate reduction was reported by the proposed techniques.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6622" JCTVC-K0241 Gamut Scalable Video Coding [L. Kerofsky, A. Segall (Sharp)]
This document proposes a scalable extension for HEVC that supports different color gamuts in enhancement and base layers. Here, the emphasis is on supporting the UHDTV (BT.2020) color gamut in an enhancement layer and the BT.709 color gamut in a base layer. This is motivated by a need to support both HD and UHDTV devices in the near future. The document proposes a color gamut prediction tool for converting between BT.709 and BT.2020 with a series of multiplies and adds, while also accounting for a change in bit depth.
The proposal uses a linear mapping (configurable offset and slope) for approximate conversion between BT.709 and BT.2020 in the inter-layer prediction for spatial scalability from HDTV to UHDTV.
Experimental results were obtained by artificially producing different color formats in base and enhancement layers.
In one case better than single layer for one of the color channels (likely due to better quantization that is in effect due to the mapping)
The color prediction mapping is suggested to be signalled by a flag, not dependent on VUI parameters
Several experts express that this is an interesting feature
Could be interesting to investigate other methods of mapping (matrix, LUT) to make it more generic
One expert points out that the suggested approach could be interpreted as weighted prediction in the inter-layer prediction (which would not fully reflect the bit-depth conversion)
The contributor proposed study of the color space prediction tool in a core experiment.
It was remarked that if the upconverted base layer is used as a reference frame, weighted prediction is a way to accomplish this and that this simple variation of the technique should be a candidate for study of this topic.
Further study (CE now or later)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6652" JCTVC-K0264 Hierarchical inter-layer prediction in multi-loop scalable extension of HEVC [D.-K. Kwon, M. Budagavi, M. Zhou (TI)]
Multi-loop scalable HEVC is asserted to be easier to extend from single-layer HEVC from an architecture point of view when compared to single-loop scalable coding. However, multi-loop coding increases memory bandwidth at decoder side. In this contribution, it is proposed to signal in the NAL unit header whether a picture is used as a reference for next layers and as a temporal reference for other pictures that are referred to by next layers. In intermediate layers, the pictures not being used as references for next layers can be discarded without decoding, which reduces memory bandwidth in decoder. Moreover, only the pictures being used as temporal references for other pictures that are referred by next layer need to be stored, which reduces DPB size as well in decoder. When inter-layer prediction is enabled for the half number of pictures (instead of being enabled for all pictures) in enhancement layer, it is possible to save memory bandwidth necessary for temporal prediction and inter-layer prediction by half. The proposed method is implemented on top of JCTVC-K0038. It is reportedly shown that BL + EL (actual) BD-rate losses are only 1.4%, 2.2% and 1.7% for RA 2x, 1.5x and SNR scalabilities, respectively, when compared to JCTVC-K0038. It is reportedly shown that the proposed method still provides BL + EL (actual) BD-rate gains of 15.3%, 23.6% and 19.6% for RA 2x, 1.5x and SNR scalabilities, respectively, over Simulcast.
Proposes two flags to be put into the NUH:
Whether the picture may be referred to by an EL
Whether the picture may be referred to by some picture in the BL that is referred to by an EL.
nal_ilp_flag and nal_ilp_ref_flag are proposed which signal whether pictures of a lower layer are used for inter-layer prediction (co-located or temporal reference)
Comments: Rather not use the reserved bits in NAL unit header; the suggested method may not be generic enough compared to concepts that were discussed in context of HL syntax (flags in slice header). Further study is required in the whole area to determine what the best use of any of these flags should be.
See notes for K0210. The reserved flags can be used for this purpose although they are in the SH instead of in the NUH.
It was asked whether the second proposed flag is really needed given the various other ways that we have to indicate reference picture storage requirements.
Further study was encouraged regarding how to use these bits.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6716" JCTVC-K0321 Transform Selection for Inter-Layer Texture Prediction in Scalable Video Coding [L. Guo, M. Karczewicz, J. Sole, J. Chen (Qualcomm)] [late]
This describes a variation of a feature proposed in K0035.
In this contribution, multiple transforms are proposed to be used for coding the luma component of inter-layer texture prediction residues. The encoder would select a transform from among multiple candidates and signal its selection. All the candidate transforms can reportedly be implemented by reusing the partial butterfly structure in HM software. Experimental results reportedly show luma BD-rate reductions of 1.6% and 1.3% for AI-2X and AI-1.5X, respectively (BD-rate calculated using both enhancement layer and base layer rates) when using this technique with two additional transforms.
Refers to K0035 (which has 3 additional transforms), but reports another result with only two transforms where the gain is 1% and 0.9% for AI-2X and AI-1.5X.
The gain with RA cases is lower.
No action at this point. Further study was encouraged.
Extended colour component sampling
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6503" JCTVC-K0133 AHG7: Full-chroma (YUV444) dictionary+hybrid dual-coder extension of HEVC [Tao Lin, Shuhui Wang, Peijun Zhang, Kailun Zhou (Tongji U)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6504" JCTVC-K0134 AHG7: HM software implementation and source code for JCTVC-K0133 [Peijun Zhang, Tao Lin, Xianyi Chen, Xiaojuan Jin (Tongji U)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6729" JCTVC-K0329 Cross-check of JCTVC-K0133 ( dictionary+hybrid dual-coder extension of HEVC) [M. Budagavi (TI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6542" JCTVC-K0171 AHG7: Transforms for extended chroma formats [C. Rosewarne (CiSRA), M. Maeda (Canon)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6744" JCTVC-K0338 AHG7: Cross-verification of JCTVC-K0171, Transforms for extended chroma formats [R. Cohen (Mitsubishi)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6552" JCTVC-K0181 AHG7: Options present in Extended Chroma Format model [K. Sharman, N. Saunders, J. Gamei (Sony)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6561" JCTVC-K0190 On luma-chroma mode support [K. Kawamura (KDDI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6565" JCTVC-K0194 Crosscheck of luma-chroma mode support (JCTVC-K0190) [S. Matsuo, M. Matsumura, H. Fujii, S. Takamura, A. Shimizu (NTT)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6562" JCTVC-K0191 Inter-plane intra coding [K. Kawamura (KDDI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6566" JCTVC-K0195 Crosscheck of inter-plane intra coding (JCTVC-K0191) [S. Matsuo, M. Matsumura, H. Fujii, S. Takamura, A. Shimizu (NTT)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6563" JCTVC-K0192 Chroma coding structure [K. Kawamura (KDDI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6567" JCTVC-K0196 Crosscheck of chroma coding structure (JCTVC-K0192) [S. Matsuo, M. Matsumura, H. Fujii, S. Takamura, A. Shimizu (NTT)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6564" JCTVC-K0193 Colour-space transformation [ HYPERLINK "mailto:ki-kawamura@kddi.com" K. Kawamura (KDDI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6569" JCTVC-K0198 Crosscheck of colour-space transformation (JCTVC-K0193) [S. Matsuo, M. Matsumura, H. Fujii, S. Takamura, A. Shimizu (NTT)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6582" JCTVC-K0211 AHG7: Colour Spaces and Chroma Sampling Methods [Pankaj Topiwala, Wei Dai, Madhu Krishnan (FastVDO)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6637" JCTVC-K0253 AHG7: performance of extended chroma mode for non 4:2:0 format [J. Kim, B.Jeon (LGE)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6738" JCTVC-K0333 Cross-check of extended chroma mode for non 4:2:0 format (JCTVC-K0253) [K. Kawamura, T. Yoshino, S. Naito (KDDI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6692" JCTVC-K0302 AHG7: On processing 4:2:2 chroma format [A. Gabriellini, M. Mrak (BBC)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6705" JCTVC-K0312 AHG7: Cross-verification of JCTVC-K0302, On processing 4:2:2 chroma format [R. Cohen (MERL)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6717" JCTVC-K0322 AHG7: Comments on 422 and 444 coding tools and software [R. Joshi, G. Van Der Auwera, J. Sole, M. Karczewicz (Qualcomm)] [late]

Higher bit-depth
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6479" JCTVC-K0109 On 10 bit Profile on High efficiency video coding (HEVC) [Alberto Duenas (NGcodec)]

Interlaced scan and field-based video coding
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6516" JCTVC-K0146 Comments on Coding and Display Formats [W. Wan, B. Heng, W. Ahmad (Broadcom)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6524" JCTVC-K0153 Coding of Interlaced Video with HEVC [C. Auyeung (Sony)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6722" JCTVC-K0326 Cross-check report for GOP structures for interlaced video (low delay) (JCTVC-K0153) [K. Terada, H. Sasai (Panasonic)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6712" JCTVC-K0317 Cross-check of GOP structures for interlaced video (JCTVC_K0153) [D. Baylon (Motorola Mobility)] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6529" JCTVC-K0158 AVC and HEVC coding efficiency of deinterlaced sequences [K. Slavin, C. Fogg (??)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6531" JCTVC-K0160 Field indication metadata [C. Fogg, P. Haskell, O. Bar-Nir, A. Wells, D. Le Gall (??)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6536" JCTVC-K0165 Results of frame sequences vs. field sequences for film content [O. Bar-Nir, C. Fogg (??)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6588" JCTVC-K0216 HEVC interlaced coding assessment and Chroma issue consideration [ HYPERLINK "mailto:jm.thiesse@ateme.com" Jean-Marc Thiesse, HYPERLINK "mailto:j.vieron@ateme.com" Jérôme Viéron, HYPERLINK "mailto:p.larbier@ateme.com" Pierre Larbier (??)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6600" JCTVC-K0226 Confidence level and mixed-content indicators for field indication SEI message [G. J. Sullivan, Y. Wu (Microsoft)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6633" JCTVC-K0250 Coding interlaced video using sequence-adaptive field-frame [D. Hoang (Zenverge), J. Xin (Zenverge)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6713" JCTVC-K0318 Cross-check of coding interlaced video using sequence-adaptive field-frame (JCTVC-K0250) [D. Baylon (Motorola Mobility)] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6720" JCTVC-K0325 Picture Adaptive Frame/Field Coding for HEVC [Raul Lopez, Arianne Hinds (??)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6733" JCTVC-K0331 HEVC performance evaluation on interlaced video sequences [K. Sugimoto, A. Minezawa, S. Sekiguchi, M. Murakami (Mitsubishi)] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6762" JCTVC-K0353 HEVC encoding of deinterlaced sequences: a preliminary study [Agyo Zineb, Jérôme Vieron, Pierre Larbier, Jean-Marc Thiesse (Ateme)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6770" JCTVC-K0360 Need to code Intra pictures of progressive source as two fields [A. Rodriguez (??)] [late]

Deblocking filter
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6500" JCTVC-K0130 Support of weighted prediction in the HEVC deblocking filter [A. Tourapis (Apple)]
This contribution presents some asserted shortcomings of the HEVC deblocking filter process and suggests methods for their resolution. In particular, it is asserted that the HEVC deblocking filter does not properly consider the presence of weighted prediction during the deblocking filter strength derivation.
The first suggested modification likely introduces additional problems in deblocking across slices.
The second suggested solution (enabling BS1 when different weighting parameters are used at block boundary) was not tested, as this case does not appear in CTC.
A benefit was not clearly demonstrated.
No support was expressed by other experts.
No need for current action further study is requested; there is a need to show evidence.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6704" JCTVC-K0311 Cross-check of JCTVC-K0130 Method A [J. Xu, C. Auyeung (Sony)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6508" JCTVC-K0138 Non-CE1: Deblocking of Large Block Artifacts [G. Van der Auwera, R. Joshi, M. Karczewicz (Qualcomm)]
Was presented in BoG JCTVC-K0342.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6485" JCTVC-K0115 Crosscheck for JCTVC-K0138 - non-CE1:Deblocking of Large Block Artifacts [P. Kapsenberg (Intel)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6714" JCTVC-K0319 Cross-check of deblocking of large block artifacts in JCTVC-K0138 [D.-K. Kwon, M. Budagavi (TI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6521" JCTVC-K0150 NonCE1: Simple improvement of Deblocking filter [S. Lu, O. Nakagami, T. Suzuki (Sony)]
Was presented in BoG JCTVC-K0342.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6556" JCTVC-K0185 Crosscheck for JCTVC-K0150 [T.K. Tan (NTT Docomo)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6715" JCTVC-K0320 Cross-check of simple improvement of deblocking filter in JCTVC-K0150 [D.-K. Kwon, M. Budagavi (TI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6594" JCTVC-K0220 Use of Chroma QP offsets in Deblocking [S. Kanumuri, G. J. Sullivan (Microsoft)]
This contribution proposes that the effect of chroma QP offsets be taken into account when determining the parameter tC for the deblocking filtering of chroma components. It is asserted that the current derivation of this parameter in the current HEVC design does not properly reflect the actual QP used for chroma when non-zero QP offsets are used. At the preceding JCT-VC meeting of July 2012 in Stockholm, some concern was expressed about the complexity impact of using the chroma QP offsets, due to the potential need to store the chroma QP offset values on a CTU basis. This contribution asserts that this complexity impact is relatively small and thus does not necessarily justify the current design. However, this contribution also suggests that if that complexity impact is considered important, a compromise approach that accounts for picture-level chroma QP offsets without applying the slice-level QP offsets would eliminate that memory requirement and provide better performance than the current scheme of completely ignoring the chroma QP offset values in the deblocking filter process.
Comments:
Chroma deblocking is simplified anyway, as it is practically only performed if one of the sides of the boundary is intra-coded what would be the benefit?
Could be relevant in extreme deviations between luma and chroma QP.
Relevant for 4:2:2/4:4:4? More likely a re-design of chroma deblocking would be needed.
Unclear whether picture level QP offset would be used much in practice.
Why do we need different offsets for luma and chroma.
Decision: Adopt solution B (picture- based chroma QP offset adjustment).
(Experts from 3 independent companies expressed support for the idea, and no objections were heard about the additional addition in the chroma deblocking.)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6605" JCTVC-K0230 Non-CE1: Simplification of strong filter decisions in CE1 deblocking [M. Ikeda, A. Tabatabai, T. Suzuki (Sony)]
Was presented in BoG JCTVC-K0342, this is a simplification of test 4 and could be relevant once that would be adopted.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6700" JCTVC-K0307 Cross-check of K0230 [A. Norkin (Ericsson)] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6657" JCTVC-K0269 Non-CE1: Suppression of blocking artifacts at large TU boundaries [D.-K. Kwon, M. Budagavi (TI)]
Was presented in BoG JCTVC-K0342.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6665" JCTVC-K0275 Cross check of Suppression of blocking artifacts at large TU boundaries(JCTVC-K0269) [S. Lu, O. Nakagami (Sony)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6679" JCTVC-K0289 Non-CE1: improvement to deblocking filtering [A. Norkin (Ericsson)] [late]
Was presented in BoG JCTVC-K0342.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6701" JCTVC-K0308 The crosscheck for deblocking filtering improvements suggested in JCTVC-K0289 [E. Alshina (Samsung)] [late]

Sample adaptive offset
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6527" JCTVC-K0156 SAO encoder selection bug fix [E. Alshina, A. Alshin, J. H. Park (Samsung), P. Onno, G. Laroche, C. Gisquet (Canon)]
This contribution is about a correction of a SAO encoder bug which was introduced during the integration of J0044 in HM8.0. J0044 was about the addition of a new threshold for the Chroma component for the decision to switch on/off the SAO process at the slice level. The bug fix is a two-line modification in the HM8.0 encoder and does not affect the coding efficiency performance. In addition, it is asserted that the bug fix speeds-up the HM8.0 encoder and in average reduces the amount of bins to parse.
Does not give any advantage but makes the decision more logical
Decision (SW): Adopt
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6653" JCTVC-K0265 About an order of SAO syntax elements [E. Alshina, A. Alshin, J. H. Park (Samsung)]
This contribution is about changing the order of SAO syntax elements which allows reduction for conditions check both in specification text and s/w. There is no performance change due to suggested modification.
No action
(note this proposal would have been welcome at the last meeting to simplify the syntax and save some lines of text, but several experts express opinion that stability has higher importance now proposal changes sequence of syntax elements; there may also be other ways to implement the existing syntax without additional condition checks e.g. by unrolling the loop).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6695" JCTVC-K0305 Cross-check report for Samsung's SAO syntax order change (JCTVC-K0265) [J. Lou, K. Minoo (Motorola Mobility)] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6656" JCTVC-K0268 AHG6: SAO offset coding [I. S. Chong, J. Sole, M. Karczewicz (Qualcomm)]
In HM8.0, SAO offsets are coded using truncated unary binarization with all bins being bypass-coded. The maximum offset value depends on the internal bit-depth: ranges 0~7/0~15/0~31 are allowed for 8/9/10 or higher bit-depth, respectively. Therefore, the worst-case number of bypass-coded bins per offset is 7/15/31 bins with TU binarization. Considering that a total of 12 offsets are sent per LCU, the worst-case is allegedly too large in the current design. We propose a different binarization to reduce the worst number of bins to 5/7/9 for bit-depth 8/9/10 or higher, respectively, coding all bins in bypass and without coding performance loss on average.
Comments: Is this critical? Several experts mention that this is a minor problem (if at all). Stability has highest importance. No action.
(related: K0249)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6689" JCTVC-K0299 Cross-check of AHG6: SAO offset coding (K0268) by Qualcomm [C. Rosewarne (CiSRA), M. Maeda (Canon)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6631" JCTVC-K0249 AhG6: SAO offset coding for higher bit-depth video [W-S. Kim, M. Budagavi, V. Sze (TI)]
(include abstract)
Same idea as K0268, but uses a different binarization (condition dependent on bit-depth) which would leave the syntax unchanged for 8 bit (main profile).
No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6691" JCTVC-K0301Crosscheck report for TI's proposal (JCTVC-K0249) [T.Matsunobu, T.Sugio (??)] [late]

Other loop and interpolation filters
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6543" JCTVC-K0172 Modification of zero-delay non-local means filter [M. Matsumura, S. Takamura, H. Fujii, A. Shimizu (NTT)]
Authors unable to attend; presentation by cross-checker suggested.
[include abstract]
Presented by cross-checker:
Noise reduction for 2x2 block
No gain on luma
chroma gains 1.6% / 2% for AI
chroma gain 0.5% / 0.7% for RA
chroma gain 0.9% / 1.8% for LDB
decoding time 114% for AI
(remark: For AI it could be applied as post processing)
no action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6681" JCTVC-K0291 Cross-check of zero-delay non-local means filter (JCTVC-K0172) [K. Kawamura, T. Yoshino, S. Naito (KDDI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6647" JCTVC-K0260 Syntax to support use Chroma filter for Luma interpolation [J. Lou, K. Minoo, Y. Yu, L. Wang (Motorola Mobility)]
In the current HEVC, 8-tap/7-tap FIR filters are used for Luma component interpolation and 4-tap FIR filters are used for Chroma component interpolation. Generally, 4-tap filters need much less computational complexity and memory bandwidth than the 8-tap filters. It is identifid that for some high resolution sequences, replacing the 8-tap Luma interpolation filters with the 4-tap Chroma filters does not introduce coding efficincy degradation, but greatly reducing the computational and memory complexity. It is proposed to introduce one flag in SPS to indicate if the Chroma interpolation filters are used for Luma interpolation. Crosscheck will be provided by Samsung.
Does not solve worst-case complexityLikely to require additional logic
More complex for encoder
Subjective impact not clear mostly beneficial on noisy sequences
No support - no action.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6702" JCTVC-K0309 The cross-check for use of Chroma filter for Luma interpolation (JCTVC-K0260) [E. Alshina (Samsung)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6662" JCTVC-K0273 AHG6: ALF in HM80 [I. S. Chong, M. Karczewicz(Qualcomm), C.-Y. Chen, C.-Y. Tsai, C.-M. Fu, Y.-W. Huang, S. Lei (MediaTek), T. Yamakage, T. Itoh, T. Chujoh (Toshiba)]
In this contribution, we first evaluate ALF in HM80. Compared with ALF-off, the ALF coding gain is 1.3%/2.4%/1.1%/2.2% for Main-AI/RA/LB/LP and 1.4%/2.8%/2.1%/3.3% for HE10-AI/RA/LB/LP. Furthermore, we evaluate ALF in JCTVC-J0390 on top of HM80. Compared with ALF-off, the ALF coding gain is 1.4%/2.8%/2.1%/3.5% for Main-AI/RA/LB/LP and 1.5%/3.1%/2.5%/4.1% for HE10-AI/RA/LB/LP. For key technical area sequences (i.e., 720p or higher resolution), the ALF coding gain is 3.9% (Y) / 5.4% (Cb) /4.8% (Cr). We propose to keep ALF in the reference software (i.e., HM90) with improvements made in the JCTVC-J0390 to help development of HEVC extensions and 2nd version HEVC profiles.
Contribution for information
Proponent suggests to include the change in encoder at least, but if possible the simplifications of 390.
Method of 390 (16 bit) would only make sense for main profile (8 bit)
No action, as ALF is not used in a current standardization activity. If it would hypothetically be used somewhere (Prof Prof, SVC), it is likely to be modified in a different way.

Block structures and partitioning
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6488" JCTVC-K0118 Encoding complexity reduction by removal of some unnecessary CU segmentations and partition types based on spatial and temporal correlation [Xiaohai He, Guoyun Zhong, Yuan Li, Linbo Qing, Di Wu (??)]

Motion and mode coding
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6568" JCTVC-K0197 Removal of dependency between PUs in a CU for parallel merging candidate list construction [Y. Lin, J. zheng, X. Zheng (Hisilicon)] [late]
This contribution presents an issue on parallel merging candidate list construction when a CU has multiple PUs, e.g., a CU with Nx2N partition includes two PUs, left PU and right PU. For purpose of parallelism of merging candidate list construction for the two PUs, no any dependency between the two PUs is allowed. However, in HM8 implementation, the derivation process of spatial merging candidates for the right PU still depends on the left PU, since the left PU is involved in the pruning process of merging candidate list construction for the right PU. It is proposed to completely remove the dependency between the two PUs for purpose of parallelism of PU-based merging candidate list construction. Experimental results show average coding efficiency of 0.02%(RA-MAIN), 0.00%(RA-HE10), 0.06%(LDB-MAIN) and 0.06%(LDB-HE10) with comparison to HM8.0.
Several experts believed that usage of candidate A1 in case of Nx2N and 2NxN is already prohibited in the spec. It is definitely the intended behaviour.
A1 is excluded as candidate, but seems to be used in conditional checking in the pruning process.
Side activity: M. Zhou, P. Kapsenberg, someone from Nokia, report back whether the suggested solution solves that problem and whether a deviation between text and software exists. Revisit.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6719" JCTVC-K0324 Cross check of Hisilicon's proposal JCTVC-K0197 [J. Kim (??)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6618" JCTVC-K0239 Temporal motion vector prediction hook for MV-HEVC [Y. Chen, L. Zhang, V. Seregin, M. Karczewicz (Qualcomm)]
In the current HEVC design, when merge mode is used, the reference index for the temporal merging candidate is always zero. This impacts the coding efficiency relatively small, since scaling can be used to compensate the temporal location differences. However, in the context of multiview or 3DV coding, reference index equal to zero may correspond to the reference picture in the same view, while the motion vector (MV) of the co-located PU may point to an inter-view reference picture. In this case, TMVP candidate is considered as unavailable. To address this issue, it is proposed that one additional target reference index is used, so that TMVP can be supported even when the MV of the co-located PU points to an inter-view reference picture. For multiview video coding (MV-HEVC), the proposed method provides about 0.94% average bitrate saving for the all the views and 2.5% bitrate saving for the non-base views.
In the initial review in track B, some concern was raised to include this change in version 1, as it would require a considerable amount of text which may only be needed in a future version.
In the last meeting, a restriction was included where in cases where current picture and co-located picture have different picture type (short/long), TMVP was disabled. Question was raised whether removing this again would resolve the issue? According to the proponent, tThis would not be the case, as it would insert a wrong candidate (e.g. using the motion vector of the base view which is marked as long term instead of a correct disparity vector).
Another question is whether this is actually be considered as an actual low level change (the required additional logic would be minor, as it would just mean to enable TMVP candidate from an additional reference picture, it is not about inserting a new coding tool) revisit in JCT plenary.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6698" JCTVC-K0306 Cross-check of JCTVC-K0239 [Y. Takahashi, O. Nakagami, T. Suzuki (??)] [late]

High-level syntax and slice structure (81)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6745" JCTVC-K0339 BoG report on general high-level syntax topics [M. M. Hannuksela (Nokia)]
The results of this BoG report are noted in the section for contribution discussed therein.
NAL unit header (3 ( 1)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6491" JCTVC-K0121 AHG9: NAL unit header design for support of multi-standard extensions [Y. Chen, Y.-K. Wang (Qualcomm)]
(This was initially reviewed in the AHG9 meeting.)
This is a follow-up proposal of JCTVC-I0355 and JCTVC-J0113, for support an HEVC extension where the base layer/view is AVC and the enhancement layers/views are HEVC. In both of these proposals, NAL unit header syntax changes were proposed so that distinguishing of AVC and HEVC NAL units by checking the NAL unit header becomes possible. Both the approaches in JCTVC-I0355 and JCTVC-J0113 require a bit to be reserved at the HEVC NAL unit header.
In this proposal, it is proposed that the order of syntax elements to be changed to support the multi-standard functionality, which is a "should" requirement for the scalable enhancement of HEVC and was also supported in 3DV discussions.
It was remarked that this could be addressed at the systems level, rather than trying to create bitstreams that are mixed at the NAL unit level.
K0206 was mentioned as being relevant.
The specific suggestion is to switch the order of the nal_unit_type and nuh_reserved_zero_6bits syntax elements in the NUH. Then, in a mixed bitstream, the value of the one of the bits of nuh_reserved_zero_6bits (which, conceptually, is the layer ID) would always be set to 1.
It was commented that it could be desirable to detect HEVC vs. AVC even without enabling the mixed-bitstream construction.
Actual operation with reception of a mixed bitstream fed directly to an existing AVC decoder (without a demux).
The HLS AHG suggested to revisit after K0206 discussion.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6548" JCTVC-K0177 AHG9: NAL unit header with layer ID partitioning [B. Choi, J. Park (Samsung), Y.-K. Wang, Y. Chen (Qualcomm)]
(This was initially reviewed in the AHG9 meeting.)
At the 10th JCT-VC meeting, two approaches for NAL unit header and video parameter set for HEVC extension were discussed, and their straw man designs were described in JCTVC-J1007. This contribution proposes two alternative NAL unit header designs in the same category as approach 2 in JCTVC-J1007. The proposed design partitions a layer_id into specific scalability dimension identifiers by parsing only NAL unit headers.
For the "base" (v1) specification, the only proposed changes are 1) the NUH of the VPS, and in one variation of the proposal, 2) having the size of the temporal_id depend on the NUH of the VPS.
The proposal avoids needing a mapping table in the VPS to identify a layer type, by instead creating a partitioning of the layer id bits in the NUH into separate fields for different types of layering.
The partitioning approach would be somewhat simpler to use, while the mapping table approach would be somewhat more flexible somewhat more "future proof".
It was noted that the proposal enables a non-fixed partitioning of temporal ID bits, which has both advantages and disadvantages. In that regard, it adds some flexibility. However, it was questioned whether we would really need more than 6 bits of layer ID range.
When reviewed in the HLS AHG, there did not seem to be strong support for this proposal.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6581" JCTVC-K0210 AHG9: NAL unit header design for base spec [B. Choi, T. Lee, C. Kim, J. Park (Samsung)]
(This was initially reviewed in the AHG9 meeting.)
In the latest HEVC WD, 6 bits are reserved for layer_id in the NAL unit header. However, even if layer_id should be signalled in NAL unit headers in an HEVC extension, it was suggested that this does not mean that the bits for layer_id should be reserved and be fixed to a pre-defined value in the HEVC base spec. If a way to distinguish base layer NAL units from enhancement layer NAL units is present, the reserved bits can be used for other purposes than layer_id in HEVC base spec. This document proposes two alternative NAL unit header designs for the distinguishing base layer NAL units and non-base layer NAL units. Some part of this contribution overlaps the design proposed in JCTVC-K0177.
One proposed approach is to use a bit to identify whether the current layer is the base layer or not. When the layer is identified as the base layer, more bits would become available for use in the base layer. Another aspect of the proposal merges the temporal sub-layer ID into other layering identification bits.
Another proposed approach is to increase the number of bits for NUT and use different NUTs for enhancement layers (including temporal layers) than the values of the NUTs used for the base layer.
In each variant, there would be a distinction drawn between the syntax of the base layer NUT and the syntax of enhancement layer NUTs, and then some syntax elements in the NUH of the base layer that would become available for use for other purposes.
One proposed use of the additional available syntax in the base layer would be an inter-layer prediction (ILP) flag, indicating whether the base layer is used by enhancement layers or not. Others include a picture output flag, and a no-output-of-prior-pictures flag.
There was some interest in adding an ILP flag. This should be further discussed, and potentially added e.g. in the slice header if not the NUH.
When reviewed in the HLS AHG, there did not seem to be strong support for this proposal (other than in having an ILP flag).
Suggestion #1: Send a number 'num_extra_slice_header_bits' encoded as u(3) in PPS, then that number of bits will be present in the (early part of) the SH (after the pps_id and slice_address and dependent_slice_flag), to be ignored if present (until specified later). Current conforming bitstreams required to have 'num_extra_slice_header_bits' equal to 0. Further suggestion (SW): A distinct value for each slice type. Further suggestion: Promise never to put more than X bits there, where X = 7. Decision: Agreed, but not with a distinct value for each slice type, and don't send it for a dependent slice.
Suggestion #2: Move the slice header extension earlier in the slice header and change its units from bytes to bits.
Suggestion #3: Flag in SPS to indicate whether an ILP flag is in the SH (at some early position).
Random access and adaptation (8 ( 36)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6492" JCTVC-K0122 AHG9: On CRA and BLA pictures [Y.-K. Wang (Qualcomm)]
(This was initially reviewed in the AHG9 meeting.)
This document proposes the use of an external-means-determined flag, UseAltCpbParamsFlag, to specify which set of initial CPB removal delay and offset parameters is used, for BLA pictures with nal_unit_type equal to BLA_W_LP and CRA pictures. The proposed flag is also used to specify which of the BLA NAL unit types is used when a CRA picture is indicated to be handled as a BLA picture.
In the current draft, the NUT of AU number 0 determines which parameters apply. Also, in the current draft, there is an external means flag, HandleCraAsBlaFlag, that is used.
There was support expressed for the proposal in the HLS AHG discussion. Pending close study, the HLS AHG supported the proposal (at least in concept). Decision: Adopted.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6530" JCTVC-K0159 AHG 9: On referenced and non-referenced DLP and TFD NAL units [Hendry, Y. Jeon, B. Jeon (LG)]
(This was initially reviewed in the AHG9 meeting.)
In the 10th JCTVC meeting, it was agreed to remove nal_ref_flag from NAL unit header and divide NAL unit types for coded slice of a non-TSA, non-STSA trailing picture, coded slice of a TSA picture, and coded slice of an STSA picture into referenced and non-referenced NAL unit types to replace the functionality that was provided by the removed flag. This contribution proposes to also divide NAL unit types for leading pictures (i.e., DLP and TFD NAL unit types) into referenced and non-referenced types. The rationale for this is that leading pictures actually behave similar to trailing pictures in the decoding process when random access / splicing are not done.
It was commented that we would ordinarily not expect many leading pictures per temporal layer, so this modification might not be necessary. The temporal ID already provides some ability to indicate "droppable" pictures within the leading pictures category.
Note that one of the items in K0208 is the same as this proposal.
It was remarked that this topic was already discussed at the previous meeting, and the new contributions are not really adding to that. The question is whether it is really worth using two NUTs for this indication.
In the HLS AHG discussion, there was a mixture of support and skepticism regarding this proposal. Further discussion was suggested.
Decision: Adopted the addition of the reference/non-reference distinction by NUT for TFD & DLP.
Decision: 0-15 for non-RAP VCL, odd=reference; 16-23 for RAP VCL, 24-31 reserved VCL, 32-47 non-VCL, 48-63 unspecified.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6535" JCTVC-K0164 AHG 9: On non-referenced TSA and STSA NAL units [Hendry, B. Jeon (LG)]
(This was initially reviewed in the AHG9 meeting.)
In the 10th JCTVC meeting, it was agreed to adopt STSA NAL units and also to differentiate TSA and STSA NAL unit types into referenced and non-referenced NAL units (i.e., TSA_R, TSA_N, STSA_R, and STSA_N). Since both TSA and STSA NAL units can be referenced (i.e., TSA_R and STSA_R) and non-referenced (i.e., TSA_N and STSA_N), it was suggested that there is a possibility that for the TSA_N and / or STSA_N are removed from the bitstream by a system / network that work simply by checking whether or not a NAL unit is needed for reference.
It was remarked that there may be value in retaining the non-reference TSA and STSA types, and that an encoder would only use those types if those pictures were reasonably discardable (e.g. if there were also some reference TSA or STSA pictures in the bitstream as well). Having the non-reference types may allow the decoder to recover somewhat earlier.
However, it was remarked that using another temporal ID for the non-reference TSA/STSA pictures, it could provide a similar functionality. This was questioned in regard to trying to have a fixed frame rate in each temporal sub-layer.
There was not a consensus in the HLS AHG on this, so further discussion was suggested.
Another aspect discussed in the contribution was whether it is reasonable to allow an STSA picture in a layer when there was not a TSA or STSA the next lower layer. In some instances, this seemed reasonable, so no action was suggested to be taken on this aspect by the HLS AHG.
No action taken, due to above-recorded decision to consistently apply reference/non-reference distinction.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6537" JCTVC-K0166 AHG 9: On random access point NAL units [Hendry, B. Jeon (LG)]
(This was initially reviewed in the AHG9 meeting.)
This contribution proposes merging the IDR and BLA NUTs, asserting that they have similar functionality. It was noted that dropping IDR was previously proposed (at least twice). The contribution seemed to essentially repeat that proposal. Skepticism was expressed about this by some participants, saying that some systems may want to rely on the distinctness of IDR functionality.
No action was recommended by the HLS AHG on this aspect.
Another aspect of the proposal was to merge the NUTs for RAP pictures and use the current temporal ID bit field to distinguish between the RAP types instead of using the NUT. This would save 5 NUT values. It was remarked that K0219 includes a proposed similar approach.
There were mixed opinions about this in the HLS AHG, due to the conditional interpretation of the temporal ID bit field from a bitstream extraction perspective, so further discussion was suggested. The temporal ID would need to be inferred as zero when the NUT indicates a RAP picture.
The HLS AHG recommended further discussion of this (together with K0219).
Comment: How about VPS and SPS? They always have temporal ID equal to 0. We could make the temporal ID interpretation depend on those cases as well. And should some reserved NUT values have conditional temporal ID interpretation as well?
Opinions remained mixed in further discussion.
No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6579" JCTVC-K0208 AHG9: On random access point pictures [B. Choi, T. Lee, Y. Park, J. Park (Samsung)]
(This was initially reviewed in the AHG9 meeting.)
In this contribution, several syntax changes on random access point pictures are proposed.
CRA and BLA NAL units and pictures: 1) Inclusion of new NAL unit and picture types for CRA with TFD and DLP pictures, 2) Removal of BLA_W_DLP NAL unit and picture type. This seemed unnecessary in HLS AHG discussion.
IDR NAL unit and picture: Combining two IDR types to an IDR type. This was not supported in the HLS AHG discussion, as the current design simplifies the detection of the simplest stream access point type (e.g. as used in DASH and file format specs).
TSA and STSA NAL units and pictures: Inclusion of TSA&TFD picture and STSA&TFD picture proposing to add two NUTs. This was originally proposed in J0107, but having the extra distinction was not supported and there seemed to be no clear need to change that in the HLS AHG discussion.
Reference/non-reference NAL units and pictures: 1) Inclusion of DLP and TFD pictures referenced or non-referenced, 2) Inclusion of nuh_ref_flag in NAL unit header. The same as proposed in K0159 see notes in that section.
TFD NAL unit and picture: Inclusion of nuh_discard_flag a proposal that depends on JCTVC-K0210. See discussion of K0210.
DLP picture: Enabling inter-prediction from DLP pictures to the following pictures. The coding efficiency benefit did not seem sufficient to justify this change.
Moving no_output_of_prior_pics_flag into the NUH a proposal that depends on JCTVC-K0210. See discussion of K0210.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6593" JCTVC-K0219 On Random Access Point Picture Signaling [S. Deshpande (Sharp)]
(This was initially reviewed in the AHG9 meeting.)
In HEVC when a RAP picture is signalled the syntax element nuh_temporal_id_plus1 is required to be signalled such that TemporalId shall be equal to 0. This document proposes different alternatives to use this unused syntax element in the case of RAP pictures. It is asserted that this is beneficial and does not sacrifice complexity.
Approach 1 in this proposal is essentially the same as the RAP type NUT merging proposed in K0166.
Approach 2 concerned back-to-back IDR pictures, and proposed sending a RAP ID (similar to IDR pic ID in AVC) for RAP pictures.
Approach 3 reserves the current temporal ID bits for future use when the picture is a RAP picture.
See notes in section on K0219.
An additional separate aspect of the document proposes signalling the pic_order_cnt_lsb syntax element for IDR pictures. Note that we no longer have IDR pic ID. The pic_order_cnt_lsb for an IDR would be interpreted in the same manner as for a BLA.
It was noted that K0166 is related to this.
It was asked whether it should be required for back-to-back IDR pictures to have different values of pic_order_cnt_lsb. There would be both advantages and disadvantages to such a requirement.
It was remarked that there is an SEI message proposal K0205 that is related, and there are system-level uses for this e.g. for AVC/SVC.
It was remarked that this may not really provide any capability that is not otherwise available, other than providing some identifier. In the HLS AHG, there did not seem to be strong interest in this aspect.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6730" JCTVC-K0330 Introduction of temporal_id_type [Arturo Rodriguez (??)] [late]
TBP (late).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6735" JCTVC-K0332 Independent intra-period coding in HEVC [Krzysztof Wegner, Olgierd Stankiewicz, Jakub Siast, Marek Domanski (Poznan Univ.)] [late]
TBP (late).
Slices and slice header parameters (9 ( 37)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6538" JCTVC-K0167 AHG 9: On dependent slice [Hendry, B. Jeon (LG)]
(This was initially reviewed in the AHG9 meeting.)
This contribution proposes, for a dependent slice, to send the POC LSB and the CTU address of the slice on which it depends.
Without something like this, detection of losses at the header level would be difficult (absent a system-level functionality for this). However, it was questioned whether the ability to perform the detection at the header level (without decoding the preceding slice) is very useful for a dependent slice.
In the HLS AHG, the opinions on this seemed somewhat mixed and there was no strong support expressed by non-proponents.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6539" JCTVC-K0168 AHG 9: Short Slice Header [Hendry, B. Jeon (LG)]
(This was initially reviewed in the AHG9 meeting.)
In the current HEVC specification, all syntax elements of a slice header must present even when they do not change from slice to slice within the same picture, unless the slice is a dependent slice. It was asserted that in environment where error resiliency is not critical, duplicating syntax elements in slice headers is undesirable. Previous related proposals have included JCTVC-I0070 and JCTVC-J0109.
This contribution proposes a short slice header that is indicated by a short_slice_header_flag. When the flag is set, the slice header contains only syntax elements that change from the previous regular slice header with the flag not set and syntax elements that are not present would be copied from previous regular slice header.
The slice header contents are proposed to not be allowed to change within a picture when using this scheme.
A participant commented that this somewhat defeats the purpose of separating a picture into slices.
In the HLS AHG, the general view seemed to be that similar ideas had been proposed before, and that it seemed unwise to adopt such a scheme at this point.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6674" JCTVC-K0284 Cross-check of JCTVC-K0168 on Short Slice Header [Félix Henry, Gordon Clare (Orange Labs)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6555" JCTVC-K0184 AHG9: On dependent slices syntax [S. Esenlik, M. Narroschke, T. Wedi (Panasonic)]
(This was initially reviewed in the AHG9 meeting.)
The dependent slices introduce an additional dimension of dependency between the VCL NAL units, where a dependent slice is not decodable if the preceding VCL NAL unit is lost. It was asserted to be desirable to take this dependency into account in routing operations for the purposes of more efficient bitstream adaptation and managing of the downlink bandwidth. In the document it is proposed to change the signalling orders of the dependent_slice_flag and dependent_slice_enabled_flag in the corresponding syntax structures in order to enable routers to access and utilize the slice dependency indication.
In the HLS AHG, there was some support expressed for taking action on this topic. However, offline study and further discussion seemed necessary.
In JCT-VC discussion, the idea of using a NUT for dependent slices was considered. It was noted that some information about the picture type is not available (e.g. whether the dependent slice belongs to an IDR, or CRA picture or not) if this is done.
"Alternative 1" moves the dependent_slice flag before the slice_address (after pps_id) and moves the enabled_flag just before the sign_data_hiding_flag in the PPS. Decision: Adopt (this alternative #1)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6678" JCTVC-K0288 Comments on Entropy Slices [W. Wan, B. Heng (Broadcom)] [late]
(This was initially reviewed in the AHG9 meeting.)
The current HEVC draft text specifies the concept of entropy slices but they are not included in the Main Profile and seem to be the only feature that has this status. This contribution notes that entropy slices do not break a number of cross-slice dependencies in CABAC decoding state (e.g. for intra mode identification and/or because of context selection dependencies). As such, it is not possible to independently CABAC decode entropy slices. Because they are asserted to no longer accomplish their intended purpose, this contribution recommends removing entropy slices from the HEVC specification.
K0120 also proposes removal of entropy slices from the draft standard.
The HLS AHG recommended removal of entropy slices from the draft standard. Decision: Agreed.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6707" JCTVC-K0314 Comments on Dependent Slices [W. Wan, B. Heng, P. Chen (Broadcom)] [late]
(This was initially reviewed in the AHG9 meeting.)
This contribution notes an issue with the specification of dependent slices in the current HEVC WD text. Specifically, it is unclear in which instances the term slice is intended to refer to both ("normal") slices and dependent slices, and in which instances slice refers only to (normal) slices. Two areas of the current HM software (QP prediction and loop filtering) are discussed that are asserted to have contradicting behavior for dependent slices. It is proposed that the slice term be clarified and used consistently with respect to dependent slices and suggested that cross-slice prediction is always allowed for dependent slices.
It was remarked that "dependent slice" may not be a good name, as the data is really part of the same "slice". Suggestions: "slice segment" ("independent slice segment" and "dependent slice segment" together form the complete "slice"), "slice suffix", "slice appendix", "slice trailer".
Conceptually, a "dependent slice" should be considered part of the same slice.
The HLS AHG agreed that these aspects should be clarified. Offline study with review of the identified issues was recommended.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6750" JCTVC-K0341 AHG9: On slice_temporal_mvp_enable_flag [Y.-K. Wang (Qualcomm)] [late]
TBP (late). Related to a topic discussed in HLS BoG.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6483" JCTVC-K0113 The general structure and syntax of the slice extension [D. Singer, T. Leontaris, A. Tourapis (Apple)]
(No presenter was available in the HLS AHG meeting to present this contribution.)
This contribution offers a general syntax for slice-extensions, and enables them to be found and used before entropy decoding of the rest of the slice. This enables pipelined transmission of data that can only be generated after encoding, yet is currently placed in the slice header or a preceding SEI message, which requires buffering before transmission. Placing the data in the slice extension hence enables pipelined transmission and reduced delay.
Three uses were listed:
Entry points (not so decoder-friendly)
Checksums (not so essential not part of decoding process no need for backward parsing)
Deblocking filter (or ALF) control parameters (not so decoder friendly backward parsing could be useful)
A trailing SEI message could also provide a way to signal such things (although in a less compact way) see proposal K0120.
It was noted that dependent slices starting at each LCU row in the wavefront case, or tile in the tiled case, is a way to provide effective "low-delay" entry points.
It was remarked that the current syntax is broken, since the rbsp_stop_one_bit is actually part of the CABAC data string, but the current syntax puts non-CABAC data between the payload and that bit. K0361 highlights this issue and proposes fixes, so this is a separate issue.
The current scheme can only be parsed in the forward direction.
For further study, and possible revisit.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6484" JCTVC-K0114 Specific Uses of the Slice Extension [D. Singer, T. Leontaris, A. Tourapis (Apple)]
(No presenter was available in the HLS AHG meeting to present this contribution.)
See section discussing K0113.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6771" JCTVC-K0361 CABAC termination stop bit [V. Sze (TI)] [late]
To be reviewed

Reference picture signalling (10)
Picture order count (POC) (3)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6513" JCTVC-K0143 On handling of minimum POC range at decoder [K. Kazui, J. Koyama, S. Shimada, A. Nakagawa (Fujitsu)]
This contribution provides the text which describes how a decoder can handle a POC value without having 32-bit range limit, according to the resolution at the 10th JCT-VC meeting. It is also proposed to extend the range of the POC value to 64-bit as once decided at the 9th JCT-VC meeting.
Quote from prior meeting notes:
"If adequate text is provided to describe how a decoder can handle POC without having such a range limit, we can review the description of that scheme and consider including it in the standard and removing (or increasing) the 32 bit range limit. That aspect is for further study."
It may take a long bitstream to test the wrapping behaviour. The maximum LSBs that can be sent are 16. A 65537-picture bitstream would be needed to test wrapping behaviour in a decoder.
It was commented that the provided text was still somewhat imprecise regarding exactly what a decoder would need to do, although it seemed conceptually correct.
It was commented that the simplicity of the current limit is desirable.
No action taken.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6525" JCTVC-K0154 Simplification of PicOrderCntMsb calculation and specification [C. Auyeung, J. Xu, A. Tabatabai (Sony)]
This contribution proposes to simplify the specification and calculation of PicOrderCntMsb in WD8 without changing the semantics in WD8. This contribution removes four arithmetic-logic operations and removes the implicit assumption that the subtraction in the calculation is based on unsigned integer arithmetic in WD8. The proposed text is asserted to be correct for both signed and unsigned integer arithmetic.
Decision (Ed.): This is a purely editorial issue. The contribution seemed correct, and was delegated to the editor to determine the appropriate action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6623" JCTVC-K0242 Cross-verification of JCTVC-K0154 [A.lexis Tourapis (Apple)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6602" JCTVC-K0227 On POC Signalling [X.iaosong (Steve) Zhou, D.azhong Zhang, Y.unfei Zheng, J.ae H.oon Kim (Apple)]
This contribution proposes ways to signal the remaining bits of current pictures POC in the slice header in addition to its LSB, in order to avoid or correct potential POC mismatch between the encoder and the decoder, when consecutive frame losses occur during transmission. Two different signalling methods are introduced: Method 1 allows the encoder to signal all the remaining bits of the POC; method 2 further reduces the signalling overhead in Method 1 by allowing the encoder to signal part of the remaining bits.
It was commented that there would be an adverse effect in the event of splicing, in which a CRA picture is converted to a BLA picture.
It was asked whether the sent value would be required to match the value that would have been computed if there was no data loss. It seemed that this would, in spirit, be required (otherwise there would likely be some violation of the maximum POC difference gap constraint).
It was asked whether some other method such as SEI would be sufficient to provide the functionality, as the data is redundant with what the decoder can compute without receiving the extra data.
A participant suggested that the match requirement could be specified in terms of the value that would have been computed if the decoding process had begun from the previous RAP picture in decoding order. This would seem to resolve the splicing issue.
It was suggested that something along these lines structured as an SEI message proposal might be more appropriate.
No action taken.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6752" JCTVC-K0343 AHG9: On POC and its timing hint [Y.-K. Wang (Qualcomm)] [late]
TBP (late). Related to a topic discussed in HLS BoG.
Reference picture set (RPS) (3)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6493" JCTVC-K0123 AHG9: Reference picture set clean-ups [A. K. Ramasubramonian, Y.-K. Wang (Qualcomm)]
This document proposes the following as "clean-up" changes related to reference picture set signalling and derivation:
Addition of restrictions such that each LTRP signalled (explicitly or indexed) in the slice header shall be a distinct reference picture. It was agreed that there is a problem in this area that needs fixing. The correction could involve syntax/semantics changes or addition of restrictions. K0235 discusses the same problem. Revisit after offline drafting and checking of syntax-based approach.
Addition of a restriction that an LTRP entry shall not be directly signalled in any slice header when an equivalent LTRP entry is included in the SPS. It was commented that there is no real need to impose this restriction.
Addition of a restriction that disallows duplicate LTRP entries signalled in the SPS. It was commented that there is no real need to impose this restriction.
Addition of a restriction that disallows duplicate short-term RPS candidates in the SPS and a short-term RPS pattern in the SPS being repeatedly (i.e. explicitly) signalled in the slice header. It was commented that there is no real need to impose this restriction.
Removal of the restriction that POC LSBs for LTRPs are signalled in a non-increasing order and modifying the derivation of POC MSB cycle. To be discussed together with the above revisit topic.
Not counting STRPs in determination of sending MSB cycle for LTRPs. This change does not seem strictly necessary but is asserted to be a spec simplification. No action on this aspect.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6596" JCTVC-K0222 On reference picture set extension [S. Deshpande (Sharp)]
This document proposes an extension field in the short-term reference picture set syntax structure. This field enables extension of the short-term reference picture sets in future extensions of HEVC.
Revision of this document adds a modified syntax for the extension signalling.
One example use would be to send a layer ID. Another could be the sending of inter-layer reference marking.
The mechanism would be essentially the same as in the SH extension, controlled by an SPS-level presence flag. One suggestion was to have two presence flags rather than one so that the flag can be different for the RPS syntax in the SPS and in the SH.
No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6610" JCTVC-K0235 Single inclusion of long-term reference pictures in RPS [J. Samuelsson, R. Sjöberg (Ericsson)]
This contribution contains a proposal for how to avoid that the same long-term reference picture is included more than once in the same reference picture set (RPS). At the Stockholm meeting the possibility to signal long-term reference pictures in the sequence parameter set (SPS) was adopted. It is therefore possible to signal the least significant bits (LSB) of long-term reference pictures both in the SPS and in the slice header and the semantics makes it possible to include the same long-term reference picture more than once in the same RPS even though that has no practical usage. This contribution proposes that the LSB that are signalled in the sequence parameter set (SPS) and the LSB that are signalled in the slice header are put in a joint ordered (non-decreasing) list and that for elements with the same LSB, the most significant bits (MSB) are signalled in strictly increasing order. The contribution claims that the proposed changes makes it impossible to include the same long-term reference picture more than once in the same RPS, that ambiguity in the decoding process is removed and that redundancy in the signalling of delta_poc_msb_cycle_lt is removed.
To be revisited in conjunction with K0123.
Reference picture list (RPL) (4)
Track A discussion of contributions in this category was chaired by M. M. Hannuksela.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6494" JCTVC-K0124 AHG9: Reference picture list modification with truncation [A. K. Ramasubramonian, Y. Chen (Qualcomm)]
In the current HEVC draft, reference picture list modification requires signalling of each entry for a reference picture list. In this proposal, the flexibility of signalling a smaller number of entries is proposed with reportedly minor syntax changes. Two methods with the same syntax table are proposed. The first method provides similar functionalities as AVC reference picture list modification, while the second method is asserted to be further simplified to just bring pictures to the beginning of the reference picture list with less decoding process changes.
It was commented that the proposed syntax seemed to have an error. It was suggested to upload a new version of the contribution with fixed specification text.
No compression efficiency results were presented.
Revisit after implementation, simulation results according to the common conditions, and a cross-check.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6541" JCTVC-K0170 AHG 9: On restricted reference picture list [Hendry, Y. Jeon, B. Jeon (LG)]
This contribution proposes to move restriction_ref_pic_lists_flag from SPS to PPS. In addition, to avoid a parsing problem, it is also proposed to move lists_modification_present_flag from SPS to PPS.
It was asked whether restriction_ref_pic_lists_flag should also infer weighting parameters to be unchanged within a picture.
Decision: Move restriction_ref_pic_lists_flag to VUI and move lists_modification_present_flag to PPS. No constraints on the value combinations of these two flags.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6598" JCTVC-K0224 Syntax cleanup for reference picture list modification signalling [G. J. Sullivan, S. Kanumuri (Microsoft)]
The syntax for reference picture list modification, as found in the ref_pic_list_modification() syntax structure, is asserted to have unnecessary redundancies for the signalling of some of its syntax elements. This contribution proposes modifications that are asserted to remove the redundancies.
Proposal #1: In the syntax for ref_pic_list_modification(), it is proposed that ref_pic_list_modification_flag_l0 and ref_pic_list_modification_flag_l1 only be sent when NumPocTotalCurr is greater than 1. When NumPocTotalCurr is less than or equal to 1, there is no possibility for modification and hence no need to send these flags.
Proposal #1 is similar to an aspect in JCTVC-K0255 (only editorial differences between proposal #1 and the aspect in JCTVC-K0255).
Decision: Pproposal #1 adopted.
Proposal #2 Option A: In the syntax for ref_pic_list_modification( ), it is proposed that list_entry_lX[0] not be sent when NumPocTotalCurr is equal to 2 and num_ref_idx_lX_active_minus1 is equal to 0. In such a case, list_entry_lX[0] can be inferred based on ref_pic_list_modification_flag_lX since there are only two choices possible (default value of 0 or the non-default value of 1).
No action taken.
Proposal #2 Option B: In addition to Option A, for P slices with weighted_pred_flag equal to 0 or for B slices with weighted_bipred_flag equal to 0, it is proposed that list_entry_lX[ 0 ] and list_entry_lX[ 1 ] not be sent when NumPocTotalCurr is equal to 2 and num_ref_idx_lX_active_minus1 is equal to 1. In such a case, list_entry_lX[ 0 ] and list_entry_lX[ 1 ] are inferred to be 1 and 0 respectively since reference picture list modification would not have been needed for the only other possibility (list_entry_lX[0] and list_entry_lX[ 1 ] being equal to 0 and 1 respectively). Furthermore, for P slices with weighted_pred_flag equal to 0 or for B slices with weighted_bipred_flag equal to 0, it is proposed that the length of list_entry_lX[ i ] syntax element be limited to Ceil( Log2( NumPocTotalCurr " i ) ) bits, since in this case, it is only useful to place each reference picture once in the list and thus the number of useful possibilities decreases as the index i increases.
No compression results were presented.
Concerns on whether the syntax is correct were expressed.
Revisit after implementation, simulation results and a cross-check.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6640" JCTVC-K0255 Cleanup of reference picture list modification [T. Yamamoto, T. Tsukuba, T. Ikai (Sharp)]
This contribution proposes two changes on reference picture list modification signaling. It is asserted that the first proposed change removes redundant modification flag signaling and that the second proposed change is to make the text of initialization process clearer.
The first proposed change was resolved by notes taken for proposal #1 of JCTVC-K0224.
The second proposed change seemed purely editorial. Decision (Eed.): Eeditors to consider as a suggested improvement.
Parameter sets in version 1 of HEVC (6)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6495" JCTVC-K0125 AHG9: On video parameter set [Y.-K. Wang, Y. Chen (Qualcomm)]
This document proposes some changes to the VPS syntax as well as the profile_tier_level( ) and operation_point( ) syntax structures included in the VPS syntax.
Bit rate and picture rate information are proposed to be added to the VPS to assist session negotiation and content selection in HEVC application systems. Decision: Adopted.
The syntax elements for signalling of profile space, tier, compatible profiles, and profile-related constraints for temporal sub-layers are proposed to be removed from the profile_tier_level( ) syntax structure. Decision: Adopt only the sub_layer_profile_present_flag to be conditional on ProfilePresentFlag.
The operation point syntax is proposed to be changed to support a simple operation point mode for which only one value of nuh_reserved_zero_6bits needs to be signalled. K0204 is related. Revisit after conferring offline in relation to K0204.
When multiple values of the nuh_reserved_zero_6bits are signalled for one operation point, they are proposed to be differentially coded. The changing operation point signalling is asserted to be more efficient, particular for typical scalability coding scenarios with linear layer dependency. K0204 is related. Revisit after conferring offline in relation to K0204.
Within one VPS, duplicate copies of operation points and duplicate copies of hrd_parameters( ) syntax structure are proposed to be disallowed within the same VPS. Decision: Adopt.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6544" JCTVC-K0173 On VPS [K. Sato (Sony)]
Both VPS (Video Parameter Set) and SPS (Sequence Parameter Set) contain syntax elements max_temporal_layers_minus1 and temporal_id_nesting_flag. If the value of max_temporal_layers_minus1 is 0, it means that there is only one temporal layer, and in this case temporal_id_nesting_flag becomes meaningless. JCTVC-0183 proposed to remove this redundancy, and adopted as change in semantics.
However, in the current VPS specification temporal_id_nesting_flag is located before max_sub_layers_minus1, so it is not possible to know immediately whether it is meaningful or not during the parsing process. In SPS this problem does not exist.
This contribution requests to move the order of temporal_id_nesting_flag to be after max_sub_layers_minus1 in the VPS. Decision: Adopted (note that BoG is requesting an aligned change in the SPS). Also, the nesting flag should be required to be equal to 1 when the max_sub_layers_minus1 is equal to 0.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6551" JCTVC-K0180 AHG9: Operation points in VPS and nesting SEI [M. M. Hannuksela (Nokia)]
A problem was identified in JCTVC-J0074 that when the conformance of a bitstream containing scalable layers is checked using HEVC v1 standard or an HEVC v1 decoder decodes a bitstream containing scalable layers, the HRD parameters of the highest layer present in the bitstream should be used. As a solution to the problem, HEVC draft 8 includes a possibility to include multiple sets of HRD parameters for different bitstream subsets into VPS. It is asserted in this contribution that while HEVC draft 8 enables multiple sets of HRD parameters, it still lacks the capability of indicating different initial delays for bitstream subsets.
JCTVC-K0180 proposes:
Specifying operation points as a separate loop in the VPS rather than as part of the loop for the HRD parameters. K0204 is related. Revisit after conferring offline in relation to K0204.
Specifying a scalable nesting SEI message. K0126 is related. Revisit after conferring offline in relation to K0126.
It is asserted that in HEVC v1, the proposed scalable nesting SEI message can be used for two purposes:
Indicate that the nested SEI messages pertain to a range of temporal sub-layers rather than all sub-layers.
Indicate buffering period and picture timing for any bitstream subset, such as the base layer sub-bitstream.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6580" JCTVC-K0209 AHG9: VPS and SPS design [B. Choi, T. Lee, Y. Cho, J. Park (Samsung)]
In this contribution, two VPS and SPS topics are proposed.
Topic #1 is to signal multiple cropping windows in the VPS for layered streams. All possible candidates of cropping windows for all layers are signalled in VPS, and each set of cropping parameters is mapped to an index. In each SPS, the indices of cropping windows used for the layer associated with the SPS are signalled.
For the v1 base layer, one or more cropping windows would be sent in the SPS and duplicated in the VPS. It was noted that there are multiple proposed approaches to cropping windows. Revisit in the context of cropping window contributions.
Topic #2 to remove duplicated syntax signalling between VPS and SPSs. By a flag indicating whether VPS parsing can be skipped or not, the duplicated syntax elements are signalled or not in SPS. The flag indicating the duplication is asserted to have the same role as the vps_skip_flag in the second design proposed in JCTVC-K0177. Revisit in the context of of parameter set designs for extensions.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6597" JCTVC-K0223 On Video Parameter Set [S. Deshpande (Sharp)]
In future extensions of HEVC, the nuh_reserved_zero_6bits in the NAL unit header are anticipated to be used as a layer ID with VPS signalling information that identifies the meaning of those bits. In the previous meeting various proposals for signalling information about these bits were proposed and were categorized into so-called "Approach 1" and "Approach 2" categories. This document proposes a method for signalling scalability information in the VPS about the reserved_zero_6bits in the NAL unit header. Syntax and semantics are proposed which are applicable to both Approach 1 and Approach 2 categories. It is asserted that the proposed approach overcomes drawbacks of the existing approaches and enhances the merits of them. Revisit in the context of of parameter set designs for extensions.
An additional separate aspect of this document proposes signalling a different syntax element in place of nuh_temporal_id_plus1 syntax element for VPS NAL unit type. (A revision of this document adds a variant syntax structure (variant A2) for one of the proposals in the original document.)
This scheme is similar in spirit to other proposals defining NUT-dependent parsing of the temporal ID (e.g. K0219). See notes relating to K0219. No action taken on the second aspect.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6607" JCTVC-K0232 On support of mixed video sequences in High Level Syntaxes [M. Haque, K. Sato, A. Tabatabai (Sony)]
Revisit after dealing with K0119.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6756" JCTVC-K0347 Persistence of VPS: bitstream instead of coded video sequence [M. M. Hannuksela (Nokia), Y.-K. Wang (Qualcomm)] [late]
In the current HEVC draft specification, the active VPS is allowed to be changed for each coded video sequence. Hence, the number of VPSs active for the entire bitstream may be large.
Use cases where video parameter set is used in systems specifications include the capability exchange of session negotiation (e.g. the offer/answer model of the session description protocol, SDP) and declarative indication of bitstream properties (e.g. a part of session description passed through the real-time streaming protocol (RTSP), or a part of media presentation description, MPD, in dynamic adaptive streaming over HTTP, i.e. DASH). It is asserted that it would be convenient in the protocol design and implementation for these use cases, if a VPS pertained for the entire bitstream and consequently only one VPS had to be communicated in session negotiation.
It is proposed that VPS pertains to a bitstream instead of a coded video sequence. In other words, it is proposed that an active VPS remains active until the end of the bitstream.
No action taken. [Add remarks explaining why.]
High-level syntax cleanups (9)
Initially reviewed by BoG (K0339).
Revisit for review of remaining items.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6490" JCTVC-K0120 AHG9: High-level syntax clean-ups [Y.-K. Wang (Qualcomm)]
Initially reviewed by BoG (K0339).
NUTs assignment resolved in other discussions (not per BoG report)
Decision: Moving sps_temporal_nesting_flag per BoG report
Decision (Ed.): Clarificationof semantics of end of sequence RBSP.
Decision: Specify activation of VPS and SPS by APS SEI message and not specify SPS activation by the SPS ID in the BP SEI message (APS SEI must be present when BP SEI is present, and they must be the first and second SEI message in the first SEI NAL unit when present). Further study regarding the wisdom of this requirement, but keep it required in the current draft.
Decision (Ed.): There are editor action items in the BoG report.
Decision (Ed.): 224 constraint on POC difference for LTRP per BoG report.
Decision (Ed.): Alignment of the range restriction on SPS ID (make it 16) and PPS ID (make it 64) for semantics and profile specification. We can simply remove this constraint in the profile specification.
Decision (Ed.): Removal of constraint on position of persistent SEI messages from 7.4.1.4.2.
Decision: Specify a suffix SEI message NUT with payloadType = 132 for the decoded picture hash SEI message (K0120-v2 attachment with edit ID = "Ye-Kui Wang").
Revisit: Specify that 1) when an SEI message has a payloadSize that exceeds the number of bytes needed to hold the SEI message syntax, the data that follows the specified SEI message syntax shall be ignored, 2) encoders shall not put extra data there. Also remove extension flags that appear at the end of currently specified HEVC SEI message (but do not change the AVC SEI messages).
Decision (Ed.): The editor is suggested to consider adding an informative table describing the scope of each type of SEI message.
Revisit: Allowing redundant copies of any SEI message within the scope of its persistence.
Decision: POC temporal relationship syntax based on K0343. timing_info_present_flag should have an inferred value of 0 when not present.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6506" JCTVC-K0136 AHG9: High-level syntax cleanups [C.-Y. Chen, C.-Y. Tsai, C.-W. Hsu, Y.-W. Huang, S. Lei (MediaTek)]
Initially reviewed by BoG (K0339).
See also K0125.
Decision: Not send inter_ref_pic_set_prediction_flag for index 0 (see also prior document J0185).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6545" JCTVC-K0174 On PPS [K Sato (Sony)]
Initially reviewed by BoG (K0339). No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6589" JCTVC-K0217 Proposed cChanges on cCoding tTree uUnit sSyntax and sSequence parameter set RBSP syntax [X.ue Fang (Motorola Mobility)]
Initially reviewed by BoG (K0339).
Revisit change to CTU syntax
Decision: Group together syntax elements for PCM in SPS.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6635" JCTVC-K0251 Modification of slice_temporal_mvp_enable_flag [Yue Yu, Jian Lou, Limin Wang (Motorola Mobility)]
Initially reviewed by BoG (K0339).
Same topic as K0341 and item 1.3 of K0120.
Decision: Adopted (not signalling the flag for IDR pictures).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6639" JCTVC-K0254 AHG9: Parsing profile and level information of temporal sub-layers [T. Tsukuba, T. Yamamoto, S. Deshpande (Sharp)]
Initially reviewed by BoG (K0339).
Byte alignment of sub-layer profile/tier/level no support by non-proponent; no action.
Decision: Move reserved_zero_12bits and increase its length to 16 bits and set it to 0xFFFF in v1 and change reserved_zero_2bits to reserved_three_2bits. See also K0231.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6606" JCTVC-K0231 VPS syntax re-ordering for easy access of extension parameters [M. Haque, K. Sato (Sony)]
[Any need for review distinct from K0254?]
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6643" JCTVC-K0256 Cleanup of Slice Header [Yue Yu, Jian Lou, Limin Wang(Motorola Mobility)]
Initially reviewed by BoG (K0339). No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6644" JCTVC-K0257 Modification of Enabling Weighted Prediction [Yue Yu, Jian Lou, Limin Wang (Motorola Mobility)]
Initially reviewed by BoG (K0339). No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6711" JCTVC-K0316 Semantics of no_output_of_prior_pics_flag [Arturo Rodriguez, Anil Kumar Katti, Hsiang-Yeh Hwang (??)] [late]
No presenter available in BoG.
High-level parallelism (10)
K0367 BoG report
The results of this BoG report are noted in the sections for the contribution discussed therein.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6476" JCTVC-K0106 On Tile Processing Order [P. Kapsenberg (Intel), W. Zhang (Intel)]
Initially reviewed by BoG (K0367). No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6625" JCTVC-K0244 Cross check of JCTVC-K0106 [G. Van der Auwera (Qualcomm)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6478" JCTVC-K0108 On parallel decoding with SEI message containing rReference dDependency tTree [W. W. Ro, M. Kim, D. Kim, K. Kim (Yonsei Univ.), C. Kim, Y. Park, K. Choi (Samsung)]
Initially reviewed by BoG (K0367). No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6505" JCTVC-K0135 AHG4: Independent parsing for WPP substreams [T.-D. Chuang, C.-W. Hsu, Y.-W. Huang, S. Lei (MediaTek)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6648" JCTVC-K0261 Cross-verification of JCTVC-K0135 on Independent parsing for WPP substreams [M. Coban (Qualcomm)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6741" JCTVC-K0335 AHG4: Cross-check of independent parsing for WPP substreams (JCTVC-K0135) [T. Nguyen, D. Marpe, A. Henkel, T. Schierl, V. George (Fraunhofer HHI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6553" JCTVC-K0182 CABAC termination for the end of tile/WPP [K. Terada, H. Sasai (Panasonic)]
Initially reviewed by BoG (K0367). Decision (BF): Adopted.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6554" JCTVC-K0183 AHG4: Dependent slices restriction [S. Esenlik, M. Narroschke, T. Wedi (Panasonic)]
Initially reviewed by BoG (K0367). Decision (Ed.): Editor is requested to double-check that actions taken for "depedendent slices" have resolved its editorial problems.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6571" JCTVC-K0200 AHG4: Sub-stream entry points SEI message [M. Zhou (TI)]
Initially reviewed by BoG (K0367). In later Track A discussion, it was commented that the proposed syntax is fragile to whether non-VCL NAL units are added or removed, and to whether the NAL units are carried by packets or in the Annex B byte stream format. It was suggested that some system-level functionality might be needed to provide the desired functionality. No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6611" JCTVC-K0236 Decoder parallelism indication [J. Samuelsson, R. Sjöberg, M. Westerlund, B. Burman, P. Fröjdh (Ericsson)]
Initially reviewed by BoG (K0367). Proposes an 8 bit thread count value as a bitstream restriction in VUI.
It was commented that the proposal has some editorial issues, and does not address certain aspects of thread-based operation (e.g. bit rate balancing). It was suggested that the proposed parameter should perhaps be renamed as something more specific such as min_spatial_segmentation_idc. Aside from editorial issues, it was agreed that this appears useful. Decision: Adopt (subject to editorial cleanup).
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6483" JCTVC-K0113 The general structure and syntax of the slice extension [David Singer, Thanos Leontaris, Alexis Tourapis (Apple)]
No presenter was available in HLS AHG meeting to present this contribution.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6484" JCTVC-K0114 Specific Uses of the Slice Extension [David Singer, Thanos Leontaris, Alexis Tourapis (Apple)]
No presenter was available in HLS AHG meeting to present this contribution.

Hypothetical reference decoder (HRD) (5)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6496" JCTVC-K0126 AHG9: On HRD and related general issues [Y.-K. Wang (Qualcomm)]
This contribution reports a list of perceived problems or shortcomings related to the HRD specification and HRD related general topics, such as the description of the general decoding process, bitstream conformance requirements and level constraints. Proposed changes are summarized in the contribution document, and proposed spec text changes for the solutions, relative to JCTVC-K0030v2, are enclosed in the same zip file of the contribution document.
In revision 1 of this contribution, a condition is removed from the applicable_operation_points( ) syntax structure, as described in Section 3.
Definition of operation point (editorial), and inclusion of temporal ID in the definition (not necessarily editorial).
Definition of process for bitstream conformance tests (editorial).
Definition of each bitstream conformance test (editorial).
Use of HRD parameters of the SPS for the base layer or whole bitstream Decision: whole bitstream.
Mechanism for signalling a buffering period or picture timing SEI message that applies to an operation point with multiple values of nuh_reserved_zero_6bits. (This is related to K0180.)
Comment: Do we have a problem with "dangling" left-overs from bitstream extraction process?
MoreRevisit after off-line study.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6510" JCTVC-K0140 AHG9: Simple HEVC stream editing [K. Kazui, J. Koyama, S. Shimada, A. Nakagawa (Fujitsu)]
(The discussion of this contribution in Track A was chaired by M. M. Hannuksela.)
This contribution presents high-level syntax and semantics for HEVC bitstream editing. This is a follow-up proposal of JCTVC-J0137 at the 10th JCT-VC meeting.
This contribution contains three topics. The first topic is a modifier of cpb_removal_delay and dpb_output_delay. The value of the modifier is intended to be set by an editing process which removes leading pictures from the bitstream.
Alternative 1: It was suggested that the asserted problem the first proposal attempts to solve could alternatively be solved by including a buffering period SEI message in each DLP picture. However, the buffering period SEI in DLP pictures should not be used for buffer initialization. (Variation 2 of the contribution appeared to be somewhat similar to this alternative, but the signalling happens in the buffering period SEI message in the CRA/BLA picture.)
Alternative 2: It was suggested that another way to solve the problem would be to disallow the decoding order interleaving of TFD and DLP pictures.
Suggestion: add an informative note that recommends encoding the initial_alt parameters only when there is no decoding order interleaving of TFD and DLP pictures, or something in that spirit.
Decision (ed.): add an informative note such as drafted above.
The second topic relates to the restriction imposed when fixed_pic_rate_flag is equal to one. It is proposed that this restriction is not applied at a sequence boundary.
Decision: add another flag cvs_fixed_pic_rate_flag that applies only within a coded video sequence with the semantics proposed in the contribution.
The third topic is a SEI message for indicating a possible editing point in a bitstream. When the bitstream is chopped up into two pieces at the beginning of a coded picture associated with this SEI message, and the former piece is connected by another bitstream starting with a RAP picture, it is assured that resulting bitstream is still conforming to the restriction imposed when fixed_pic_rate_flag is equal to one.
It was clarified that an editing point SEI message is intended to reside in the last access unit of a GOP/SOP.
It was suggested that the SOP description SEI message can be used to conclude the last picture of a SOP.
It was commented that a splicer could conclude cpb_offset values proposed in the editing point SEI message from the buffering period and picture timing SEI messages.
No action taken.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6586" JCTVC-K0214 Early bumping [R. Sjöberg, J. Samuelsson (Ericsson)]
This contribution presents a proposed change in the output order decoder conformance section in Annex C of the HEVC specification. Currently, the bumping process is invoked after the first slice of a picture has been parsed. This contribution claims that this may cause unwanted output delay. The document discusses whether early picture output can be done directly after a picture has been decoded or not, but concludes that this is not possible according to the current HEVC specification since a decoder at that point in time can not know whether the following picture is a random access picture with no_output_of_prior_pics_flag set to 1 or not. To reduce the output delay in HEVC, this document proposes to enable output of pictures directly after decoding by adding the following text to section "C.5.3 Picture decoding, marking and storage":
When the number of pictures in the DPB that are marked as "needed for output" is greater than sps_max_num_reorder_pics[ HighestTid ] after the current decoded picture has been stored in the DPB, the picture in the DPB with the smallest value of PicOrderCntVal of all pictures in the DPB that are marked as "needed for output" is cropped, output and marked as "not needed for output".
Consider the relationship with picture timing conformance and the impact of sps_max_dec_pic_buffering[ i ], sps_max_num_reorder_pics[ i ] (before in decoding order, after in output order), and sps_max_latency_increase[ i ] (before in output order, after in decoding order), pic_output_flag, no_output_of_prior_pics_flag.
Revisit.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6595" JCTVC-K0221 On Sub-picture based HRD Buffering [S. Deshpande (Sharp)]
The CPB in the HRD of HEVC may operate at the access unit level or sub-picture level. Currently in HEVC draft only one CPB size parameter is signaled for each bitrate schedule. It is asserted that this is insufficient to support operation at both access unit level and sub-picture level.
This document proposes syntax elements and semantics to signal a CPB size and a CPB size scale parameter for sub-picture based CPB operation. These parameters are calculated using leaky bucket model of operation for HRD at sub-picture level.
Decision: Adopted.

VUI and SEI messages (17)
Video usability information (VUI) (2)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6523" JCTVC-K0152 Chroma sampling filter hint SEI [T. Chujoh (Toshiba)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6609" JCTVC-K0234 VUI Extension [M. Haque, K. Sato (Sony)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6651" JCTVC-K0263 Sample scale factor in VUI [A. Rodriguez (Cisco)]

Frame packing arrangement (FPA) SEI message and related (4)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6475" JCTVC-K0105 FPA SEI message modification [O. Nakagami (Sony), T. Suzuki (Sony), G. Ballocca (Sisvel Technology), V. Giovara (Sisvel Technology), P. Sunna (RAI), M. Arena (RAI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6486" JCTVC-K0116 2D compatible frame packing stereo 3D video [Xiaofeng Yang, Peiyu Yue, Yuanyuan Zhang (??)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6489" JCTVC-K0119 AHG9: Indication of frame-packed or interlaced video [Y.-K. Wang (Qualcomm)]
Note: revisit K0232 after this document.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6621" JCTVC-K0240 Frame packing arrangement SEI for 4:4:4 content in 4:2:0 bitstreams [Y. Wu, S. Kanumuri, S. Sadhwani, L. Zhu, S. Sankuratri, G. J. Sullivan, B. A. Kumar (Microsoft)]
Initially reviewed by BoG (K0339). Further study and a follow-up contribution with more results and test sequences was recommended.
Region of interest (ROI) SEI message and related (4)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6498" JCTVC-K0128 AHG9: Signalling of regions of interest and gradual decoding refresh [Y.-K. Wang (Qualcomm)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6590" JCTVC-K0218 Tile-based region-of-interest signalling with sub-picture SEI messages [Robert Skupin, Valeri George, ThomasT. Schierl (HHI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6629" JCTVC-K0247 Region of interest (ROI) SEI message [G. Dedeoglu, M. Budagavi (TI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6630" JCTVC-K0248 ROI tile sections [Yan Ye, Yuwen He, Yong He (InterDigital Communications), Michael Horowitz (eBrisk Video)]

Other SEI messages (7)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6487" JCTVC-K0117 Parameter ID change information SEI for bitstream splicing [Xiaofeng Yang, Peiyu Yue, Yuanyuan Zhang (Huawei??)]
Initially reviewed by BoG (K0339). No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6497" JCTVC-K0127 AHG9: Signalling of bitstream and elementary stream properties [Y.-K. Wang, A. K. Ramasubramonian (Qualcomm)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6501" JCTVC-K0131 Deblocking filter display preference SEI message [Alexis Tourapis, Athanasios Leontaris (Apple)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6511" JCTVC-K0141 AHG9: Low delay display hint SEI [K. Kazui, J. Koyama, S. Shimada, A. Nakagawa (Fujitsu)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6512" JCTVC-K0142 AHG9: Modification of SEIs specified in AVC [K. Kazui, J. Koyama, S. Shimada, A. Nakagawa (Fujitsu)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6576" JCTVC-K0205 TL0 index SEI message [J. Boyce, D. Hong, W. Jang(Vidyo)]
(This was initially reviewed in the AHG9 meeting.)
It is proposed to include a TL0_index SEI message in the HEVC base specification, for improved error resiliency when temporal scalability is used. The proposed SEI message is similar to that used in the tl0_dep_rep_index SEI message in SVC, with revised syntax and semantics in order to better align with the HEVC base specification design.
It was noted that this is related to K0166 and K0219.
It was remarked that in Daegu we actually expressed an intent to have the TL0_index SEI message in the HEVC design, based on D082 but did not follow through on that thus far.
The proposed normative increment-by-one behaviour was discussed in relation to both syntax elements of the proposed SEI message. It was suggested that some operations, such as removing a non-reference picture or splicing bitstreams, would violate this constraint, so the normative nature of the constraint was questioned. Suggestions included eliminating the normative constraint on rap_idx behaviour and making the tl0_idx increment in the same way that frame_num did in AVC (i.e. increment relative to the previous TL0 picture that was not a non-reference picture for its temporal layer and was not a leading picture).
It was remarked that the RPS also enables picture loss detection.
The HLS AHG suggested to revisit this contribution after offline work to consider these issues.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6649" JCTVC-K0262 AHG9: NAL Packet Priority SEI Message [E.-S. Ryu, Y. Ye, Y. He, Y. He (InterDigital Communications)]

Parameter sets in 3D and SVC extensions (10)
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6540" JCTVC-K0169 AHG 9: On layer ID partition in VPS [Hendry, B.Jeon (LG)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6575" JCTVC-K0204 VPS syntax for scalable and 3D extensions [J. Boyce (Vidyo)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6577" JCTVC-K0206 VPS support for out-of-band signaling and hybrid codec scalability [J. Boyce, D. Hong, W. Jang, S. Wenger(Vidyo), A. Luthra (Motorola)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6597" JCTVC-K0223 On Video Parameter Set [S. Deshpande (Sharp)]
In future extensions of HEVC, the nuh_reserved_zero_6bits in the NAL unit header are anticipated to be used as a layer ID with VPS signalling information that identifies the meaning of those bits. In the previous meeting various proposals for signalling information about these bits were proposed and were categorized into so-called "Approach 1" and "Approach 2" categories. This document proposes a method for signalling scalability information in the VPS about the reserved_zero_6bits in the NAL unit header. Syntax and semantics are proposed which are applicable to both Approach 1 and Approach 2 categories. It is asserted that the proposed approach overcomes drawbacks of the existing approaches and enhances the merits of them. Revisit in the context of of parameter set designs for extensions.
An additional separate aspect of this document proposes signalling a different syntax element in place of nuh_temporal_id_plus1 syntax element for VPS NAL unit type. (A revision of this document adds a variant syntax structure (variant A2) for one of the proposals in the original document.)
This scheme is similar in spirit to other proposals defining NUT-dependent parsing of the temporal ID (e.g. K0219). See notes relating to K0219. No action taken on the second aspect.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6603" JCTVC-K0228 Proposal to Video Parameter Set and its Extension [T. C. Thang (UoA), J. W. Kang (ETRI), H. Lee, J. Lee, J. S. Choi (??)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6606" JCTVC-K0231 VPS syntax re-ordering for easy access of extension parameters [M. Haque, K. Sato (Sony)]
[Move to syntax cleanup?]
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6608" JCTVC-K0233 VPS Extension [M. Haque, K. Sato, A. Tabatabai (Sony)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6664" JCTVC-K0274 VPS extension design [M. M. Hannuksela (Nokia)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6666" JCTVC-K0276 Parameter set design for HEVC extensions [ThomasT. Rusert (Ericsson)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6667" JCTVC-K0277 Inter-layer SPS prediction for HEVC extensions [ThomasT. Rusert (Ericsson)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6673" JCTVC-K0283 Video pParameter sSet extension design [Robert. Skupin, Valeri. George, Thomas. Schierl (HHI)]

Quantization
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6482" JCTVC-K0112 Worst-c Case DQP fFix [G. Van der Auwera (Qualcomm), R. Joshi (Qualcomm), M. Karczewicz (Qualcomm), P. Kapsenberg (Intel)]
This contribution claims that the adopted proposal JCTVC-I0219 while being an important solution to enable CU-level processing does not alleviate the worst case that would only be caused by a specially designed evil bitstream. Two solutions are proposed. The first solution stores QP per 8x8 region, while the second solution signals QP delta at the beginning of the coding unit depending on the no_residual_syntax_flag for both inter- and intra-coded CUs.
First solution: Low impact on coding efficiency
Second solution: about 0.2-0.3% loss
Two experts mention that with LCU based pipelining, there is no issue.
No support by other experts no action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6515" JCTVC-K0145 Consistent chroma QP derivation in deblocking and inverse transform [W. Wan, T. Hellman (Broadcom)]
This contribution recommends changing the chroma QP derivation process in the deblocking process to make it consistent with the QP derivation process used in the inverse quantization process. Specifically, it proposes to include the chroma QP offsets and QpBdOffset in the chroma block edge filtering process. The contribution also proposes to remove slice-level chroma QP offsets, as it claims that these add a storage burden to single-pass deblocking implementations.
Third solution: convert to chroma QP first (as in inverse transform) and then average (requires additional storage).
Related: K0220, some similarity with solution 2. (but K0220 does not remove the slice-level offset but just ignores it in deblocking)
Q: Is there a problem at all? Likely in case of large QP offsets
Removal of slice-level QP offsets would be undesirable e.g. in case of rate control or picture mosaics compiled from multiple tiles.
No action (considering simlarity with JCTVC-K0220 which may achieve this in a more desirable way).

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6532" JCTVC-K0161 Syntax issues and quantization groups [C. Fogg (??)]
Delta Qp (cu_qp_delta_abs, cu_ap_delta_sign) is signalled in the transform_unit() but applies to the quantization group of CUs due to (1) the depth restriction signalled by diff_cu_qp_delta_depth (2) split_cu_flag and split_transform_flag being the first respective syntax elements in coding_quadtree and transform_tree (3) and delta Qp only having meaning when there are coded coefficients present. This however creates the possibility of misunderstanding to implementers that deltaQp applies only to that TU and possibly TUs that follow rather than the entire CU tree at depth diff_cu_qp_delta_depth (Log2MinCuQpDeltaSize) as intended by the specification. To avoid this high potential for conformance mismatch, this proposal suggests that all CUs, regardless of CU tree depth, signal Delta Qp when cu_qp_delta_enabled_flag = 1 and encoders optimize RD to signal Delta Qp = 0 when too costly at some arbitrary depth with each coding_tree().
No concrete results
Opinion of experts: Nothing is really broken, but some aspects in the context of QP coding could might been done cleanermore cleanly.
No action.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6559" JCTVC-K0188 On the derivation of Chroma QPs [E. François, P. Onno, C. Gisquet, G. Laroche (Canon)]
This contribution proposes a slight modification of the chroma QP derivation in order to simplify the design and to give more flexibility for controlling the chroma QP.
In a first proposal, it is suggested to replace the table used in the derivation of chroma QP values from luma QP by a generic equation which reproduces very closely the table values. This change enables to remove one table from the specification. Results on common test conditions reportedly show a small gain in chroma, with a slight loss in luma.
In a second proposal, it is suggested to make this equation more generic by introducing two new control parameters that enable to accurately control the link between luma and chroma QPs. It is reported that these parameters are not redundant with the existing parameters cb/cr_qp_offset and have a different impact on the luma-chroma QP relation. The finer chroma QP control gives more flexibility, in particular for local QP adaptation which is required for fine quality control applications. Results on common test conditions are presented to show the impact of these new control parameters.
Proposal 1 would allow replacing the mapping table by logic (which is already possible with current table, but only piece-wise)
Proposal 2 is a larger change, function with starting point and slope of the high-QP range
Not clear what benefit of proposal 2 would be (not visible by PSNR, as the gain in chroma comes with a loss in luma). Further, if an implementer wants to do it, it could already be done with quant matrices.
Proposal 1: The benefit is minor, no need to change.
No action.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6668" JCTVC-K0278 Cross-check of K0188 [Philippe Bordes, Philippe Salmon, Pierre Andrivon (??)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6742" JCTVC-K0336 Cross-check report of JCTVC-K0188 [J. Xu, S. Kanumuri (Microsoft)] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6709" JCTVC-K0315 On default scaling list values [M. Naccari, M. Mrak, A. Gabriellini] [late]
Default scaling lists, also denoted as default quantisation matrices, are integral part of the latest version of HEVC draft specification. The usage of these scaling lists in the HEVC codec may improve the perceived video quality by exploiting some properties of the human visual system. This contribution describes an experiment which evaluates the impact of the default quantisation matrices in HM-8.0 codec. Informal visual tests have been carried out and PSNR and bitrate computed. The obtained results show that the overall impact on the quality of reconstructed videos seems to be minimal and therefore the benefits of having the default scaling lists remain unclear.
The contribution shows that the benefit of current default matrices in terms of visual quality is minorr
The solution suggested (defining flat matrix as default) would be redundant with the scaling list present flag in SPS.
Default matrix can be enabled at picture level may be useful in terms of rapid rate rate control.
No consensus - no action on replacing default matrix by flat matrix, stability of design.

Entropy coding
Transform coefficient coding
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6502" JCTVC-K0132 Unified coefficient scan for 8x8 TU [C.-W. Hsu, T.-D. Chuang, Y.-W. Huang, S. Lei (MediaTek)]
In HM-8.0, three scan patterns including diagonal, horizontal, and vertical are used for 8x8 transform units (TUs) when mode dependent coefficient scan (MDCS) is applied. The scan patterns can be divided into scanning across coefficient groups (CGs) and scanning within CGs. In this contribution, the scanning order across CGs of horizontal scan is unified to be the same as those of vertical and diagonal scans. Simulation results reportedly show no significant differences in BD-rates and run times in comparison with HM-8.0.
Not seen as a big deal no change at this late stage
Another advantage of the current design is that the horizontal and vertical cases are exact transposes of each other (when the whole 8x8 block is considered)
No action.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6636" JCTVC-K0252 Cross check of MediaTeks proposal JCTVC-K0132 [J. Kim, C. Kim (LGE)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6658" JCTVC-K0270 Unification of context modeling methods for large transform units for coding significant coefficient flags [S.-T. Hsiang (MediaTek)]
In the 10th JCT-VC meeting in Stockholm, it was adopted to employ the same set of the context templates used by the 16x16 and 32x32 transform blocks (TBs) for entropy coding significant coefficient flags in the 8x8 TBs. This contribution proposes the modified context modeling methods for the 8x8 TBs in order to further unify the context modeling schemes for the 8x8, 16x16 and 32x32 TBs. The proposed modifications remove the need to reference the scan order index for context selection and further reduce the number of the modeling contexts for the 8x8 TBs. Simulation results reportedly show that the proposed method with context reduction by 6 increases overall average Y BD rate by 0.03%, 0.02%, 0.02%, 0.03%, 0.00%, and -0.02% for AI Main, RA Main, LB Main, AI HE10, RA HE10, and LB HE10, respectively, under the common test conditions.
Method 1: Same set of contexts shared by the 8x8 Luma TBs in diagonal and non-diagonal scans, reduce number of contexts by 6
Method 2: Same set of contexts shared by Luma 8x8/16x16/32x32 high-freq. sub-set, Same set of contexts shared by Chroma 8x8 TBs and 16x16/32x32 TBs, reduce number of contexts by 12

Benefit not large stability of design has higher priority
No action.

Note: Current number of HEVC contexts is approx. half relative toof AVC.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6718" JCTVC-K0323 Cross-check of context modeling unification for large transforms significance coefficient flags (JCTVC-K0270) [J. Sole (Qualcomm)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6659" JCTVC-K0271 Withdrawn

Intra prediction and intra mode coding
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6509" JCTVC-K0139 Contouring artefact and solution [T.K. Tan, Y. Suzuki (NTT Docomo)]
Reviewed after subjective viewing (BoG K0359)
This contribution reports the problem of visible contouring artefacts found in some sequences under the common test conditions. This contribution further suggests that the problem is due to the propagation of blocking artefact from the reference samples during the process of creating the intra predicted sample array predSamples in the 32x32 blocks. The contribution proposes a change to avoid this artefact by replacing the intra smoothing filter with a bi-linear interpolation of the reference samples in the 32x32 intra prediction when the conditions for contouring artefact is detected. This modification is reported to reduce the contouring artefacts without causing any other subjective artefacts and reportedly has no significant impact in the average BD rate or simulation time for all the common conditions settings.
Effect appears in flat areas with some motion e.g. shadow, present down to QP 27.
Consequences: Requires checking another condition: if 32x32 block, difference of edge pixels below threshold? Then invoke a bilinear interpolation between boundary samples instead 121 filter
Q: Could this be solved by a more intelligent coder that prevents usage of directional modes in flat areas and use planar mode or DC mode instead. The cross-checker tried something like this but this produced other artifacts.
Q: One expert asks whether that the problem could eventually be solved by encoder-only solution inserting few DCT coefficients?
One expert mentions that the threshold should be dependent on bit depth. However, the problem has so far been shown to exist for 8 bit video, and we are currently defining an 8 bit profile.
Decision: Adopt K0139, with enabling flag at SPS
Some experts pointed out that it might be worthwhile to be applied to 16x16 in cases where max TU size is 16. Revisit: Provided that evidence is shown by additional tests, extend to 16x16 in cases where max TU size is 16.
To be reviewed after subjective viewing (BoG)

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6549" JCTVC-K0178 Crosscheck of JCTVC-K0139: Contouring artefact and solution [K Sato (Sony)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6587" JCTVC-K0215 Cross-check of JCTVC-K0139 on Contouring Artefact and Solution W. Wan, P. Chen (Broadcom)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6703" JCTVC-K0310 Cross-check of JCTVC-K0139 (Contouring artefact and solution) [M. Budagavi (TI)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6526" JCTVC-K0155 Intra angular prediction blending [S. Matsuo, S. Takamura, H. Fujii, A. Shimizu (NTT)]
Authors unable to attend; presentation by cross-checker suggested.
(include abstract)
Explained by cross-checker:
Usage of two prediction reference (from left and above) with weighted superposition
Would imply additional multiplications
Overall gain 0.1 ... 0.2% (max 0.4% in some cases)
contribution for information
No action.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6680" JCTVC-K0290 Cross-check of intra angular prediction blending (JCTVC-K0155) [K. Kawamura, T. Yoshino, S. Naito (KDDI)] [late]

Transforms
Memory bandwidth reduction
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6471" JCTVC-K0101 Line Buffer Cleanup [P. Kapsenberg (Intel), W. Zhang (Intel)]
This contribution claims that the line buffer reduction technique adopted previously no longer has any benefit due to the removal of biprediction on 8x4 and 4x8 sized blocks. It is suggested that the relevant code and text is removed from the standard, which has the additional benefit of harmonizing the column buffer needed for in-loop filtering. This contribution includes a suggested HM-8.0 patch.
Following concerns are raised:
Could this be inconsistent with AMP cases of 4x16 and 16x4 which could be bi-directional?
The suggested approach might increase cache memory in software implementation (where no dedicated logic is used)
Except for that it is noted that the unification of horizontal and vertical boundaries is desirable
After some discussion, it is asserted that the problems mentioned above are likely not severe, as they would otherwise also exist for vertical boundaries
Decision: Adopt.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6474" JCTVC-K0104 Cross-verification of JCTVC-K0101 on line buffer cleanup [M. Zhou (TI)]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6514" JCTVC-K0144 Reduce worst-case memory bandwidth for SCU size larger than 8x8 [C. Rosewarne (CiSRA), M. Maeda (Canon)]
It is asserted that memory bandwidth for inter-prediction is a significant issue facing video decoder implementations. The adoption of prohibiting 4x4 inter PUs and restricting 4x8 and 8x4 PUs to uni-directional inter-prediction, applicable when the CU size is equal to the SCU size of 8x8, have to some extent alleviated this situation. This contribution proposes to apply these restrictions for any SCU size. It is asserted that larger SCU sizes may be desirable for larger frame sizes and that the proposed restrictions will assist these cases. Simulation results show luma 1.0% losses in RA_Main (0.6% in class A), 1.0% losses in RA_HE10 (0.6% in class A), 1.2% in LB_Main, 1.2% in LB_HE10 for PART_NxN removal from inter-prediction. Encoder run-times are reduced to 8890%.
Might be mainly helpful for extreme large resolutions
Would only help when an encoder selects SCU 16x16, but does not reduce worst case memory bandwidth in general
Transcoding from AVC might become more difficult.
No action.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6739" JCTVC-K0337 Cross-check of reduction of worst-case memory bandwidth for SCU size larger than 8x8 (JCTVC-K0144) [J. Sole (Qualcomm)] [late] [miss]

Alternative coding modes
I_PCM
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6645" JCTVC-K0258 I_PCM Signalling [M. Coban, M. Karczewicz (Qualcomm)]
Burst I_PCM method provides sending of I_PCM sample data of successive I_PCM at a coding quadtree level. An alternative I_PCM signalling that eliminates sending of number of subsequent I_PCM blocks ahead of PCM samples is proposed.
The suggestion is to send PCM blocks until the end of the CU once the IPCM mode is invoked. This gives up flexibility in not allowing arbitrary placing of IPCM blocks in the CTB. An example where such flexibility is needed is transcoding from AVC.
In the context of the presentation, it is mentioned that the main purposes of IPCM are weird content and over-run of CABAC. The question is raised whether it is then useful at all to make IPCM dependent provisions in de-blocking and SAO?
It is mentioned in the discussion that the current way of signaling IPCM is too complicated and has problems (as reflected by the tickets). Several experts suggest that signaling IPCM flag at CU level and omitting the num_subsequent_pcm would be simpler. This would mean going back to the version before the num_subsequent_ipcm syntax was introduced.
Decision: Simplify I_PCM signalling by removing the num_subsequent_pcm syntax element. (B. Bross to provide text, W. Wan will provide software).
This also resolves ticket 763.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6690" JCTVC-K0300 Crosscheck of I_PCM signalling in JCTVC-K0258 [C.-W. Hsu, Y.-W. Huang (MediaTek)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6585" JCTVC-K0213 AHG9: On Tickets 637, 763, and, 777 [K. Chono (NEC)]
This contribution reviews unclosed tickets 637, 763, and 777 related to I_PCM. Tickets 637 and 763 are editorial issues. Ticket 777 addresses the potential use of wrong combinations of pcm_enable_flag, log2_min_coding_block_size_minus3, and log2_min_pcm_coding_block_size_minus3 values. The issue is an encoder-side issue but can be solved by restricting the minimum CU size less than 64 when pcm_enable_flag is equal to 1. It is recommended that the issues are resolved during the 11th JCTVC meeting.
Solution to ticket 637: Agreed. May be sufficient to re-initialize the coding engine after the last PCM syntax element (not after every one). To be resolved in the editorial improvements of section 9.3.
Solution to ticket 777: Rather than making the suggested normative restriction, a note should be added to the semantics of pcm_enable_flag that its usage not meaningful when min coding block size is 64.
Tticket 763 resolved by decision recorded above in discussion of K0258.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6760" JCTVC-K0351 On num_subsequent_pcm specification [K. Chono, H. Aoki (NEC), W. Wan (Broadcom)] [late]
This contribution addresses a bitstream conformance issue of the current num_subsequent_pcm specification and suggests a solution avoiding misinterpretation of the concept. This contribution also highlights the potential misuse of num_subsequent_pcm in practice since there is no built-in mechanism preventing an encoder from sending an invalid value in that syntax.
It is recommended that JCT-VC review the suggested the solution and discuss the bitstream conformance issue.
No action.

Transform skipping
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6574" JCTVC-K0203 AHG9: A bug fix for scaling list signalling in SPS when transform skipping is enabled [A. Osamoto, M. Zhou(TI)]
In the current HM8.0 design, flat 4x4 default quantization matrices can be used for quantization of 4x4 TUs when transform skipping is used. However, when scaling_list_data() is called from SPS the default 4x4 quantization matrices are undefined because transform_skip_enabled_flag transmitted in PPS is unknown in SPS. In this case, when the quantization matrices (scaling_list_data()) are not carried in PPS (i.e. matrices from SPS are used) but transform skipping is enabled, the spec is broken because a decoder will inherit undefined 4x4 default quantization matrices from SPS for inverse quantization of 4x4 TUs. To fix the problem, it is proposed to insert an additional flag (sps_flat_scaling_list_enabled_flag) in SPS to enable signaling flat 4x4 default matrices in SPS.
An alternative solution to the problem is suggested to define a flat scaling matrix as the default.
Decision: Define 4x4 default scaling matrix by as flat.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6613" JCTVC-K0237 Rotation of Residual block for Transform Skipping in HM8 [D. He, J. Wang, G. Martin-Cocher (RIM)]
This proposal reports the performance of the technique described in JCTVC-J0093 in HM8.0, which rotates residual blocks by 180 degrees when transform is skipped. In common test conditions, the average BD-rates resulting from this change against HM8.0 anchor are (-"0.2%, -"0.1%, 0.0%, -"0.2%, -"0.1%, -"0.1%) for (AI-Main, RA-Main, LD-Main, AI-HE10, RA-HE10, LD-HE10). For Class F sequences, the average BD-rates are (-"1.4%, -"1.0%, -"0.5%, -"1.4%, -"0.9%, -"0.6%).
Result of -"1.9% overall is reported in lossless coding as additional result.
Subjective benefit? not known.
The contribution was already presented last meeting where it was not adopted.
The main purpose is coding efficiency which is small in common test conditions, but also for class F it is significantly lower than e.g. the gain that was achieved by transform skip.
According to the principle of not doing more than bug-fix changes and not introduce additional processing stages the proposal is not adopted.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6670" JCTVC-K0280 Cross-check report of JCTVC-K0237 [J. Xu (Microsoft)] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6626" JCTVC-K0245 Fix for residual coding of transform skipped blocks [K. Andersson, J. Ström (Ericsson)]
This contribution presents fixes in the residual coding of transform-skipped blocks to combat the different nature of the transform skip residual compared to transform coefficients: The addressing of the context for the coding of the significance flags is adjusted, the start-up context model for non-zero coefficient greater than 1 flags is adjusted and the coding of the reference position for the last coefficient position is adjusted. The contribution claims that the average gains for common conditions (excluding class F) is 0.0%, and that the average BDR gain for class F is 0.8%. By also turning on RDOQ for transform skipped blocks, the contribution claims that the gains become 0.1% (excluding class F) and 1.5% for class F.
The contribution also presents an alternative, namely to reverse the scan directions for coding of transform skip blocks. This is same as is done in JCTVC-K0237. Results are reported both for the case when RDOQ is turned off for transform skipped blocks and when it is turned on. For RDOQ turned off, the contribution reports that the gains for common conditions (excluding class F) is 0.1% and that the average BDR gain for class F is 1.0%. If RDOQ is turned on, the gains are reported to be 0.2% for common conditions (excluding class F), and 1.7% for class F.
The contribution also presents a combination of the alternatives, namely to reverse the scan directions for transform-skipped blocks and adjust the start-up context model for non-zero coefficient greater than 1 flags coding. With RDOQ turned off for transform skipped blocks, results are reported to be 0.1% for the common conditions (excluding class F) and that the average BDR gain for class F (only) is 1.3%. With RDOQ turned on for transform skipped blocks, results are reported to be 0.2% for the common conditions (excluding class F) and that the average BDR gain for class F is 2.0%.
The contribution also presents a combination of the alternatives with adjustment for lossless coding, namely to reverse the scan directions for lossless coded blocks (same as in JCTVC-J0237) and the coding of the reference position for the last coefficient position is adjusted. Results are reported for the common conditions (excluding class F) to be 0.9% and that the average BDR gain for class F is 1.1%. Corresponding gains in JCTVC-K0237 are 0.6% (excluding class F) and 1.0% for class F.
The contribution also presents an encoder-only modification to turn on RDOQ for transform skip. The gains are reported to be 0.1% compared to common conditions (excluding class F) and the average BDR gain for class F is reported to be 0.6%.
Decision (SW): Enable RDOQ on in TS.

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6759" JCTVC-K0350 Cross-check results of the entropy coding for blocks coded in the transform skip mode of Ericsson (JCTVC-K0245) [Matthias Narroschke, Semih Esenlik (Panasonic] [late] [miss]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6765" JCTVC-K0356 Crosscheck of alternative 3 in JCTVC-K0245 [J. An, S. Lei (MediaTek)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6646" JCTVC-K0259 Scaling list selection for transform skip mode [J. Lou, Y. Yu, L. Wang (Motorola Mobility)]
Resolved through decision that was made in the context of JCTVC-K0203.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6682" JCTVC-K0292 AHG9: Scaling list for transform skip [T. Suzuki (Sony)] [late]
Resolved through decision that was made in the context of JCTVC-K0203.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6684" JCTVC-K0294 Mirroring of Coefficients for Transform Skipping [R. Weerakkody, M. Mrak, A. Gabriellini (BBC)] [late] [late]
This proposal describes a modification to the ordering of coefficients within a residual block in the presence of transform skipping. Depending on the scanning order for the given block, the coefficients are rearranged relative to their original spatial positions. The rearrangement is achieved by mirroring the coefficients across one of the block diagonals. When the diagonal scan is used, mirroring across the antidiagonal is used, otherwise mirroring across the main diagonal (transpose) is used. In this way the distribution of significant coefficients is closer to the distribution in a case when transform is applied. Therefore the entropy coding may benefit from the new arrangement. The experiments show gains of 1.5% BD-rate for screen content coded with intra configurations and 1.1% BD-rate for screen content coded with random-access configurations. For Classes A-E the average gains are insignificant (0.0% to 0.2% BD-rate gain).
No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6688" JCTVC-K0298 Cross-check on Mirroring of Coefficients for Transform Skipping (JCTVC-K0294) [T. Tsukuba (Sharp)] [late]

Lossless compression
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6528" JCTVC-K0157 Lossless coding with residual sample-based prediction [Y. H. Tan, C. Yeo, Z. Li (I2R)]
This proposal describes a residue coding method for lossless intra coding in HEVC that incorporates sample-based prediction during the residual coding process. The proposed method does not modify the current intra prediction scheme and is implemented in a manner that is independent of intra prediction modes and color components. It is reported that the proposed scheme improves lossless intra coding performance by ~6.5%.
Secondary prediction with switchable sample-wise predictor applied to directional prediction residual.
It wais pointed out that at the decoder side this requires a recursive processing which could be undesirable.

No item for current action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6753" JCTVC-K0344 Cross-check of Lossless coding with residual sample-based prediction (JCTVC-K0157) [Wen Gao, Haitao Yang, Haoping Yu (Huawei)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6570" JCTVC-K0199 AHG7: Sample-based angular intra prediction for HEVC lossless coding [M. Zhou (TI)]
Efficient lossless coding is required for real-world applications such as automotive vision, video conferencing and long-distance education. This contribution reports the test results of the sample-based angular intra prediction (SAP) in the HM8.0 environment. The proposed sample-based prediction is exactly same as the HM8.0 block-based angular prediction in terms of prediction angle signaling and sample interpolation, requires no syntax or semantics changes, but differs in decoding process in terms of reference sample selection for interpolation. In the proposed method a sample to be predicted uses its adjacent neighboring samples for better intra prediction accuracy. Compared to the HM8.0 lossless coding method which bypasses transform, quantization, de-blocking filter, SAO and ALF, the proposed method provides an average gain (w/o Class F) of 7.0% in AI-Main, 6.9% in AI-HE10, 1.8% in RA-Main, 2.1% in RA-HE10, 1.5% in LB-Main, 2.2% in LB-HE10, 1.8% in LP-Main and 2.3% in LP-HE10. For class F sequences only, the average gain is 11.6% in AI-Main, 13.8% in AI-HE10, 6.8% in RA-Main, 9.0 % in RA-HE10, 5.4% in LB-Main, 7.7% in LB-HE10, 5.5% in LP-Main and 7.7% in LP-HE10. The SAP is fully parallelized on the encoder side, and can be executed at a speed of one row or one column per cycle on the decoder side.

No item for current action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6550" JCTVC-K0179 AHG7: Cross-verification report on JCTVC-K0199 entitled "Sample-based angular intra prediction for HEVC lossless coding" [K. Chono (NEC)]
Question in general: Is efficient lossless coding a relevant topic in the context of professional extensions? Lossless profile? Or mode that allows lossless decoding (most probably not real-time when a level/tier that is used has limited bit budget)? To be clarified with parent bodies.
Non-normative: Encoder optimization, decoder speed improvement, post filtering, loss concealment, rate control
Software
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6472" JCTVC-K0102 HM-8.0 code speedup [B. Li, H. Li (USTC)]
This contribution proposes several aspects to speed up the HM encoder and decoder. The modifications in the document do not include any normative changes and do not change the R-D performance. The experimental results show that the modifications in this document can save about 14% encoding time (RA_Main, RA_HE10, LB_Main, and LB_HE10) and about 10% decoding time on average.
Several suggestions: Hard-coded interpolation filter, loops unrolling, replace min/max by if/else, ...
Many of these suggestions depend on compiler quality.
In reference software, readability plays a more important role than runtime.
For encoder speedup, methods of fast decisions (motion/mode) would play a more important role.
No action.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6517" JCTVC-K0147 Cross-check of HM-8.0 code speedup (JCTVC-K0102) [Y. Chiu, W. Zhang (Intel)] [late]

Rate control
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6473" JCTVC-K0103 Rate control by R-lambda model for HEVC [B. Li, H. Li, L. Li, J. Zhang (USTC)]
This contribution proposes R-» model based rate control for HEVC. The proposed rate control algorithm is implemented on HM-8.0. Compared with the existing rate control algorithm in HM-8.0, when targeting the bitrate of HM-8.0 default anchor (without rate control), the proposed method obtains 0.42 dB ~ 1.12 dB Y PSNR gain for different cases. The bitrate errors (the difference of the target bitrate and the actual bitrate) of the proposed method, 0.09%~0.22% for different cases, are also much smaller than those of the existing rate control algorithm in HM-8.0, which are 0.16%~1.09% for different cases.
According to the results, the algorithm has much more stable behaviour than the current rate control in HM. Allows to constrain the variation of QPs on the picture.
Algorithm has problems in class F, assuming relative consistent behaviour with not too many scene changes.
Decision (SW): adopt
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6518" JCTVC-K0148 Cross-check of Rate control by R-lambda model for HEVC (JCTVC-K0103) [Y. Chiu, W. Zhang (Intel)] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6604" JCTVC-K0229 Improvement of the rate control in HM8.0 [J. Yoo, J. Nam, H. Choi, D. Sim (Kwangwoon Univ.)]
No presenter available Fri afternoon.
To be reviewed.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6685" JCTVC-K0295 Novel coding tree unit layer rate control for HEVC [Wei Wu, Bin Song (Xidian Univ.)] [late]
The contribution proposes a novel coding tree unit (CTU) layer rate control scheme for HEVC. In the proposed scheme, a method for determining QPs of the first frames in GOPs is presented, and then a modified strategy of allocating the target bits for frames is described, finally the QPs for CTUs in a frame are predicted based on a new RQ model, a DQ model, and the target bits for the remaining CTUs in the frame. Compared with HM-8.0 rate control, the average PSNR of reconstructed video can be increased by 1.10 dB, 0.67 dB, and 0.62 dB for RA-main, LB-main, and LP-main, respectively, and the smoother PSNR performances can be achieved.
No action.
Encoder optimization
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6488" JCTVC-K0118 Encoding complexity reduction by removal of some unnecessary CU segmentations and partition types based on spatial and temporal correlation [Xiaohai He, Guoyun Zhong, Yuan Li, Linbo Qing, Di Wu (Sichuan Univ.)]
No presenter available Fri afternoon.
To be reviewed.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6507" JCTVC-K0137 Parallelize encoder of HM reference software for Multi-Core/Cluster Environment [Daxin Guang, Pin Tao (Tsinghua Univ.)]
No presenter available Fri afternoon.
To be reviewed.
To be allocated | category not clear

Withdrawn and missing contributions
JCTVC-K0048 Withdrawn

JCTVC-K0051 Withdrawn

JCTVC-K0129 Withdrawn

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6505" JCTVC-K0135 AHG4: Independent parsing for WPP substreams [T.-D. Chuang, C.-W. Hsu, Y.-W. Huang, S. Lei (MediaTek)]
Withdrawn.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6648" JCTVC-K0261 Cross-verification of JCTVC-K0135 on Independent parsing for WPP substreams [M. Coban (Qualcomm)] [late]
Cross-check of withdrawn document.
JCTVC-K0282 Withdrawn

JCTVC-K0286 Withdrawn

JCTVC-K0293 Withdrawn

JCTVC-K0297 Withdrawn

JCTVC-K0334 Withdrawn

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6741" JCTVC-K0335 AHG4: Cross-check of independent parsing for WPP substreams (JCTVC-K0135) [T. Nguyen, D. Marpe, A. Henkel, T. Schierl, V. George (Fraunhofer HHI)] [late]
Cross-check of withdrawn document.
JCTVC-K0340 Withdrawn

Plenary Discussions and BoG Reports
Project development
BoGs
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6745" JCTVC-K0339 BoG report on general high-level syntax topics [M. M. Hannuksela (Nokia)]
See section REF _Ref337191773 \r \h 5.16.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6751" JCTVC-K0342 BoG report on subjective viewing set up for deblocking filter [T. Yamakage]
See section REF _Ref337893087 \r \h 4.1.1.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6763" JCTVC-K0354 BoG report on HEVC scalable extensions (draft) [Andrew Segall]
See section REF _Ref337893762 \r \h 5.7.1.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6768" JCTVC-K0358 BoG report on conformance testing [T. Suzuki] [miss]
See section REF _Ref337895037 \r \h 3.2.
HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6769" JCTVC-K0359 BoG Report on Contouring Artifact [Ali Tabatabai]
The BoG reviewed contribution JCTVC-K0139 and observed the HM8.0 encoded sequences and visual artifact was observed and verified in Class E sequences for random access (RA) as well as low delay (LD).
The JCTVC-K0139 was cross-checked by 3 other companies (JCTVC-K0178, JCTVC-K0215 and JCTVC-K0310). The objective results under common conditions were confirmed to have insignificant change when JCTVC-K0139 was applied.
From Track B presentation and discussions:
The BoG
Investigated and verified that the problem exists (class E sequences)
Tested solution offered (JCTVC-K0139) blind test with 35 viewers
Results indicate clear evidence that the contouring problem exists, and K0139 provides an appropriate solution.
Another suggestion was made in the BOG to apply to the blocksize max{MAX_TU_SIZE,16}
Further, the BOG suggested to make it switchable at SPS (see further disposition under JCTVC-K0139)

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6775" JCTVC-K0365 BoG report on range extensions [David Flynn] [late]

HYPERLINK "http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6777" JCTVC-K0367 BoG report on high level parallelization [Andrew Segall]
See section REF _Ref337191868 \r \h 5.16.7.

KXXXX BOG report on deblocking viewing
From Track B discussion where the BoG report was presented prior to upload:
Comparison was made versus anchor that is HM with max offsets
Q: Were data rates almost identical? Was not investigated.
6 cases (sequences@bitrates) were tested on 7 proposals test sessions lasted 35 minutes.
Only 1 case (Riverbed 32) where one of the proposals is slightly better than anchor with non-overlapping confidence interval.
2 cases (Riverbed 32 and 37) where one of the proposals (not the same as above) is better than HM with automatic adaptation of deblocking parameters.
Question is raised how the comparison would look like against HM without extreme settings? From previous meeting results, again only the Riverbed sequence showed difference without overlapping confidence intervals.
It was pointed out verbally that the problem may exist in other sequences, but none of these could be made available due to copyright restrictions.
One expert who participated pointed out that the test may have been lead to fatigue of participants due to its length, and also that no training had been performed before.
Conclusion: No conclusion about significance can be drawn. The visual results do not suggest any evidence about action.
Decision(SW): Adopt non-normative adaptation of de-blocking parameters (K0289). Not in CTC. The non-normative part of K0289 looks interesting but further investigation should be performed in AHG which parameters should be used default such that it might be activated in CTC by a later meeting.
Project planning
WD drafting and software
The following agreement was established: the editorial team has the discretion to not integrate recorded adoptions for which the available text is grossly inadequate (and cannot be fixed with a reasonable degree of effort), if such a situation hypothetically arises. In such an event, the text would record the decision of the committee without including a full integration of the available inadequate text.
Plans for improved efficiency and contribution consideration
The group considered it important to have the full design of proposals documented to enable proper study.
Adoptions need to be based on properly drafted working draft text (on normative elements) and HM encoder algorithm descriptions relative to the existing drafts. Proposal contributions should also provide a software implementation (or at least such software should be made available for study and testing by other participants at the meeting, and software must be made available to cross-checkers in CEs).
Suggestions for future meetings included the following generally-supported principles:
No review of normative contributions without WD text
HM text strongly encouraged for non-normative contributions
Early upload deadline to enable substantial study prior to the meeting
Using a clock timer to ensure efficient proposal presentations (5 min) and discussions

The document upload deadline for the next meeting was planned to be XX Jan. 2013.
As general guidance, it was suggested to avoid usage of company names in document titles, software modules etc., and not to describe a technology by using a company name. Also, core experiment responsibility descriptions should name individuals, not companies. AHG reports and CE descriptions/summaries are considered to be the contributions of individuals, not companies.
General issues for CEs
Because a draft design and HEVC test model (referred to as the HM) have now been established, group coordinated experiments are now referred to as "core experiments" rather than "tool experiments".
A preliminary CE description is to be approved at the meeting at which the CE plan is established.
It is possible to define sub-experiments within particular CEs, for example designated as CEX.a, CEX.b, etc., for a CEX, where X is the basic CE number.
As a general rule, it was agreed that each CE should be run under the same testing conditions using one software codebase, which should be based on the HM software codebase. An experiment is not to be established as a CE unless there is access given to the participants in (any part of) the CE to the software used to perform the experiments.
The general agreed common conditions for experiments were described in the output document JCTVC-F900.
A deadline of three weeks after the meeting was established for organizations to express their interest in participating in a CE to the CE coordinators and for finalization of the CE descriptions by the CE coordinator with the assistance and consensus of the CE participants.
Any change in the scope of what technology will be tested in a CE, beyond what is recorded in the meeting notes, requires discussion on the general JCT-VC reflector.
As a general rule, all CEs are expected to include software available to all participants of the CE, with software to be provided within two (calendar) weeks after the release of the HM 8.0 software basis. Exceptions must be justified, discussed on the general JCT-VC reflector, and recorded in the abstract of the summary report.
Final CEs shall clearly describe specific tests to be performed, not describe vague activities. Activities of a less specific nature are delegated to Ad Hoc Groups rather than designated as CEs.
Experiment descriptions should be written in a way such that it is understood as a JCT-VC output document (written from an objective "third party perspective", not a company proponent perspective e.g. referring to methods as "improved", "optimized" etc.). The experiment descriptions should generally not express opinions or suggest conclusions rather, they should just describe what technology will be tested, how it will be tested, who will participate, etc. Responsibilities for contributions to CE work should identify individuals in addition to company names.
CE descriptions should not contain verbose descriptions of a technology (at least not unless the technology is not adequately documented elsewhere). Instead, the CE descriptions should refer to the relevant proposal contributions for any necessary further detail. However, the complete detail of what technology will be tested must be available either in the CE description itself or in referenced documents that are also available in the JCT-VC document archive.
Those who proposed technology in the respective context (by this or the previous meeting) can propose a CE or CE sub-experiment. Harmonizations of multiple such proposals and minor refinements of proposed technology may also be considered. Other subjects would not be designated as CEs.
Any technology must have at least one cross-check partner to establish a CE a single proponent is not enough. It is highly desirable have more than just one proponent and one cross-checker.
It is strongly recommended to plan resources carefully and not waste time on technology that may have little or no apparent benefit it is also within the responsibility of the CE coordinator to take care of this.
A summary report written by the coordinator (with the assistance of the participants) is expected to be provided to the subsequent meeting. The review of the status of the work on the CE at the meeting is expected to rely heavily on the summary report, so it is important for that report to be well-prepared, thorough, and objective.
A non-final CE plan document was reviewed and given tentative approval during the meeting (with guidance expressed to suggest modifications to be made in a subsequent revision).
The CE description for each planned CE is described in an associated output document JCTVC-J11xx for CExx, where "xx" is the CE number (xx = 01, 02, etc.). Final CE plans are recorded as revisions of these documents.
It must be understood that the JCT-VC is not obliged to consider the test methodology or outcome of a CE as being adequate. Good results from a CE do not impose an obligation on the group to accept the result (e.g., if the expert judgment of the group is that further data is needed or that the test methodology was flawed).
Some agreements relating to CE activities were established as follows:
Only qualified JCT-VC members can participate in a CE
Participation in a CE is possible without a commitment of submitting an input document to the next meeting.
All software, results, documents produced in the CE should be announced and made available to all CE participants in a timely manner.
Alternative procedure for handling complicated feature adoptions
The following alternative procedure had been approved at the preceding meeting as a method to be applied for more complicated feature adoptions:
Run CE + provide software + text, then, if successful,
Adopt into HM, including refinements of software and text (both normative & non-normative); then, if successful,
Adopt into WD and common conditions.
Of course, we have the freedom (e.g. for simple things) to skip step 2.
Common Conditions for HEVC Coding Experiments
Preferred Common Conditions for experiment testing that are intended to be appropriate for both CEs and other experiments were selected by the group and described in output document JCTVC-F900.
Software development (to be updated)
The software coordinator had already started integrating bug fixes on top of HM 3.3 software, and had strongly recommended for proponents of adopted proposals to re-implement them in HM 3.3 and test in this environment before integrating them into HM 4.x. All tools were planned to again be thoroughly tested after integration in HM 4.x.
HM 4.0 should be available within 3 weeks after the meeting, and will be used for CEs. HM 4.1 is planned to be available 3 weeks later.
Subjective verification test plan
(after finalization of standard)
Establishment of ad hoc groups
The ad hoc groups established to progress work on particular subject areas until the next meeting are described in the table below. The discussion list for all of these ad hoc groups will be the main JCT-VC reflector ( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de).

Title and Email ReflectorChairsMtgJCT-VC project management (AHG1)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Coordinate overall JCT-VC interim efforts.
Report on project status to JCT-VC reflector.
Provide report to next meeting on project coordination status.G. J. Sullivan, J.-R. Ohm (cochairs)NHEVC Draft and Test Model editing (AHG2)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Produce and finalize JCTVC-J1002 HEVC Test Model 8 (HM 8) Encoder Description.
Produce and finalize JCTVC-J1003 HEVC text specification Draft 8.
Gather and address comments for refinement of these documents.
Coordinate with the Software development and HM software technical evaluation AhG to address issues relating to mismatches between software and text.B. Bross, K. McCann (cochairs), W.-J. Han, I. K. Kim, J.R. Ohm, K. Sugimoto, G. J. Sullivan, T. Wiegand (vicechairs)NSoftware development and HM software technical evaluation (AHG3)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Coordinate development of the HM software and its distribution to JCT-VC members
Produce documentation of software usage for distribution with the software
Prepare and deliver HM 8.0 software version and the reference configuration encodings according to JCTVC-J1100 based on common conditions suitable for use in most core experiments (expected within 3 weeks after the meeting).
Prepare and deliver HM 8.1 software (and additional "dot" version software releases as appropriate) and appropriate software branches that include additional items not integrated into the 8.0 version (expected within three weeks after the 8.0 software release).
Perform analysis and reconfirmation checks of the behaviour of technical changes adopted into the draft design, and report the results of such analysis.
Suggest configuration files for additional testing of tools.
Coordinate with HEVC Draft and Test Model editing AhG to identify any mismatches between software and text.F. Bossen (chair),D. Flynn, K. Sühring (vicechairs)NHigh-level parallelism (AHG4)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Study the implication of requiring the use of specific high-level parallelism tool(s) for very high resolution video to guarantee decoders can utilize parallel decoding, considering both single-core and parallel decoding architectures.
Identify and discuss issues relating to high-level parallelism.M. Horowitz and M. Zhou (cochairs) NHEVC conformance test development (AHG5)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Study the requirements of HEVC conformance testing to ensure interoperability.
Discuss the work plan needed to develop HEVC conformance testing.
Study potential testing methodology to fulfil the requirements of HEVC conformance testing.
Establish and coordinate bitstream exchange activities for HEVC.
Study to develop a potential set of HEVC conformance bitstreams.T. Suzuki (chair), C. Fogg, , W. Wan (vicechairs)NIn-loop filtering (AHG6)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Clean up and stabilize the HM software, the draft text and the HM encoder description on in-loop filtering.
Study and consider improvements to the default behaviour and adaptability controls of the deblocking filter.
Study and consider potential refinements of the adaptive loop filter (ALF).T. Yamakage and A. Norkin, (cochairs) NSupport for range extensions (AHG7)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Study aspects of the technical design and develop software relating to the support of non-4:2:0 chroma formats and bit depths beyond 8 bits, using J0191 and J0357 as the starting basis.
Assist and advise in the work of removing any implicit assumptions of 8-bit depth and 4:2:0 formatting from the current draft and software (where feasible).
Consider needs for lossless coding and screen content coding support in the range extensions.
Discuss and propose test conditions and test material for the development of the range extensions, using J0581 as the starting basis.
Study techniques for color conversion and resampling and their relationship to non-4:2:0 chroma coding, including consideration of techniques in J0127.D. Flynn (chair), P. Andrivon, E. Francois, K. McCann, M. Mrak, K. Sharman, K. Sugimoto, P. Topiwala (vicechairs)NReference picture buffering and list construction (AHG8)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Provide source code that enables HM encoding of all test cases described in JCTVC-J0513 and produce anchor data for experiments.
Study the loss resilience properties of reference picture handling and its support in the HM software.
Develop user-friendly tools for improving the control of picture referencing structures for the HM reference software.R. Sjöberg (chair), Y. Chen, Hendry, T. K. Tan, Y.K. Wang (vicechairs)NHigh-level syntax (AHG9)
( HYPERLINK "mailto:jct-vc@lists.rwth-aachen.de" jct-vc@lists.rwth-aachen.de)
Study NAL unit header, video parameter set, sequence parameter set, picture parameter set, and slice header syntax designs.
Study SEI messages and VUI syntax designs, including checking and fixing texts for SEI messages currently included by referring to the AVC specification.
Study the hypothetical reference decoder (HRD) syntax and operations and the related text for bitstream conformance and decoder conformance.
Work towards simplification and general minor cleanup of the high-level syntax.
Assist in software development and text drafting for the high-level syntax in the HEVC design.Y.-K. Wang (chair)Y (12 days before the October meeting)
Output documents
The following documents were agreed to be produced or endorsed as outputs of the meeting. Names recorded below indicate those responsible for document production.
[check/fix hyperlinks]
JCTVC-K1000 Meeting Report of 11th JCT-VC Meeting [G. J. Sullivan, J.-R. Ohm]
JCTVC-H1001 HEVC software guidelines [K. Suehring, D. Flynn, F. Bossen, (software coordinators)]
Remains valid
JCTVC-K1002 High Efficiency Video Coding (HEVC) Test Model 9 (HM 9) Encoder Description [K. McCann (primary), B. Bross, W.-J. Han, I. K. Kim, K. Sugimoto, G. J. Sullivan] (WG 11 N 1XXXX)
JCTVC-K1003 58abcdgpxz|~¥¦§ïåÛåÛÑÇå¾¸¯¦¸¸¸¸¸¯å{t{t{pibXHhMd
§hKÌh=êhëh=êhÄ#Èh0yúh=êh9]lh=êh¬æh=êhgbaJh=êh«võaJh=êhÏbÎaJh=êhÂÝaJh=êh¬æaJh=êhaJ
h0yúaJh=êhÏ>öaJh=êh5aJh=êhEå5aJh=êh9]l5aJh=êh¬æ5aJ jh=êh¿kÌUmHnHu"5b©ª«², ððáÔxk
¤öh=êhc+¾h=êh
@õ7¹ÖÞßèìùüöh=êh@=h=êhc+¾h=êhÖaxh=êh½b6h0yúh=êhöh=êhCùh=êh%Ih=êhºuVh=êh^Vh=êhTf*h=êhÏ>öh=êh@=h=êh^Vê*h=êh`¤nHtHh=êhM)ênHtHh=êh"KnHtHh=êhý|gnHtHh{ÔnHtHh=êh8[nHtHh=êhDrNnHtHh=êh>`¤aJh=êh©Y¾aJh=êh"KaJ'oVWWWW?X@XAXCXDXFXGXJXKXMXNXzYYýYþYZZ Z%ZW\k\!_"_£a¤a×aØaÙabb/b3b6b7b|b}b¯b÷ìãØÏÆ½Ï½Ï½Ï½Ï½ÏØÏ´Ï´Ï«ÏØÏ¢ÏÏzÏqÏqÏÏh=êh,~óaJh=êhô.¼0JaJjwh=êhô.¼UaJjh=êhô.¼UaJh=êh9®aJh=êh7ñaJh=êhá8SaJh=êh VaJh=êhL/jaJh=êhô.¼aJh=êhô.¼mH sH h=êh8[aJh=êhn:×nHtHh=êhn:×aJ)¾XzYY¬YÑYòYZ;ZaZ¬ZäZ['['\W\k\I]"_º_Ma£a|bùbúíúÒÒÒÒÒÒÒÒÒÒÒíúúúúú¿¿$
&F
ÆÐ8 ¤xa$gd,Z$
&F
ÆÐ8 Ðþ¤x^Ð`þa$gd,Z
$
ÆÐ8 a$gdô.¼gdô.¼¯b°b±b×bØbùbúbBcCcDcccccccc¢c´cµcñcòcóc#d$d:d;dtdudvd£d¤d¦dd¯d°d¿dfegekkïâ×âÎâÎ¾â×âÎµÎµÎ¬ÎâÎâ×âÎâÎâ×âÎÎÎzqzhh=êhÒE¦aJh=êh*e-aJh=êhá8SaJh=êhÇ>TaJj
h=êhô.¼UaJj0 h=êhô.¼UaJh=êhÎ;aJh=êhGbËaJj+h=êhô.¼UaJh=êhô.¼aJh=êhô.¼0JaJjh=êhô.¼UaJjRh=êhô.¼UaJ(ùb´c:d¿dfeUg·h+j kÚklooèpqýr¿tu@wbxnx§xìììçÞÞÞÞçÑÌç¿çç···¿±$gdô.¼$a$gdô.¼
$
ÆÐ8 a$gdô.¼gd9®
$
ÆÐ8 a$gd9®h^hgd¬J£gdô.¼$
&F
ÆÐ8 ¤xa$gd,Zk kÙkÚklçpèpq.q/q^q_q`qqqqªq«q×qØq
rrr2r3rerurzr{rür-s.sns÷îåÚÑÈ½´§´§§´´îvîfv[vRRîRîvîh=êh,~óaJh=êhô.¼0JaJjÒh=êhô.¼UaJjh=êhô.¼UaJh=êhÇ>TaJh=êhü0JaJjh=êhñO¶UaJjh=êhüUaJh=êhüaJh=êhô.¼mH sH h=êhcóaJh=êh9®aJh=êh9®mH sH h=êhX
*aJh=êhô.¼aJh=êhá8SaJ nsosps¤s¥sàsásttt,t-tht¾tuzvÑvÔvÕvÙvævw$w-w?w@wPwRwdwkwBxDxbxnx§xªx¸xïâ×âÎâÎ¾â×âÎµÎ¬£££££¬ÎÎÎÎtÎjah=êhJaJh=êhJ5aJh=êhô.¼mH sH h=êhÇ>TaJh=êhK|´aJh=êh"KaJh=êhÕi5aJh=êhÇz§aJh=êhÎl´aJh=êh^CaJj
h=êhô.¼UaJh=êhô.¼aJh=êhô.¼0JaJjh=êhô.¼UaJj«h=êhô.¼UaJ$¸x¹xºx¼xÉxÌxðxóx y
yyy0y4yYy]yyyy¡y¤yÂyÄyÓyÖyïyòymzozz÷îä÷ÚÑÇî÷î½´ª¡ª¡{r{r{rh_ULh=êh\méaJh=êh\mé5aJh=êhô.¼aJh=êhô.¼5aJh=êhX§aJh=êhX§5aJh=êh©VaJh=êh¶l aJh=êh¶l 5aJh=êh"KaJh=êh"K5aJh=êh¥*aJh=êh¥*5aJh=êhJ5aJh=êhpaJh=êhp5aJh=êhv@5aJh=êhJaJh=êhv@aJ§xºxÉxðxy0yYyy¡yÂyÓyïymzzA{W{e{{±{ ||aJh(*hmbaJjèh(*hóPÓUaJh(*hóPÓaJjh(*hóPÓUaJh(*hUaJh(*h§[¾aJådÂ`²kzÂ(ÒØÈ°°°°°° ° °°$$
&FÊþ¤1$^Ê`þa$gdin¬$$
&F¤1$a$gd@?XYZ]^`n|}ª÷îåØÏ¿Ø¹Øåî÷³÷¦¦¹¦÷³÷¦}¦¹¦÷tî³înet¦h=êhaJ
haJh=êhHP4aJjÜh=êhäEUaJj_h=êhäEUaJh=êhäEaJjh=êhäEUaJ
hin¬aJ
hg>aJjâh=êhSUaJh=êhSaJjh=êhSUaJh=êhº^aJh=êhÂÝaJh=êh|aJ'ª«¬¯°±²ÀÁÈÉËÍÓÔÕÖÝÞßøùúýþÿ>?AHIJcïâÜâÓÊÄ»µÊÄÊ¬µ£ÓwÓqkÄµÄbÄh¤@óhin¬aJ
hÂÝaJ
hu@aJjÖh8ÃUaJ
h8ÃaJjh8ÃUaJ
h;_aJh¤@óhHP4aJh=êhaJhb.}hÂÝaJ
haJh=êhin¬aJ
hin¬aJh=êhÂÝaJh=êhHP4aJ
hg>aJjh=êhäEUaJjYh=êhäEUaJ"cdehikyz ¡º»¼¿ÀÁÂÒâðòúûý !%&'(;=EGPòèâèÜÖÍÜÇÜ¾Üèâ±èâèÜ¨ÜÜÜÇÜ¾ÜèâèâèÜ¨Üwha# hlFaJha# h|aJjMh8ÃUaJ
hÓKñaJHhöj
ÇhôHaJh=êhin¬aJjÐh8ÃUaJh¤@óhin¬aJ
haJh=êh#TÔaJ
h#TÔaJ
hin¬aJ
h8ÃaJjh8ÃUaJjSh8ÃUaJ*PQjk{|¤¥¦§®¯°ÉÊËÏÐÑÒûòéÙéòÓòÊÄ»Äµ«¡Ó|Óo|Ó|iÄ_UÄ*hKÌhaJ*hKÌhin¬aJ
hÂÝaJjGh8ÃUaJjh8ÃUaJha# hÅ+OaJha# hé1?aJha# hlFaJ*hKÌhlFaJ*hKÌhÂÝaJ
hH3äaJha# hÂÝaJ
hin¬aJha# h|aJ
h8ÃaJjÊha# häEUaJha# häEaJjha# häEUaJ
&'(,-./RSU[\]fnv®÷ñçáÔçáçñËÂñÂ¸®¥ÂÂÂ¸®¥{neUjAha# hóPÓUaJha# hóPÓaJjha# hóPÓUaJha# hUaJha# hU{öaJ
h2aaJha# htbaJha# hHP4aJha# hlFaJ*hKÌhlFaJ*hKÌhÂÝaJha# hÂÝaJh¯lhin¬aJjÄh8ÃUaJ
h8ÃaJjh8ÃUaJ
hin¬aJh¤@óhin¬aJÒ/gÆ+qèBà-l¶ö,l« ' | çççç××××××Ç×·××Ç×·§$$
&F¤1$a$gd%t÷$$
&F¤1$a$gdp{$$
&F¤1$a$gdýW$$
&F¤1$a$gd%t÷$$
&FÊþ¤1$^Ê`þa$gd%t÷®¾¿ÃÄÅÆÜáðñóõ÷ýþÿ "#$()*+:?ABC÷êäêÛÒÉÀÉÀÉäÉ·®¨ääääym[m#Hh h
Ç jàðh³0h³0aJHh h
Çh³0aJ
h2aaJ
h?maJ
hFaJ
hÂÝaJj¾h8ÃUaJjh8ÃUaJ
hò$aaJhb.}hlFaJhb.}hÂÝaJh=êh'naJh=êhÂÝaJha# hÂÝaJha# hU{öaJ
h8ÃaJjha# hóPÓUaJha# h
QaJ!CLMfghnopq ¡º»¼ÂÃúðêÝð×ðúÑêË¿¿Ëêúr^Trjh³0UaJ&j¸Hh
h
Çh³0UaJ jHh
h
Çh³0UaJHh
h
Çh³0aJhÅLh³0aJcHdh
h
Çh2ah³0aJcHdhh
Ç#Hhh
Ç jàðh³0h³0aJHhh
Çh³0aJ
h?maJ
hÜ"9aJ
h8ÃaJj;hFUaJ
hFaJjhFUaJ
hÅLaJÃÄÝÞßåæ789?@T_`bdlmnìÝÆì·ì±«~«±xn±an[n±U«U«±[Kjh8ÃUaJ
h2aaJ
h8ÃaJj²hFUaJjhFUaJ
hÅLaJh(.h³0aJcHdhh
Ç#Hhh
Ç jàðh³0h³0aJHhh
Çh³0aJ
h?maJ
hFaJh8Ãh³0aJcHdh
h
Ç,j5hFh³0UaJcHdh
h
ÇhFh³0aJcHdh
h
Ç&jhFh³0UaJcHdh
h
Çn®¯°²»¼ÕÖ×ÝÞàìùúûüý "#$*+,.N_k«¬³´úíãúãÝ×ÝÑúÑÝÇÝºÇúÇÝ×´×´®ú®ãú¡ãúã®ÝÑÑÝãú|ãúãj¦h8ÃUaJhýWhýWaJh(.h(.aJ
h(.aJj)h8ÃUaJ
h~lWaJ
hî2raJj¬hFUaJjhFUaJ
h?maJ
h2aaJ
hFaJjh8ÃUaJj/h8ÃUaJ
h8ÃaJ0´¶·õöúûüþ!"#)*89;=FG`abhijklmª«ÅÉÌÍ×ÜÝæç úôëôúåßåúÕúÈÕßÕúåßåúÕú»ÕßÕúµúôë¬ëô¦¦ß¦wjhíKUaJjhíKUaJ
híKaJh0yúhíKaJh0yúhlaJ
h2aaJhýWhýWaJ
hî2raJj hFUaJj#hFUaJjhFUaJ
h8ÃaJ
h?maJh(.h(.aJ
h(.aJ
hFaJ.
& ' 3 5 6 8 > ? @ I J c d t u y z { | úðêäÛÒÉÀúÀ¶¬£tkúÀÉbúbXN*hKÌhóPÓaJ*hKÌhQ:1aJha# hQ:1aJha# h9aJjha# hP&UaJha# hP&aJjha# hP&UaJha# hHP4aJha# hlFaJ*hKÌhlFaJ*hKÌhÑ
aJha# hÑ
aJha# hÂÝaJh=êh(.aJh(.h(.aJ
h(.aJ
híKaJjhíKUaJ
h8ÃaJ ¡ º » Ë Ì Ð Ñ Ò Ô ñ ò ô ú û ¡¡¡¡ ¡!¡%¡&¡'¡J¡K¡T¡^¡_¡x¡y¡¡¡¡¡÷îáØÈ¿á¹áî°§¹§îv¹î§¹§îáØf]á¹áha# h9aJjha# hóPÓUaJjh©UaJjh©UaJ
h©aJ*hKÌhQ:1aJ*hKÌhÂÝaJha# hÂÝaJha# hQ:1aJ
h8ÃaJha# hÁQhaJjha# hóPÓUaJha# hóPÓaJjha# hóPÓUaJha# hHP4aJha# hJÛaJ$| Ó (¡¡É¡%¢x¢Ê¢££õ£K¤W¤Å¤Æ¤¥N¥a¥ïïïßïïïïïÖÖÑÉÉ¸³¢
Æ
hÐ8 ¦¤(¤(gd(.gd(.
Æ
hÐ8 ¦¤(¤(gd Ð$a$gdJgdÔ"ø $1$a$gd·Rù$$
&F¤1$a$gd@}aJh=êh7aJh~lWh#aJa¥o¥¥¥¥²¥³¥Ð¦æ§ç§¨©*©F©S©©½©ÿ©}ª¦ª«r«µ«÷÷÷÷÷æá×ææÒææææææææææÁ
Æ
hÐ8 ¦¤(¤(gd(. gd¤@ó $¤xa$gdAÏ gdp{
Æ
hÐ8 ¦¤(¤(gd Ð
&Fmgd(.´¥¦
¦¦¦¦6¦W¦_¦a¦v¦x¦¦¦¦¦¦¦¤¦¦¦´¦¶¦Î¦Ð¦å¦æ¦:§C§H§J§L§h§§¢§§§å§æ§ç§¨ïÚÃÚµïµ¤ï¤ï¤ï¤ï¤ï¤ï¤ï¤µykyygh
lMh..>hAÏH*aJmH sH hAÏaJmH sH hÚxhAÏaJhÚxhAÏaJmH sH hAÏhÚxhAÏ hÖhîh
lMaJmHnHsHtHh
lMaJmHnHsHtH,hdl@h
lM>*B*aJmHnHphÿsHtH)jhdl@h
lMUaJmHnHsHtH hdl@h
lMaJmHnHsHtH&¨ ¨x¨y¨¨¨¨Ù¨Û¨û¨ü¨©©F©U©`©e©f©i©r©©©«r«}«ô«û«¬¬¬êÙêÂê´Ù´Ù´¦´¢¢¢jYj hêpkh ÐaJmHnHsHtH)jhêpkh ÐUaJmHnHsHtHh=êh(.h(.*hp{h(.hç?XhsmÀh&ÔhÌ²hAÏh+
aJmHnHsHtHhsmÀaJmHnHsHtH,hp
hsmÀ>*B*aJmHnHphÿsHtH hp
hsmÀaJmHnHsHtH)jhp
hsmÀUaJmHnHsHtHµ«í«=¬ú¬:®¯®M¯t¯z¯¯«¯½¯¾¯l°°@±±3²d²îîéÜÜÜÌÀÀÀÀ³®
Æ
hÐ8 ¦¤(¤(gd Ð gdp{
Æ5-^-gd Ð
&Fn
Æ5gd(.
&Fn
Æ5û^ûgd(.
Æ5-^-gd(. gd¤@ó
Æ
hÐ8 ¦¤(¤(gd(.¬¢¬£¬¤¬Ô¬Ö¬ø¬ú¬½¯¾¯¿¯°°#°$°%°.°O°X°Z°a°c°i°l°éÔÆµÆµÆ¨r[MrM*B*aJmHnHphÿsHtH hêpkh ÐaJmHnHsHtH)jhêpkh ÐUaJmHnHsHtH*h=êhsmÀ*hV2Îh(.h(.hV2Îh(.høøh
`h&Ôd²¡²b³c³´u´´´ä´µ¿µÀµ¶¶»¶\·~··f¸îîÝØÓËËËÆÆÆÁ°° gdp{
Æ
hÐ8 ¦¤(¤(gd&(
Æ
hÐ8 ¦¤(¤(gd@,ñ gd7Sªgd÷Eh
&Fmgd(.gd(. gd(.
Æ
hÐ8 ¦¤(¤(gd Ð
Æ
hÐ8 ¦¤(¤(gd(.ÀµÁµ¶¶%¶&¶'¶>¶`¶k¶m¶|¶~¶¶¶¶¶¥¶§¶³¶´¶¶¶º¶»¶~···Ø·Ù·ä·å·êÙêÂê´Ù´£Ù£Ù£Ù£Ù£Ù£´Ù{j{S{,h3h
lM>*B*aJmHnHphÿsHtH h3h
lMaJmHnHsHtH)jh3h
lMUaJmHnHsHtHh=êh#TÔh&(hsmÀh#TÔ h]_h7SªaJmHnHsHtHh7SªaJmHnHsHtH,hÅ^Úh7Sª>*B*aJmHnHphÿsHtH hÅ^Úh7SªaJmHnHsHtH)jhÅ^Úh7SªUaJmHnHsHtHå·æ·1¸3¸d¸e¸f¸Û¸ô¸9¹É»&½'½?½L½½¾¾¤¾ª¾Ä¾Ë¾G¿¿¿¿¿ï¿ð¿û¿ü¿ý¿PÀTÀ ÀòáòáÓòÌÈÌÈÌÈÌÈÌÈ½µµµµ¢|eW|W|hwÔaJmHnHsHtH,hÈHýhwÔ>*B*aJmHnHphÿsHtH hÈHýhwÔaJmHnHsHtH)jhÈHýhwÔUaJmHnHsHtHh=êhsmÀnHtHh91nHtHhµznHtHhp{hµznHtHh(.h×qh(.hAÏaJmHnHsHtH h3h
lMaJmHnHsHtHh
lMaJmHnHsHtH"f¸:¹îº½ë½¾¿¦ÀÌÂ`ÃOÅnÆ¯ÆHÇIÇÇÈ#ÈRÈÉÈ÷È½ÉÊÊîîîîîÝØÓÓÓÓÓÓÓÓÓËËËËÓÓÆgd÷Eh
&Fogd(.gd(. gdp{
Æ
hÐ8 ¦¤(¤(gd@,ñ
Æ
hÐ8 ¦¤(¤(gd(. À¢À¤À¦ÀøÀÁ Á9ÂÂÂ¢Â¯Æ½Æ¾ÉÊÊÊÊÊ-Ê.ÊMÊNÊ¦Ê§ÊòáòÖÎÖÎÖÎÖÎÂÎ¶Î« wbQb h6hamaJmHnHsHtH)jh6hamUaJmHnHsHtHhammH sH h=êh'¯mH sH h=êhb4mH sH h=êhênmH sH h=êh·CmH sH h÷EhhnènHtH*hp{h(.nHtH*hV2Îh(.nHtHh(.nHtHh×qh(.nHtH hÈHýhwÔaJmHnHsHtHhwÔaJmHnHsHtHÊ.ÊMÊúÊûÊË¸ËÈËÉËêËÌÂÌÍ«ÍÎHÎòÎÏÏÌÏÐUÐúõðëæáæëÜ×ÒÒÒÒÅÀ»»»»»gd³0 gd!C
gd|c¡oÆ k
Çd&Fgd|c¡ gd|c¡gdf5 gd7Sªgd7Sªgdam gdamgdamgdÔ"ø§Ê²Ê³Ê´Ê¾ÊßÊøÊúÊûÊËËdËeËpËqËrË|ËË¶Ë¸ËÈËÉËéËêËéÔÆµÆµÆ±pbbb[PBHh k
Çh&Y~mH sH h=êh&Y~mH sH h¤@óh7Sªh7SªaJmHnHsHtH,hÅ^Úh7Sª>*B*aJmHnHphÿsHtH hÅ^Úh7SªaJmHnHsHtH)jhÅ^Úh7SªUaJmHnHsHtHh7Sªham h6hamaJmHnHsHtHhamaJmHnHsHtH)jh6hamUaJmHnHsHtH,h6ham>*B*aJmHnHphÿsHtHêËëËCÌDÌOÌPÌQÌXÌtÌ}Ì~ÌÌGÍHÍhÍiÍuÍvÍGÎHÎäÍä°äÍndUdUFUd?h|c¡h|c¡Hh k
ÇhM
Rh|c¡0JjHh k
Çh|c¡UHh k
Çh|c¡-Hh k
ÇhÅ^Úh|c¡CJmHnHsHtH-Hh k
Çh]_h|c¡aJmHnHsHtH'Hh k
Çh|c¡aJmHnHsHtH9Hh k
ÇhÅ^Úh|c¡>*B*aJmHnHphÿsHtH-Hh k
ÇhÅ^Úh|c¡aJmHnHsHtH6jHh k
ÇhÅ^Úh|c¡UaJmHnHsHtHHÎIÎ¡Î¢ÎÎ®Î¯ÎÐÎÒÎÛÎÝÎðÎòÎVÑ^ÑhÑþÒÿÒÓÓÓÓjÓkÓêÙêÂê´Ù´£Ù£´zpzlWFW hci_h*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHhf5mH sH h*B*aJmHnHphÿsHtH hKf@h±éaJmHnHsHtH)jhKf@h±éUaJmHnHsHtHhamhamaJmHnHsHtH,hKf@ham>*B*aJmHnHphÿsHtH hKf@hamaJmHnHsHtH)jhKf@hamUaJmHnHsHtHh±é¢ø¥ø¦ø²ø³ø¹øºø¾ø¿øÉøÊøÛøÜøÝø5ù6ùAùBùCùsùù²ù´ùµù¶ùúúõêõêõêõêõâ×Ïº©ºº©©kZk h° DhFwaJmHnHsHtH)jh° DhFwUaJmHnHsHtHh!Ch!CaJmHnHsHtH,hci_h!C>*B*aJmHnHphÿsHtH hci_h!CaJmHnHsHtH)jhci_h!CUaJmHnHsHtHhgnmH sH h=êhgnmH sH hÅLmH sH h=êhº^mH sH h=êh=ðmH sH úúúúcúhúpúrúúúúúàúáúìúíúîúXûyû§û©ûªû«ûéÔÆµÆ¤µ¤Æ zcUzUzUQ*B*aJmHnHphÿsHtH h° DhøR«aJmHnHsHtH)jh° DhøR«UaJmHnHsHtHhFw hWhFwaJmHnHsHtH h° DhFwaJmHnHsHtHhFwaJmHnHsHtH)jh° DhFwUaJmHnHsHtH,h° DhFw>*B*aJmHnHphÿsHtH«ûüüüüüOüQü\übüoüpüwüxüyüüüüü£ü»ü¼ü½üïÚÃÚµïµ¤¤µµvnvnvc[F)jh&.ñhøR«UaJmHnHsHtHhâmH sH h=êh»;mH sH hØÍmH sH h=êhâmH sH h!Ch
lMhwÔaJmHnHsHtHh#TÔaJmHnHsHtH hÖhîh
lMaJmHnHsHtHh
lMaJmHnHsHtH,h6h
lM>*B*aJmHnHphÿsHtH)jh6h
lMUaJmHnHsHtH h6h
lMaJmHnHsHtHyü¼üýý¯,°,±,²,´,µ,·,¹,¼,¾,Å,Ç,È,Ý,è,é,ê,-- ---.-/-1-*B*aJmHnHphÿsHtH h}kÉhV¶aJmHnHsHtH)jh}kÉhV¶UaJmHnHsHtHh!Ch(.mHnHsHtHh(.mHnHsHtHh&Eôh(.mHnHsHtH&ùSýST*TLTrUkW¹Y\\¸\Ã\ä\&]D]E]Ý]é]^L_¬_Õ_Ö_³`@fúúúõðèèèèèèèèèõããÛÛÛÛõðÓ$a$gd>TJ
&Fvgd(.gd(.$a$gd+cã gdV¶gd!Cgdæb=øSTTT)T*TJTKTLTMT¥T¦T±T²T³TU UUU"U$U,U.U:U*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh!Ch!CmHnHsHtHh(.h(.mHnHsHtHh(.mHnHsHtHh+cãmHnHsHtHhæb=mHnHsHtH!VV)V0VWWjWkW®WµWÆWÓW_X#YrY{Y¸Y¹YìYöY[&[¶[W\z\{\\\\\\\\·\¸\&]D]E]½]Ü]Ý]ê]^ñæÜæÏæÜæÜæÜæÁæÜæÜæÜæÜæ³æ³¦³¦³¦³ÜÜwkwkwh(.mHnHsHtHheçh(.mHnHsHtHh!CmHnHsHtHh>TJaJnHtHh¸b6aJnHtHh95h+cãaJnHtHh95h+cãaJnHo(tHhðtgh+cãaJnHo(tHhïWªh+cãaJnHtHh+cãaJnHtHh+cãaJnHo(tHh~£h+cãaJnHo(tH*^^,_L_«_¬_Ô_Ö_×_/`0`;`TJmHnHsHtHh=wh>TJaJh=wh>TJnHtH h«8ÆhV¶aJmHnHsHtHhV¶aJmHnHsHtH,hci_hV¶>*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh!Ch(.mHnHsHtHheçh(.mHnHsHtHh(.mHnHsHtH@fPfdfÙfõfg&hiØmòmCnn¼nénoeoÐopp#qqÎrsEs súúúúúúõíúúúúúúúúèúõààÕÕÕ$
&Fka$gd«}$a$gd«}gdUB$a$gd-õ gdV¶gd!CÀfØfõf%h&h'hhhhhhÎhÐh×hÙháhãhèhêhðhòhùhûhiiii2i:iMiTiniÊiÕiäiôèôÙÄ³ÄÄ³}³}³}³}³}³}³}sjsjsjs]h}h-õKHPJaJh}h-õaJh}h-õaJo( h«8ÆhV¶aJmHnHsHtHhV¶aJmHnHsHtH,hci_hV¶>*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh!Ch-õmHnHsHtHh>TJmHnHsHtHh-õmHnHsHtH"äiåiêiëiôiùijj5j6j¶jêj@kkkkÂkâkelhlmlplvlllll¬lµl¹l»l¾lÁlÛlÞlm mKmPmmm×mØmóæóæóæ×Ê×Ê×Ê×¾«×«ÊóóÊ«Ê×Ê×æóóvh}h-õaJnHtHh}h-õKHaJh-õKHaJnHo(tHh}h-õKHaJnHo(tH$h}h-õB*aJnHo(phtHh-õB*aJo(phh}h-õB*aJphh}h-õB*aJo(phh}h-õKHPJaJh}h-õKHaJo(*Ømñmòm÷mn-nBn_nn¨n»n¼noFoIoÐoÑoppp\p]phpipjp¦pôèÜôÐÄô¸ôÐôÐ¸¨¸ÄxgxPxBghV¶aJmHnHsHtH,hci_hV¶>*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh!ChÿPmHnHsHtHhë,çmHnHsHtHhp{hJaº>*mHnHsHtHhJaºmHnHsHtHhUBmHnHsHtHhÿPmHnHsHtHh]F´mHnHsHtHh!CmHnHsHtHh-õmHnHsHtH¦pÇp!q#qÎrs s¡s¨s¾soupuuuuÆubvcv¥vwxxxxx¼x3y½y
zzz
zòáòÛÒÛËÛÂÛ¼°¤°°°°qqq\)jhci_h(.UaJmHnHsHtHhØdh(.mHnHsHtHh(.mHnHsHtHhÿ[þmHnHsHtHh]F´mHnHsHtHh!CmHnHsHtHh«}mHnHsHtH
h]F´aJhÑah«}aJ
*h«}aJh¦wh«}aJ
h«}aJ hci_hV¶aJmHnHsHtHhV¶aJmHnHsHtH s¡stoupuuucvw¦wxxxx4ycy¾yzz,{-{O{§|}V~÷÷÷÷òòòòòòòòíååååòàíòÛÖÖgd8 gdV¶ gd(.
&Fwgd(.gd(.gd!C$a$gd«}
zezfzqzrzsz°zÐz*{,{-{N{O{P{¨{©{´{µ{¶{|||!|ïÚÃÚµïµïµ¦¦qZLqL;q h«8ÆhV¶aJmHnHsHtHhV¶aJmHnHsHtH,hci_hV¶>*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh(.h(.mHnHsHtHh!Ch(.mHnHsHtHh(.aJmHnHsHtH,hci_h(.>*B*aJmHnHphÿsHtH)jhci_h(.UaJmHnHsHtH hci_h(.aJmHnHsHtH!|.|0|9||§|ª«}ñò}ÇßàêíîõBwÃ,RSòHcdedeïÞïÞÐÌÅÌÁÌ½Á½¹½µ¹µ®¢¢¢~¢rch!Ch(.mHnHsHtHh(.mHnHsHtHh!CmHnHsHtHh²2emHnHsHtHhÛ
GmHnHsHtHhå'lmHnHsHtHhORhå'lh²2ehÛ
Ghå'lhZdîh8háh8hV¶aJmHnHsHtH hci_hV¶aJmHnHsHtH h«8ÆhV¶aJmHnHsHtH&V~}ò}ÇîÃ¶òdenÎ,=FNde¼úúúúúúõõõõõõõððèèèèðèðèõã gdV¶
&Fxgd(.gd(.gd!Cgd8ef¾¿ÊËÌ *º¼üFfu§º×ßJKÕÚÿnopÈÉÔÕÖ4êÙêÂê´Ù´Ù´°¤¤¤¤¤¤¤ttteêÙêÂê´Ù´h!ChÀ'#mHnHsHtHhÀ'#mHnHsHtHhmHnHsHtHh7o5mHnHsHtHh!CmHnHsHtHhÛ
GmHnHsHtHhÛ
GhV¶aJmHnHsHtH,h}kÉhV¶>*B*aJmHnHphÿsHtH h}kÉhV¶aJmHnHsHtH)jh}kÉhV¶UaJmHnHsHtH'¼`üFK|ÝIoÇËÈN^iÄôa¬¼ÌõõõðððððððððëðæëáððððððððððgdÀ'#gd(. gdV¶gd!C $¤xa$gdÛ
G4ÄÅÆÇÊËklwxy·Øáãíïõ÷ýÿ
!*,24;=ïáïáÕÉº«náá]]]]]]]]]] h«8ÆhV¶aJmHnHsHtH,hci_hV¶>*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh!Ch!CmHnHsHtHh(.h(.mHnHsHtHhÀ'#mHnHsHtHh(.mHnHsHtHhV¶aJmHnHsHtH h}kÉhV¶aJmHnHsHtH$=DFNPVX]_ik}¡£ª¬´¶ÆÈ·¸KLöù
ÏÐAMN]^ïÞïÞïÞïÞïÞïÞïÞïÞïÞïÞïÞïÐÁµÁ¢Á¢Á¢Á¢Á¢ÁµÁÁÁh!CmHnHsHtHh7o5mHnHsHtHhhhhÀ'#mH sH $hhhhÀ'#KHaJmH nHsH tHhÀ'#KHaJmH sH hhhhÀ'#KHaJmH sH hV¶aJmHnHsHtH hci_hV¶aJmHnHsHtH h«8ÆhV¶aJmHnHsHtH.)F`¬¼èóþb ¡®qrsËÌ×ØÙ57?AHJQS[]kmvxôèôèôèôèôèôèôèÜÍ¾©©©ssbbbbbbb h÷?JhV¶aJmHnHsHtHhV¶aJmHnHsHtH,hci_hV¶>*B*aJmHnHphÿsHtH hci_hV¶aJmHnHsHtH)jhci_hV¶UaJmHnHsHtHh!Ch(.mHnHsHtHhx´h(.mHnHsHtHh(.mHnHsHtHh7o5mHnHsHtHh
mHnHsHtH&õc¡¢®¼ÏÝíHk±ó&Gqr@]úúúúúõíåííååííííííííúàúúà gdV¶
&Fxgd(.
&Fxgd(.gd(.gd!C©«µ·ÀÂÈÊÑÓÚÜäæìîôöÿ ?@AïÞïÞïÞïÞïÞïÞïÞïÞïÞïÞïÞïÞïÞÐÞÐÄ¸©t hVÈhV¶aJmHnHsHtH)jhVÈhV¶UaJmHnHsHtHh!Ch(.mHnHsHtHh(.h(.mHnHsHtHh!CmHnHsHtHh
mHnHsHtHhV¶aJmHnHsHtH h÷?JhV¶aJmHnHsHtH hci_hV¶aJmHnHsHtH$¥¦§öøþ&(-/79>@LN[]K L Í Î b¡Ï¡ç¡¢m¢éÔÆµÆ¤µ¤µ¤µ¤µ¤µ¤µ¤µ¤µ¤µ¤Æ ssgh(.mHnHsHtHhNYmHnHsHtHh!CmHnHsHtHhp)ýmHnHsHtHh}![hp)ýaJhp)ý hÐg/hV¶aJmHnHsHtH hVÈhV¶aJmHnHsHtHhV¶aJmHnHsHtH)jhVÈhV¶UaJmHnHsHtH,hVÈhV¶>*B*aJmHnHphÿsHtH"]L \ g ~ Î ¡Ð¡ç¡¢¢¢*B*aJmHnHphÿsHtH h|:hV¶aJmHnHsHtH)jh|:hV¶UaJmHnHsHtHh!Ch(.mHnHsHtHh(.mHnHsHtHh«hdh(.mHnHsHtHv§§Ã§Ä§Ð§¨;¨¨ó¨ô¨õ¨É©³Îâ®'®6®a®®¢®Ä®ä®å®ñ®¯úúúõíííõúúèãúúúúúúúúúúúõÛ
&F{gd(.gdNY gdV¶
&Fzgd(.gd(.gd!Cô¨õ¨ö¨N©O©Z©[©\©©©©©«©µ©·©Æ©É©æ©ç©Õªõªç«
¬r¬s¬¬¬¬Â¬Þ¬ç¬)IJRñÜËÜ´Ü¦Ë¦ËË¦zzoaoWzooohNYaJnHtHho¶hNYaJnHo(tHhNYaJnHo(tHh¬>ãhNYaJnHtHh¬>ãhNYaJnHo(tH h|:hV¶aJmHnHsHtHhV¶aJmHnHsHtH,h° DhV¶>*B*aJmHnHphÿsHtH h° DhV¶aJmHnHsHtH)jh° DhV¶UaJmHnHsHtHh!Ch!CmHnHsHtH"¢³ÍÎáâä®å®¯%¯@¯_¯¢¯ª¯>²f²¼²Õ²J³K³\³o³q³³³³Á³ôæÚÎÂÚÂ¶ªªª||ª¶p¶aRFRhÇJýmHnHsHtHhÇJýhÇJýmHnHsHtHhÇJýhMk4mHnHsHtHhÁN¤mHnHsHtHhÇJýnHtHh(.nHtHhV2Îh(.mH nHsH tHh«hdh(.mHnHsHtHh(.mHnHsHtHhMk4mHnHsHtHhNj©mHnHsHtHh!CmHnHsHtHhNYmHnHsHtHh¬>ãhNYaJnHo(tHhNYaJnHo(tH¯@¯`¯¯¡¯¢¯ª¯O°æ°«±/²h²²²¦²×²³³(³J³K³q³ÿ³+´q´÷÷÷òíèòòòòòàààòààààííØØÓgdÇJý
&F~gd@íVíéÔÆµ¤µÆ{{{o{o`o`o`o`o`o`o`o`o`{h7Sªh7SªmHnHsHtHh7SªmHnHsHtHh#@émHnHsHtHh#@éh#@émHnHsHtHh÷EhaJmHnHsHtH hci_h0BfaJmHnHsHtH hÝÐh0BfaJmHnHsHtHh0BfaJmHnHsHtH)jhci_h0BfUaJmHnHsHtH,hci_h0Bf>*B*aJmHnHphÿsHtH%VííxîîîîñîòîýîþîÿîKïMïWïYïdïfïrïtïuïððõÕõT÷W÷r÷÷±÷²÷øñåÖÊµ¤µµ¤n¤n¤nå_å_åÖSÖSÖSåh7SªmHnHsHtHh?7h?7mHnHsHtH hWhFwaJmHnHsHtHhFwaJmHnHsHtH,h° DhFw>*B*aJmHnHphÿsHtH h° DhFwaJmHnHsHtH)jh° DhFwUaJmHnHsHtHh0BfmHnHsHtHh7Sªh7SªmHnHsHtHh?7mHnHsHtHh#@éh#@émHnHsHtHÕõ~ö²÷,øËø ùüù7úü(ýIýý£ýþþxÿyÿGHÜÝ¥úúúõõðëëúúëæáÔáÏÊÏáÏÊÏá gdp{gd KÌ
Æ-^-gd KÌ gd?|gd^¨gd!C gd¤@ógd?7gd7Sªøø+øù ù
ùbùcùnùoùpù¿ùÁùÇùóùüù7úeúxúÏúÛúÜúÝúíúòúBûMûkûlû»ûãûúûûû1üüôèÜÐ»ª»»ªtªhYhYhYhYhYhYhYhYhYhhzC¡hzC¡mHnHsHtHhzC¡mHnHsHtH hNvh+
aJmHnHsHtHh+
aJmHnHsHtH,hp
h+
>*B*aJmHnHphÿsHtH hp
h+
aJmHnHsHtH)jhp
h+
UaJmHnHsHtHhFwmHnHsHtHh4£mHnHsHtHh?7mHnHsHtHh@mHnHsHtH"üüüüýý(ýCýaýbýýýýý¢ý£ý¤ýüýýýþ þ
þ4þUþôåôåôåôåôÙÊ¾¯ nWInIh KÌaJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtH hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHh^¨mH nHsH tHh=êhU>mH nHsH tHh=êhX§mH nHsH tHh KÌmH nHsH tHh!ChzC¡mHnHsHtHhzC¡mHnHsHtHh7Sªh7SªmHnHsHtHh7SªmHnHsHtHUþ\þþþþþþëþìþ÷þøþùþÿ;ÿIÿPÿvÿwÿxÿyÿzÿÒÿÓÿïÞÐÂ²ÞÂÞÂÞïÞÐumXGX h"h&* aJmHnHsHtH)jh"h&* UaJmHnHsHtHh KÌnHtH hci_h KÌCJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtH)jhci_h KÌUaJmHnHsHtHhh KÌaJmHnHsHtHÓÿÞÿßÿàÿ,.>GHI¡¢®¯¼ÝñóéÔÆµÆµÆpbbQQbIh¥%.nHtH hûh¥%.aJmHnHsHtHh¥%.aJmHnHsHtH,hci_h¥%.>*B*aJmHnHphÿsHtH hci_h¥%.aJmHnHsHtH)jhci_h¥%.UaJmHnHsHtHh&* nHtH h"h&* aJmHnHsHtHh&* aJmHnHsHtH)jh"h&* UaJmHnHsHtH,h"h&* >*B*aJmHnHphÿsHtH_`klm¼¾ÆÛÜÝÞ67BCDZ{êÙêÂê´Ù´£´uduMu?d?h¥%.aJmHnHsHtH,hci_h¥%.>*B*aJmHnHphÿsHtH hci_h¥%.aJmHnHsHtH)jhci_h¥%.UaJmHnHsHtHh&* nHtH h+h&* CJmHnHsHtH hÑj]h&* aJmHnHsHtHh&* aJmHnHsHtH,h+h&* >*B*aJmHnHphÿsHtH h+h&* aJmHnHsHtH)jh+h&* UaJmHnHsHtH{£¥¦§ÿ*?@¤¥¦»Üåçóõýÿ
ïÞïÞÐÈ³¢³³}l}\³¢³³}¢}l¢l¢l¢l¢l}häN;CJaJmHnHsHtH h_>häN;aJmHnHsHtHhäN;aJmHnHsHtH,hci_häN;>*B*aJmHnHphÿsHtH hci_häN;aJmHnHsHtH)jhci_häN;UaJmHnHsHtHh¥%.nHtHh¥%.aJmHnHsHtH hci_h¥%.aJmHnHsHtH hûh¥%.aJmHnHsHtH!¥¦>?%&»¼01ÛÜÅÆ P
Q
12éêúõèõèõèõèõèõèõúõúõúõúãúÞú gd¤@ó gdp{
Æ-^-gdäN; gd?|gd KÌ#%&'§¹»¼½!"#WYbdprz|õö.012¬ÍòäÔ¿®¿¿ääÔ¿®¿¿ä®ä®®®®äÔ¿®¿¿ääÔ¿®¿¿ä®ä h_>häN;aJmHnHsHtH,hci_häN;>*B*aJmHnHphÿsHtH hci_häN;aJmHnHsHtH)jhci_häN;UaJmHnHsHtHhäN;CJaJmHnHsHtHhäN;aJmHnHsHtHhÌ{¹aJmHnHsHtH0ÍÖØäæîðûý
pq|}ÅÆØÙÛÜÝ56ABC[|ª¬ïÞïÞïÞïÞïÐÂÐ²ÞÐÞuÐmÞÐÞÐïÞïÞïÞïÞhäN;nHtH h_>häN;aJmHnHsHtH,hci_häN;>*B*aJmHnHphÿsHtH)jhci_häN;UaJmHnHsHtHhäN;CJaJmHnHsHtHhÌ{¹aJmHnHsHtHhäN;aJmHnHsHtH hci_häN;aJmHnHsHtH h9häN;aJmHnHsHtH*¬¼¿ÃÅÆÇ + , - = ^ m o v x ïáÓáË¶¥¶¶¥o¥o¥o^VA)jhcÒhq>)UaJmHnHsHtHhnonHtH hci_hnoCJmHnHsHtH hB÷hnoaJmHnHsHtHhnoaJmHnHsHtH,hci_hno>*B*aJmHnHphÿsHtH hci_hnoaJmHnHsHtH)jhci_hnoUaJmHnHsHtHhäN;nHtHh2úaJmHnHsHtHhäN;aJmHnHsHtH h9häN;aJmHnHsHtH ì í ø ù ú
:
@
B
H
P
Q
R
ª
«
¶
·
¸
þ

ïÚÃÚµïµ¤ï¤µv_QvQ@v@v hÑj]h&* aJmHnHsHtHh&* aJmHnHsHtH,h+h&* >*B*aJmHnHphÿsHtH h+h&* aJmHnHsHtH)jh+h&* UaJmHnHsHtHhq>)nHtH h¸$hq>)aJmHnHsHtHhq>)aJmHnHsHtH,hcÒhq>)>*B*aJmHnHphÿsHtH)jhcÒhq>)UaJmHnHsHtH hcÒhq>)aJmHnHsHtH(123ÀÂÐÒßéêëCDOPïáÙÄ³ÄÄ³}³}u`O`8`,hp
h+
>*B*aJmHnHphÿsHtH hp
h+
aJmHnHsHtH)jhp
h+
UaJmHnHsHtHh±énHtH hbK+h±éaJmHnHsHtHh±éaJmHnHsHtH,hKf@h±é>*B*aJmHnHphÿsHtH hKf@h±éaJmHnHsHtH)jhKf@h±éUaJmHnHsHtHh&* nHtHh&* aJmHnHsHtH hÑj]h&* aJmHnHsHtHPQ¬µ¶·

T
V
^

£
¥
¯
°
òáòÐòÈ³á³³òáòÐáòvgv[hU>mH nHsH tHh=êh¿mH nHsH tHh=êhò}ImH nHsH tHh^¨mH nHsH tHh KÌh+
nHtH,hp
h+
>*B*aJmHnHphÿsHtH)jhp
h+
UaJmHnHsHtHh+
nHtH hNvh+
aJmHnHsHtH hp
h+
aJmHnHsHtHh+
aJmHnHsHtHêµ¶

°
klNOïðÕÖ¬gh&'éêKLúõúõðëæðëÙëÙÔÙúÙëÙëÙëÙëÙ gdp{
Æ-^-gd*B*aJcHdháe
§mHnHphÿsHtH3hci_h!Ch7b aJcHdháe
§mHnHsHtH*B*aJmH nHphÿsH tH hÃ:h0ÄaJmH nHsH tH)jhÃ:h0ÄUaJmH nHsH tH h@*B*aJmHnHphÿsHtH/j
+hci_h)A|UaJmHnHsHtH hci_h)A|aJmHnHsHtH)jhci_h)A|UaJmHnHsHtHh¤@óh+
mHnHsHtHhÙWhÙWmHnHsHtH h_@h*B*aJmHnHphÿsHtH h÷h/7²aJmHnHsHtH)jh÷h/7²UaJmHnHsHtHh~lWhõ5óh0Äh0Äh0Äh(.h(. hûh¥%.aJmHnHsHtHh¥%.aJmHnHsHtH hci_h¥%.aJmHnHsHtHÉABBäBåB¾C`F§FÀFGGGðGñGþH£KÀK*LpL$M%MGMwNxNNúúõðëãÞÞÞÞðõðëãããããðÙëÔÏgdÉj¬gd KÌgd|gd0Ä$a$gd0Ä gd?|gdÅL gd¤@ógdõ5óæB>C?CJCKCLCgCCCCCCC¡C¼C½C¾CÑCD_F`FGGGuGvGïÚÃÚµïµ¤ï¤ï¤ï¤µ~zvaPa hp
h+
aJmHnHsHtH)jhp
h+
UaJmHnHsHtHhFwh0Äh}![h0ÄaJháyh0ÄaJ
h0ÄaJhEnaJmHnHsHtH h¸$hFwaJmHnHsHtHhFwaJmHnHsHtH,hcÒhFw>*B*aJmHnHphÿsHtH)jhcÒhFwUaJmHnHsHtH hcÒhFwaJmHnHsHtHvGGGGÐGÒGÜGðGñGòGJHKHVHWHXHiHkHÝHþH3I4IaIéÔÆµÆ¤Æ zcUzUzUNC7htAh0ÄnHo(tHhtAh0ÄnHtHhtAh0ÄhFwaJmHnHsHtH,h° DhFw>*B*aJmHnHphÿsHtH h° DhFwaJmHnHsHtH)jh° DhFwUaJmHnHsHtHh+
hNvh+
aJmHnHsHtH hp
h+
aJmHnHsHtHh+
aJmHnHsHtH)jhp
h+
UaJmHnHsHtH,hp
h+
>*B*aJmHnHphÿsHtHaItII¡I¢I¦I·I¸IØIàIãIôIõI"J5JOJbJcJgJ¡J¦JºJÔJ×JêJëJìJíJôJõJ=KKK#M$M%MFMGMHM M¡MõéÞéõéõ×éõÏõéõéõéõéõÏéõéõéõéÏõÏÃÏµ®£u hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHh|mH sH h=êh|mH sH h~lWhFwhtAh0ÄaJnHo(tHh&tçh0ÄH*nHtHh0ÄnHtHhtAh0Äh45h0ÄnHtHhtAh0ÄnHo(tHhtAh0ÄnHtH(¡M¬MM®MN;NENoNuNvNwNxNNNNNNNNèNéNéÔÆµÆ¤µµ~shshs`K:K hci_häN;aJmHnHsHtH)jhci_häN;UaJmHnHsHtHhÉj¬mH sH h=êhbY)mH sH h=êhÉj¬mH sH h KÌh KÌ hci_h KÌCJmHnHsHtHhEnaJmHnHsHtH hvlh KÌaJmHnHsHtH hci_h KÌaJmHnHsHtHh KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtHéNôNõNöN6OROxO{OOOñOõO^PgPVQ^Q¯Q°Q×RTTTTTéTêTéÔÆµÆµÆ§Æ|xcRc h3h
lMaJmHnHsHtH)jh3h
lMUaJmHnHsHtHhäN;*h%%h0Äh0Äh0ÄnHtHhóq.h0Ä6nHo(tHh0ÄnHo(tHh2úaJmHnHsHtH hci_häN;aJmHnHsHtHhäN;aJmHnHsHtH)jhci_häN;UaJmHnHsHtH,hci_häN;>*B*aJmHnHphÿsHtHNO×RpSÒSTT=U>UV«YkZ/\U]^^7^è^D_\_*`]`úõõõõðëðæáááÜ×ÜÒÍÀ»ú¶gd KÌgd(.
gdkooÆ
i
Çd&F gdkogdiA gd¤@ógdt}gdõ5ó gdt} gdp{gdäN;gd0Ä gd?|êTõTöT÷T&U(U.U4U;UU?UUU£U¤U¥U¸UÙUéÔÆµÆ¤ÆµÆzizRzDiDht}aJmHnHsHtH,hci_ht}>*B*aJmHnHphÿsHtH hci_ht}aJmHnHsHtH)jhci_ht}UaJmHnHsHtHhäN;h
lMhwÔaJmHnHsHtH hßýh
lMaJmHnHsHtH h3h
lMaJmHnHsHtHh
lMaJmHnHsHtH)jh3h
lMUaJmHnHsHtH,h3h
lM>*B*aJmHnHphÿsHtHÙUàUâUêUìUöUøUVVVVV][z[{[º[-\=]D]T]U]V]®]ïÞïÞïÞïÐïÂ±¦¦s¦g¦_J9 hKf@h±éaJmHnHsHtH)jhKf@h±éUaJmHnHsHtHht}mH sH *hKÌhõ5ómH sH !Hhøj
ÇhôHhôHmH sH Hhøj
ÇhôHmH sH 'hõ5óhõ5óhôHcHdhøj
ÇmH sH hõ5óhõ5ómH sH hci_ht}CJmHnHsHtHht}aJmHnHsHtHh/7²aJmHnHsHtH hci_ht}aJmHnHsHtH hÝÐht}aJmHnHsHtH®]¯]º]»]¼]Ö]Ø]ü] ^
^^^^^^^^^1^3^4^5^6^7^êÓêÅ´Å´Å´£zzrjbrTHh
i
Çhy|mH sH h]y mH sH hÁQ`mH sH h:õmH sH h=êhÉj¬mH sH h=êhYmH sH h=êhàL+mH sH h±émH sH hKf@h±éCJmHnHsHtH hKf@h±éaJmHnHsHtHh±éaJmHnHsHtH,hKf@h±é>*B*aJmHnHphÿsHtH)jhKf@h±éUaJmHnHsHtH7^8^^^^^¢^¨^è^C_D_G_T_V_W_X_Z_[_\_]_µ_¶_äÍä°äÍÍzvrkrvgRAR hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHh^¨ jàðhÏTàhÏTàhèÑh^¨h:õh^¨h§MÞhkohkoHh
i
Çhko-Hh
i
Çh%%hkoaJmHnHsHtH9Hh
i
ÇhÃ:hko>*B*aJmH nHphÿsH tH-Hh
i
ÇhÃ:hkoaJmH nHsH tH6jHh
i
ÇhÃ:hkoUaJmH nHsH tH¶_Á_Â_Ã_é_
```(`*`\`]`ÜeãeüeýeUfVfafbfcftfféÔÆµÆ¤µ¤ÆxgxPxBgBh¥%.aJmHnHsHtH,hci_h¥%.>*B*aJmHnHphÿsHtH hci_h¥%.aJmHnHsHtH)jhci_h¥%.UaJmHnHsHtH*h@*B*aJmHnHphÿsHtH]`bccÃcØdSeÃeüeÑfghoi9jÖjÞk7löl)mäoqâqÜrçsytõtUwÉw+xúúúúúúúúõúúúúúúúõúúúúúúúúúúú gd?|gd9qfff¯f±f»f½fÏfÑfg6l7l8llllll®lÊlÑlÓlÙlÛlálãlôlõlöl(mævïÞïÞïÞïÐÉÅÁ¬¬¬vveeeeWvÉÅhEnaJmHnHsHtH hB÷hnoaJmHnHsHtHhnoaJmHnHsHtH,hci_hno>*B*aJmHnHphÿsHtH hci_hnoaJmHnHsHtH)jhci_hnoUaJmHnHsHtHh¥%.h9qhdy®h9qh¥%.aJmHnHsHtH hci_h¥%.aJmHnHsHtH hûh¥%.aJmHnHsHtHævîvïvðvñv*x+x8xGxIxKxLxNxOxPxQxRxªx«x¶x·x¸xÕx×xìxîx÷óéÜóÕÎÇÃ¹¬¹ÃÎybTyTCT hvlh KÌaJmHnHsHtHh KÌaJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtH hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHhèÑh³0cHdhh
ÇHhh
Ç jàðh³0Hhh
Çh³0hèÑh^¨hÂh^¨h;fh KÌhnoh9qh4}|cHdhLk
ÇHhLk
Çh4}|h9q*h@)aJmHnHsHtH)jhcÒhq>)UaJmHnHsHtH
h
tH
hXþtHh7Hh³0cHdhh
ÇtHHhh
Çh³0tH*hKÌh7HtH
h7HtH hývBh
aJmHnHsHtH hci_h
aJmHnHsHtHh
aJmHnHsHtH)jhci_h
UaJmHnHsHtH,hci_h
>*B*aJmHnHphÿsHtH(ô3ô4ô5ôDôeôpôrô|ô~ôôôô)ö3ö4ö5ö8ö:ö;ö)tHh7Hh³0cHdhh
ÇtHHhh
Çh³0tH&*hKÌh7HhÑ9'cHdhRh
ÇtHHhRh
Ç*hÑ9'tH*hKÌh7HtH
h7HtHhEnaJmHnHsHtH h¸$hq>)aJmHnHsHtH hcÒhq>)aJmHnHsHtHhq>)aJmHnHsHtH)jhcÒhq>)UaJmHnHsHtH,hcÒhq>)>*B*aJmHnHphÿsHtHkölöxözö|öööööööìöíöøöùö÷"÷$÷6÷8÷Ø÷Ù÷Ü÷Ý÷øøtø|øøøù"ù;ù[ùcù»ù¼ùÚùéùeúwúòîêæßæîÛîÆµÆÆµxtxtxtxlhtxtxhlhtxtxhh÷ *hKÌh÷ hX´hX´hX´ hvlh KÌaJmHnHsHtHh KÌaJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtH hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHhÏÔh=êhn5Þhn5ÞhÒKÀh |èh¿ aJmHnHsHtH(Ù÷ø¼ù®úüÐüÑüPýÙþÏÿý-CþrÚF³´aàÏ ÷÷÷÷÷òíàààíÛÛÓÓÛËËÆíÆÆÆgd KÌ
&FgdKÌ
&FgdKÌgd
Æ-^-gdð gd?|gdX´
&FgdKÌwú~úú®úû!ûÓûåûìûüüüü©ü½ü¾ü¿üÇüÏüÐüÑüÒü*ý+ý6ý7ý8ý>ý@ýAýBýNýPýáÿ÷óïèïèäÜäïèïèäèäÔäÐï»ª»»ªtftYhKÌhðaJnHtHhX´aJmHnHsHtH hûh¥%.aJmHnHsHtHh¥%.aJmHnHsHtH,hci_h¥%.>*B*aJmHnHphÿsHtH hci_h¥%.aJmHnHsHtH)jhci_h¥%.UaJmHnHsHtHh KÌ*hKÌh+#*he-Th+#h+#hX´hX´hX´h÷ *hKÌh÷ !áÿéÿíÿñÿöÿûÿ=AEFNüýþVWbcdr«ÇÎ./;B³´öéöéöéöéöéöÛöÎ¹¨¹¹¨rnfn_nfn[h¥%.hh*he-Thh hûh¥%.aJmHnHsHtHh¥%.aJmHnHsHtH,hci_h¥%.>*B*aJmHnHphÿsHtH hci_h¥%.aJmHnHsHtH)jhci_h¥%.UaJmHnHsHtHhKÌh¥%.aJnHtH*hKÌhðaJnHtHhKÌhðaJnHtHhðaJnHtH ´µ
5DFLN_`a¥ÐÔÀ ° × µ
É
!%3[\êÙêÂê´£Ù£Ù£Ù£´|vpfpvp`
hii¥aJ*hKÌh7=aJ
h7=aJ
hO.aJ*hKÌh¡m5aJ
h¡m5aJh¡m5h¡m5aJhEnaJmHnHsHtH hB÷hnoaJmHnHsHtHhnoaJmHnHsHtH,hci_hno>*B*aJmHnHphÿsHtH hci_hnoaJmHnHsHtH)jhci_hnoUaJmHnHsHtH%Ï ]ò8ïºÜºrÃò4[übßPúõðððëæáÜÜÜÜ×ÒÁõÒ¹¹¹¹
&FgdùJÞgdq>yoÆde
§d&F
&FgdùJÞgd(.gdX´ gd0Ägd0Ä gdÏÔgdgú gd?|gd KÌ\]^¶·ÂÃÜðòz{êë
8
?
@
H
I
J
K
P
Q
÷Ø¾ØØmS*B*aJmHnHphÿsHtH-Hh,k
Çhci_hq+aJmHnHsHtH6jHh,k
Çhci_hq+UaJmHnHsHtHhEph¬$ mHnHsHtH#Hhöh
Çh¬$ mHnHsHtH#Hhi
Çh¬$ mHnHsHtH''3'4'5'6'7'''''¶'¼'¾'Æ'È'å'ç'(((n(o(òæ×òÍ¸§¸¸q§q§qg`K:K hcÒhÒKÀaJmHnHsHtH)jhcÒhÒKÀUaJmHnHsHtHh*B*aJmHnHphÿsHtH hcÒhEpaJmHnHsHtH)jhcÒhEpUaJmHnHsHtHHh,k
Çhq+Hh,k
Ç*hV2Îhq+Hh-k
Ç*hq+Hh,k
Çh6xÞhq+o(z({(|((ª(°(²(º(¼(Ú(Ü( )
))c)d)o)p)q)))éÔÆµÆ¤µ¤µ¤ÆnWInIh+
aJmHnHsHtH,hp
h+
>*B*aJmHnHphÿsHtH hp
h+
aJmHnHsHtH)jhp
h+
UaJmHnHsHtH
hÒKÀtHHhi
Çh¬$ h¸$hÒKÀaJmHnHsHtH hcÒhÒKÀaJmHnHsHtHhÒKÀaJmHnHsHtH)jhcÒhÒKÀUaJmHnHsHtH,hcÒhÒKÀ>*B*aJmHnHphÿsHtH)¬)Ð)Þ)ô)ü)ý) *******)***a*ïÞÐ¹§seS7-Hhi
Çh!A6Hhi
Çh!Ah!AnHtHÊi
Ç*mH sH #Hhi
Çh!AmH nHsH tHHhi
Çh!AnHtHHhi
ÇhãCÊnHtHh(.nHtHh:QnHtHh=êh¬9ënHtHh=êhÝ/ÜnHtH
h+
tHHhi
Çh¬$ tH-Hhi
Çh¬$ h¬$ tHÊi
Ç**h+
aJmHnHsHtH hp
h+
aJmHnHsHtH hNvh+
aJmHnHsHtHa*b*g*k****ä*å*ð*ñ*+!+#+3+5+W+b+c+d+¼+½+õëõëàËºË£Ëºëzt_N_ hci_hq>)aJmHnHsHtH)jhci_hq>)UaJmHnHsHtH
h!CtHHhi
Çh!A h¦tâh!CaJmHnHsHtHh!CaJmHnHsHtH,hci_h!C>*B*aJmHnHphÿsHtH hci_h!CaJmHnHsHtH)jhci_h!CUaJmHnHsHtHh!Ah!AnHtHHhi
Çh!AHh%k
ÇhLj***5+c+,,-E-..ä.æ.ç/è/0Ö01:2Û2T4&55òíèíèãÞíÙÔÏÊÏãÞã½ãÞã¸gd KÌ
Æ-^-gd:Q gdp{gd+
gd+
gd¤@ógd:Q gd:Qgd!C gd?|
gd!AoÆi
Çd&F½+È+É+Ê+ä+å+æ+,, ,,,
,e,f,q,r,s,,¤,éÔÆµ¤Æ¤ÆÆtctLt>c>h:QaJmHnHsHtH,hci_h:Q>*B*aJmHnHphÿsHtH hci_h:QaJmHnHsHtH)jhci_h:QUaJmHnHsHtHh/7²hq>)mHsHtHhCaJmHnHsHtH hÝÐhq>)aJmHnHsHtH hci_hq>)aJmHnHsHtHhq>)aJmHnHsHtH)jhci_hq>)UaJmHnHsHtH,hci_hq>)>*B*aJmHnHphÿsHtH¤,¥,¦,¯,°,±,»,¼,½,Â,Ê,Ì,Ò,Ô,Ú,Ü,ñ,ó,ù,û,----D-E-F---ëÔÆëÔÆëÔÆµ¤µ¤µ¤µ¤µ¤µ¤µÆu[u3hci_h KÌhLjaJcHdh&k
ÇmHnHsHtH)aJmHnHsHtH,hci_hq>)>*B*aJmHnHphÿsHtH hci_hq>)aJmHnHsHtH)jhci_hq>)UaJmHnHsHtHhçh_nHtH h{>hçh_aJmHnHsHtHhçh_aJmHnHsHtH,hci_hçh_>*B*aJmHnHphÿsHtH hci_hçh_aJmHnHsHtH)jhci_hçh_UaJmHnHsHtHhq>)mH sH h
âmH sH YÁYZZk[l[\\í\î\]Ý]^à^á^©_ª_k`l`8aíèãÞÙÞÙÞÙÇÞÂ½°ÞÂÞ§Þ
Ægd@) gd?|gdçh_ gdçh_
ÆÐáSü^S`ügdq>)5[B[D[Q[S[Y[[[c[k[l[m[Å[Æ[Ñ[Ò[Ó[Ø[ù[\\\\\\r\s\~\\\ë\í\ïÞïÞÄ°ï¢v_¢v¢NvN¢v_¢v¢ hfUhq>)aJmHnHsHtH,hcÒhq>)>*B*aJmHnHphÿsHtH hcÒhq>)aJmHnHsHtH)jhcÒhq>)UaJmHnHsHtH
hq>)tHhq>)aJmHnHsHtH'HhQk
Çh4}|aJmHnHsHtH3hR5Bhq>)h4}|aJcHdhQk
ÇmHnHsHtH hci_hq>)aJmHnHsHtH hR5Bhq>)aJmHnHsHtHí\î\]]]]^]_]j]k]l]]¨]µ]·]À]Â]Ð]Ò]Ø]Ú]Ý]
^^÷ïçßÊ¹Ê¢Ê¹¹¹oXNH
h KÌtHHhi
Çh¬$ -h KÌh¬$ aJcHdh i
ÇmHnHsHtH'Hh i
Çh¬$ aJmHnHsHtH hvlh KÌaJmHnHsHtHh KÌaJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtH hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHh?A{mH sH h
âmH sH h^¨mH sH h!Chq>)tH^^d^e^p^q^r^ª^²^¼^¾^Þ^à^á^â^:_;_F_G_H_q_z_êÙêÂê´Ù´£Ù£´~m~V~HmHh KÌaJmHnHsHtH,hci_h KÌ>*B*aJmHnHphÿsHtH hci_h KÌaJmHnHsHtH)jhci_h KÌUaJmHnHsHtHh¿ CJaJmHnHsHtH h{>h¿ aJmHnHsHtHh¿ aJmHnHsHtH,hci_h¿ >*B*aJmHnHphÿsHtH hci_h¿ aJmHnHsHtH)jhci_h¿ UaJmHnHsHtHz____©_ª_«_`````1`3`;`i`k`l`m`Å`Æ`Ñ`Ò`Ó`ß`aa"a7a8aïÞïÐÊµ¤µµ¤n¤]µ¤µµ¤n¤OhEnaJmHnHsHtH h@hÄ+øaJmHnHsHtHhÄ+øaJmHnHsHtH,hci_hÄ+ø>*B*aJmHnHphÿsHtH hci_hÄ+øaJmHnHsHtH)jhci_hÄ+øUaJmHnHsHtH
h KÌtHh KÌaJmHnHsHtH hci_h KÌaJmHnHsHtH h{>h KÌaJmHnHsHtH8a9aÚa
bbccId¸fúfZg&h'hThõhöhiijj kBnfopúõðççççççâúÝØÓâÎâÎÉÄÄÄgd" gd"gdnogd±m
gd±m
gd(. gd?|
Ægd@

Other exersises:

VCEG-O01d1.doc - ITU
Annexe 3 : Liste des RFC relatives à PPP - ASI @ INSA Rouen
department of electrical and information engineering - Covenant ...
Acronyme : «acronyme»
TP
EXERCICE II Un service au tennis (5,5 points)
Créer ses exercices intercactifs sous forme de page web
Modèle mathématique. - Exercices corriges
POLYNOME DU SECOND DEGRE
Exercice 1 - Collège Alain Fournier
Correction. - Math93
Factorisation - Enseignons.be