International organisation for standardisation organisation internationale de normalisation

7.8MVC high-level syntax

7.8.1.1.1JVT-Y025 ( SEI showcase 2.2) [G. Jiang, R. He, M. Yu (Ningbo U.)] Showcase for code optimization of active view info SEI in JMVM

At the JVT meeting at San Jose, an active view information SEI message (JVT-W036) was adopted into Joint Draft 3.0 on MVC. It specifies the views that are required for output. And in the following JVT meeting in Geneva, a showcase for the active view information SEI message for MVC as contributed in JVT-X027 provided a test platform for the active view information SEI message. However, the test platform contributed in JVT-X027 reportedly has a little defect: If someone wants to change the output view information, it is reportedly necessary to modify the code. This is reportedly very inconvenient to users. So this proposal suggests to revise the procedures to allow that only the modification of the configuration file is enough when the output view information needs to be changed. In this contribution, a showcase for this code improvement is presented.
JVT decision: Showcase considered satisfactory.
JVT decision: Software change agreed.

7.8.1.1.2JVT-Y029 ( Prop 2.2) [M. Yu, R. He, G. Jiang (Ningbo U.)] MVC syntax simplif in active view info SEI

At the JVT meeting in San Jose, an active view information SEI message (JVT-W036) was adopted into Joint Draft 3.0 on MVC. It specifies the views that are required for output. And at the JVT meeting in Geneva, a showcase for the active view information SEI message for MVC (JVT-X027) provided a test platform for the active view information SEI message. But the information of the syntax table provided by JVT-W036 reportedly has some redundancy, and this contribution suggests to change it.
Remarks: The proposal uses an undefined “sizeof” function. The proposed change only saves a few bits at the sequence level, so is not important.
Considering the problem in form, although it may perhaps only be editorial, there seems to be insufficient need to consider changing this at this stage.

7.8.1.1.3JVT-Y040 ( Prop 2.2/3.1) [H. Nakamura, M. Ueda (JVC)] On MVC high-level syntax

This contribution presents a comment on redundancy when coding without using inter-prediction, and it proposes that view dependency information is coded only when necessary and the information is not coded when not necessary.
The contribution suggests saving bits by not sending view dependency information in coded video sequences that do not use any inter-view prediction.
Remark: The number of bits suggested to be saved is very very small (as a percentage of total bit rate), and the anticipated use case seems to not be the primary target for the design.
Deferred for further study.

7.8.1.1.4JVT-Y043 ( Prop 2.2/3.1) [J. Luo, P. Yin, C. Gomila (Thomson)] MVC HRD & VUI high-level syntax

This contribution proposed high level syntax for an MVC Hypothetical Reference Decoder and bitstream restriction parameters. The first part presented a signaling of HRD constraints for each temporal level of each view. It was asserted that the signaling enables HRD verification for the coded presentation for a particular temporal level of a particular view. The second part was the signaling of bitstream restriction parameters for each temporal level of each view. It was asserted that the signaling enables the decoder to efficiently allocate resources for decoding a subset of the bitstream. Proposed syntax changes were provided.
The group discussed the concepts of conformance and terminology – e.g., do we specify the existence and output of more than one picture per access unit?
Consider, for example, the prior difficulty with the 4:4:4 work, where there was a need to struggle editorially with the concepts of the definition of what a picture is and whether there could be more than one primary coded picture per access unit. Similar difficulties arose during SVC drafting.
Suggestion: Specify only the decoding and output process for one view. If a decoder wants to output additional views, it can conceptually just do this specified process once for each view that it wants to output. There may not be a need to have a specified decoding process that is required to output multiple views. The essential concepts would remain the same, while the ability to properly describe and enforce conformance requirements would be much improved and much more consistent with non-MVC usage of basic concepts and terminology. (Essentially this seems to be only a matter of proper editorial expression of our intent.)
Conclusion: We certainly need to work out such details as HRD operation for MVC, but at this point the discipline of expression in the text may not be adequate for considering these issues. Further study is needed.

7.8.1.1.5JVT-Y055 ( Prop 2.2.1/3.1) [P. Yang, X. Xu, G. Zhu, Y. He (Tsinghua U.)] High level syntax for MVC view parallel proc

This was a follow up contribution in relation to JVT-X079. A view parallel coding architecture and its corresponding syntax change are presented in this proposal. As shown in results, by enabling the diagonal inter-view prediction, average gain was reported as 0.1 dB for overall pictures and 0.15 dB for non-key frames. For high motion sequences, the reported gain was 0.2 dB for overall pictures and 0.25 dB for non-key frames. This proposal further provided the syntax changes of the proposed method.
Part of the motivation was low delay.
Remark: The method of identifying the other picture to reference seems narrow-minded and less general than might be advisable. Why not sent a frameNumWrap difference to identify the picture instead of depending on POC?
Remark: There seems to be a loss robustness problem, since there is no way to unambiguously identify what picture is intended to be referenced in the case of lost view pictures. We generally don’t use POC for such purposes. What if the picture was in a different sub-sequence dependency structure? Why not send a frameNumWrap difference or long-term index within the referenced view to identify the picture instead?
Clarification: The proposal is to put the switch of what time instance of another view gets referenced up at the picture level, not at the macroblock/sub-macroblock level.
Note that the comparison here is relative to doing no referencing to other views in the non-anchor pictures.
Remark: This seems like a profile thing, since it seems like it cannot be the encoder that decides whether to reference same-time-instances in other views. The encoder would not naturally want to be forced to be unable to use same-time-instance pictures in other views.
Question: How much is the loss of coding efficiency relative to being allowed to reference the other view at the same time instant? Not reported.
Remark: The gain reported seems small, and the scenario seems highly specialized, and some design details seem questionable.

7.8.1.1.6JVT-Y062-LV (Late Info) [Q. Chen, Z. Chen (Thomson)] Verif JVT-Y055 high level syntax for MVC view parallel proc

This document reported cross-check results for JVT-Y055 “High level syntax for MVC view parallel proc”. Source code and configuration files were provided by the proponent of JVT-Y055. The verification was reportedly performed by checking, compiling the source code, generating the bitstreams and test data, and decoding the bitstreams. The simulation results of JVT-Y055 were reported to have been confirmed.
Executable files were reportedly regenerated and used for generating the cross-check results. Then bistreams were reportedly decoded and results compared with the results in JVT-Y055. For all the performed verification tests, the bitstreams were reported to have been decoded correctly with results that matched the results reported in JVT-Y055.
Question: How closely was the source code & algorithms checked? Unknown.

7.8.1.1.7JVT-Y061 ( Prop 2.2/3.1) [J.-H. Yang, J.-G Kim, S.-J. Choi (LG)] On MVC high-level syntax

In the current JD, sequence parameter set MVC extension syntax describes the dependency relations among different views. This document asserts that there are some redundancies in the current description, and proposes to remove those redundancies.
Aspect #1: Proposes to not send some syntax elements that are always required to be 0 anyway.
JVT decision: Adopted this aspect.
Aspect #2: Proposes a change of SPS syntax.
The proposal seems to not be fully understood. Some concern was expressed that there are other places in the document that depend on the parts that are proposed to be changed, and that the changes might have problematic implications on those parts.
The potential bit rate savings is extremely minor.