International organisation for standardisation organisation internationale de normalisation



Download 8.47 Mb.
Page41/116
Date19.10.2016
Size8.47 Mb.
#4078
1   ...   37   38   39   40   41   42   43   44   ...   116

Profiles/levels


15.0.0.1.1.1.1.1.86m30275 HEVC version 1: Level 2.2 for support of WVGA@30fps [Y.-K. Wang (Qualcomm)]
15.0.0.1.1.1.1.1.87m29936 Liaison Statement from 3GPP to SC 29/WG 11 on HEVC level definitions [3GPP via SC 29 Secretariat]

    1. HEVC Range Extensions


15.0.0.1.1.1.1.1.88m30167 Proposed Standardization of XYZ Image [H. Basse, W. Aylsworth, S. Stephens, M. DeValue, R. Kisor, B. Mandel, J. Helman, A. Luthra, W. Wan]

    1. HEVC Scalable Extensions


15.0.0.1.1.1.1.1.89m30422 Proposed SHVC hybrid scalable main profile [Jill Boyce, Ajay Luthra, Yan Ye, Kei Kawamura, Tomoyuki Yamamoto]

    1. HEVC Non-camera Captured Content


15.0.0.1.1.1.1.1.90m30477 Draft requirements for future extensions of HEVC in coding non-camera-captured content [H. Yu, K. McCann, R. Cohen, P. Amon]

    1. HEVC Multi-view Extension Profiles


15.0.0.1.1.1.1.1.91m30022 Proposal to Consider A New Work Item and Its Use Case REI : An Ultra-multiview 3D Display [Mehrdad Panahpour Tehrani, Takanori Senoh, Makoto Okui, Kenji Yamamoto, Naomi Inoue, Toshiaki Fujii, Hiroya Nakamura]
15.0.0.1.1.1.1.1.92m30229 Proposal on a New Activity for the Third Phase of FTV [Masayuki Tanimoto, Takanori Senoh, Shinya Shimizu, Sei Naito, Marek Domański, Anthony Vetro, Marius Preda]

    1. HEVC for Interlaced Scan Video


15.0.0.1.1.1.1.1.93m30452 Proposal of interlace coding tools for HEVC [G.Barroux, K.Kazui, A. Nakagawa(Fujitsu)]
15.0.0.1.1.1.1.1.94m30319 HM Software modifications for interlaced coding [Zineb AGYO, Jerome VIERON, Jean Marc THIESSE]

    1. Use cases


15.0.0.1.1.1.1.1.95m30340 Best-effort decoding of 10-bit sequences: use-cases and requirements [D. Flynn, G. Martin-Cocher, D. He]

    1. HEVC for Still Pictures


15.0.0.1.1.1.1.1.96m30234 New use cases for HEVC still image coding [J. Lainema, M. M. Hannuksela, K. Ugur, J. Ridge]
15.0.0.1.1.1.1.1.97m30502 Additional use cases for HEVC still image coding [D. Nicholson]
15.0.0.1.1.1.1.1.98m30503 Proposed test conditions for HEVC still picture coding performance evaluation [D. Nicholson]
15.0.0.1.1.1.1.1.99m30597 New use cases for HEVC still image coding [J. Lainema, M. M. Hannuksela, K. Ugur, J. Ridge, D. Nicholson]

  1. Wednesday Video plenary status review


The plenary was held 12:00-13:00 on Wednesday.

CDVS, Web VC and Internet VC. As far as further discussions and decisions were made on these topics, they are reflected in the respective sections above.

CDVS:


  • Analysis of runtime of CE1 proposals

  • Analysis of commonality of CE1 proposals

  • Separate LoG processing and extrema detection, further investigate different solutions in combination in upcoming CE1

  • Re-invoke CE on Global descriptor

  • Further improvements to WD and TM:

    • One proposal that improves performance of local descriptor by assuming center position instead of corner (M30228)

    • Re-ordering of bits for better truncation of bitstreams (M30309)

IVC ITM:

  • Two-reference hypothesis from same picture – publication of 1993

  • Inclusion of 16x8 and 8x16 ; same signalling mechanism as AVC for MB partitioning, but contributors claim they have investigated the MPEG-LA patent pool and did not find relevant patents

  • Loop filter: Too many commonalities with AVC/HEVC – not adopted

  • Multiple reference frames with direct signalling on block basis (based on a 1992 publication)

  • Improvement of non-reference P (as a special case of MPEG-1 B pictures)

Include 1, 2, 4, 5 in ITM6.

Continue on defining new CE.

IVC CfP:


  • Status of IPR? Is there currently any evidence that the proposal is not type-1 license?

  • Google has provided a list of companies that to the best of their knowledge is complete.

  • Only way to find out whether it is ultimately type-1 is by giving it an official status in MPEG/ISO and wait whether non-type-1 statements, or other evidence hat it is not type-1 are received.

  • “Patents” file will be removed from software

The Google representatives were asked the following questions:

  1. Is the VP8 proponent providing a type-1 license for VP8 when adopted by MPEG without modifications as an international standard?

  2. Is the VP8 proponent providing a type-1 license for VP8 modified for the purpose of adoption by MPEG as an international standard in the two following cases:

  1. one with modified version still compatible with existing implementations of VP8

  2. one with modified version not compatible with existing implementations of VP8

The Google representative confirmed that the answer on 1 and 2a is positive, the answer on 2b is unknown. Answer was provided in the follow-up session Thu 9:00, when the discussion was continued in the video group:

“In all cases, the answers pertain only to Google owned patents, and not any third-party patents.



  1. Is the VP8 proponent providing a type-1 license for VP8 when adopted by MPEG without modifications as an international standard? Yes

  2. Is the VP8 proponent providing a type-1 license for VP8 modified for the purpose of adoption by MPEG as an international standard in the two following cases:

    1. one with modified version still compatible with existing implementations of VP8. Yes

    2. one with modified version not compatible with existing implementations of VP8. Either type-1 or type-2. Will evaluate at that time.”

It was further mentioned verbally that the cross-licensing agreement (including 11 other companies) strictly only applies to question 1.

Options from BoG:
Options

Pros and cons

1

Accept and standardize the proposed VP8 as is.

Some MPEG members may be less inclined to participate in the MPEG process.

Some MPEG members may be less willing to provide use of their technology in option.

2

Accept and extend the proposed VP8 in such a way that a native VP8 mode is no longer possible

Making sure that the result is Type 1 may require considerable new MPEG resources. The original proponent may offer the technology as Type 1 or Type 2.

3

Accept and extend the proposed VP8 in such a way that a native VP8 mode is possible in addition to a new mode with an intended improved performance

The new mode may be Type 1 or not.

4

Reject the proposed VP8.

This is not applicable to this proposal

5

Other Type 1 standardization projects may borrow VP8 tools at MPEG’s risks.

The original proponent may offer the technology as Type 1 or Type 2.

It is agreed that option 4 is not applicable.

Options 2 and 5 are possible according to answer on 2b (but with considerable risk that it would not be Type 1).

Option 3 is a superset of option 1.

We propose to take option 3 with the understanding that, if there will be no volunteers to perform technical work extending the technology, we will practically fall back to option 1. If contributions are made that demonstrate significant improved performance preserving the Type 1 nature of the codec, MPEG may choose to follow option 2.



Actions:

  1. Issue “Working Draft on ABC video coding”. (Later agreed in MPEG plenary for "ABC" to be "VCB".)

  2. We propose that it should be a new ISO project.

  3. The code base of VP8 will be put on the SVN with
    a) replace the copyright disclaimer with MPEG BSD CR disclaimer
    b) remove the PATENTS file
    c) keep the AUTHORS file

Output doc planning on various topics was also further confirmed.


  1. Download 8.47 Mb.

    Share with your friends:
1   ...   37   38   39   40   41   42   43   44   ...   116



The database is protected by copyright ©ininet.org 2024
send message
    Main page
following documents
award ceremony