Organisation internationale de normalisation

5.7MVC high-level syntax and HRD

5.7.1.1.1JVT-Z024 ( Info) [A. Vetro (MERL), P. Pandit (Thomson), H. Kimata (NTT), A. Smolic (HHI), Y.-K. Wang (Nokia), C. Ying (Tech. U. Tampere)] MVC decoding process and HRD design

This informational contribution discussed some issues relating to the description of the decoding process – whether the decoding process specifies the output of only one view (i.e. repeating the decoding process when output of multiple views is needed) or the output of any number of views to be output. It was asserted that the decision on the issues may deeply affect the MVC specification text editorially. Furthermore, it was asserted that the design of the HRD for MVC may also be affected technically. Two methods with their pros and cons were discussed (single-view output or output of all view).
The goal of this contribution was reportedly to outline the issues for discussion and collect opinions from other JVT experts. It was recommended that the group carefully discuss these issues since it was asserted that they affect several important aspects of the MVC specification.
After discussion – an approach similar to that used for SVC and for separate_colour_plane_flag equal to 1 was suggested. The suggestion was to focus on the decoding of one view throughout time. Other views on which that view depends will be generated during the decoding process as needed to decode the target view. Mark the pictures of the other views as "not used for reference" after completing the decoding process for the target view (or consider them as marked as inter-view-only reference pictures and all such pictures are removed from this classification upon completion of the access unit decoding process for the target view). Pictures of other views that are not the target view are always marked as "not needed for output". Make a distinction between marking for temporal referencing and for inter-view referencing.
A BoG discussion group was formed (coordinated by A. Vetro) to further discuss the editing aspects – the exact phrasing was left to the editors.

5.7.1.1.2JVT-Z027 ( Prop 2.2/3.1) [H. Nakamura, M. Ueda (JVC)] Comments on SPS MVC extension

This contribution proposed two changes relating to view dependency information in the sequence parameter set MVC extension. Both proposals are for redundancy reduction. These were asserted to be independent proposals.
This contribution suggested modifying the sequence parameter set MVC extension syntax.
Aspect #1: Signaling for applying inter-view prediction
Analogous to simulcast AVC coding.
The contribution notes that various aspects of simulcast coding may need some (e.g., externally specified) application-level support external to the video elementary bitstream data.
The contribution proposed a flag to indicate a lack of any inter-view dependency (rather than using existing dependency info syntax).
This case seems easy to detect with existing syntax, and the savings in this case is very minor – the JVT concluded that there was no real need to treat this case as special. No action was therefore taken by the JVT in this regard.
Aspect #2: anchor_ref_l0[i][j] inference from num_anchor_refs[i] for i equal to 1
The contribution proposed eliminating syntax element presence when a value can be easily inferred.
The proposal was concluded to seem to be excessive fine-tuning with negligible real effect. No action was therefore taken by the JVT in this regard.

5.7.1.1.3JVT-Z038 ( SEI Prop 2.0/3.1) [S. Yea, A. Vetro (MERL), A. Smolic, H. Brust (HHI)] Revised syntax for SEI message on multiview acquisition information

This contribution proposed alternative syntax options for the SEI message on multiview acquisition information (camera parameters). In particular, two forms of syntax were considered: one being a floating-point representation with a variable-length mantissa, while the other also has a variable-length mantissa and follows the IEEE 754 format. The proposed options were asserted to enable a wider range of numerical values and precisions, which would reportedly overcome some shortcomings and problems with the existing syntax. Matlab scripts were provided for verifying the proposed formats.
Remark: Is there an ISO, IEC, or ITU-T spec for IEEE 754? Apparent answer: IEC 60559.
Remark: Is it OK for the SEI message to not be parsable without first parsing the SPS?
JVT decision: Adopted.