International organisation for standardisation organisation internationale de normalisation

6.4SVC historical information request

6.4.1.1.1JVT-Y085-L (Late Info) [M. Karczewicz, Y. Bao (Qualcomm)] Comments on JD text of CAVLC in SVC enhancement layer

This contribution requested clarification on the technology adopted for the CAVLC decoding processes for the SVC enhancement layer.
JVT-W090 was a CE experiment result report for a CE described in JVT-V301 (with CE leader J. Ridge; with J. Ridge of Nokia and M. Karczewicz of Qualcomm listed in the document as partners; and with HHI, Freescale, Huawei, ICT, TI, and RWTH Aachen listed in the meeting report as additional partners). The plan to perform the CE was approved at the January Marrakech meeting, and the final CE plan was agreed by the CE partners and available for review approx four weeks prior to the April San Jose meeting. It contained some changes to CAVLC which came from Nokia for partitioning coefficients into different NAL units in “method 3” along with some other changes to CAVLC and CABAC that had been proposed by others.
The JVT-W090 proposal focused on the changes proposed by HHI. An “r1” of JVT-W090 included software and results for both the changes proposed by HHI and the changes from Nokia to CAVLC. Nokia indicates that they considered their changes to CAVLC to be intended as the benchmark design for the CE and thought that the input experiment results from HHI would be sufficient for evaluating these changes, so they did not consider a submission of a contribution of their own to be necessary for consideration of these changes. In hindsight, Nokia expressed regret that they did not clarify the situation by submitting their own proposal contribution for the aspects of the CE technology that they originated. The meeting report recorded adoption of JVT-W090 in response to the experiment results submitted by HHI.
The Nokia changes were edited into the San Jose JD output along with the HHI changes. Subsequent review of the text between then and through the Geneva meeting and the Last Call review process in ITU-T did not indicate any problem with the outcome. And now there is still no indication of a technical problem with them (although Qualcomm indicates that they would have preferred the CAVLC entropy coding for MGS SVC enhancements to have been more closely aligned with non-SVC CAVLC coding for reasons of minimizing the implementation effort needed for SVC support).
Suggestion: CE descriptions should have IPR forms from each contributor of technology to the CE and are considered proposals from the set of technology contributors. Agreed.

6.5SVC Error Resilience

6.5.1.1.1JVT-Y047 ( Prop NN 2.0/3.1) [Y. Guo, Y.-K. Wang, H. Li (Nokia)] SVC motion-copy error conceal for key pics

The current JSVM software only supports the frame-copy error concealment method for key picture (i.e. the first picture of each “GOP”) losses if the same spatial or CGS layer data is considered for error concealment. This contribution presented motion-copy error concealment for key picture losses. Four QCIF@30Hz common sequences were tested with single-layer coding. Experimental results reportedly demonstrated that motion-copy can achieve better results than frame-copy at the tested GOP sizes (1, 2, 4, 8, 16) and packet loss rates (3%, 5%, 10%, 20%). For the Football and Foreman sequences, the gains for GOP sizes less than 4 were reportedly about 0.5~2 dB, whereas the gains for the other GOP sizes were reportedly no more than 0.5 dB. For the Bus and Mobile sequences, the gains for GOP sizes less than 8 were reportedly about 2~4 dB, whereas the gains of the other GOP sizes were reportedly about 0~2 dB. Source code and simulation scripts (including executable files and batch files) were provided in attached files of the contribution.
Non-normative motion-copy error resilience for key pictures in JSVM.
Non-normative proposal. Motion-compensated block copy from previous key picture.
Questions: How modular? How extensive? Maintenance issue? Response: Code for slice error concealment is more of a maintenance issue.
Question: Would there be interference with other work? Remark: Normative work should take priority.
Question: How much work do we have yet to go to get the text and software aligned? Not completely sure.
Is it working for interlace? Think so.
JVT decision: Adopted (but at a lower priority for software integration than the normative aspects).

6.6SVC high-level syntax and SEI

6.6.1.1.1JVT-Y046 ( SEI showcase) [C. He, H. Liu, Y.-K Wang, H. Li (Nokia)] SVC showcase of temporal level switching point SEI

At the Geneva meeting, a temporal level switching point SEI message (proposed in JVT-X032) was adopted in SVC. In this contribution, a showcase for the temporal level switching point SEI message was presented. The showcase tries to demonstrate that, without temporal level switching point SEI messages, a streaming server would have to run complex analysis to obtain the information contained in the SEI messages, or would have to perform temporal level switching without the information, which would then result in incorrect decoding results and degraded video quality. The source code of the implementation and the simulation scripts for the showcase were both provided as attachments.
JVT decision: Showcase is considered acceptable.

6.6.1.1.2JVT-Y066 ( Prop 2.2/3.1) [N. Sprljan, L. Cieplinski (MEI)] Perceptually optimal SVC layer removal ordering SEI

This contribution proposed using CGS and allowing a varying number of dependency layers at different temporal levels, while preserving perceptually optimal video quality for the given bit-rate. The proposed strategy is based on the creation of new adaptation points for which decoding is supported by loss compensation post-processing at the decoder. Application of such a scheme was asserted to lead to additional useful decoding points, as was asserted to be shown in the presented results. A syntax supporting a description of preferred layer combinations was proposed.
Question: After being “pruned” in this manner, is the bitstream still a conforming bitstream? Response: Perhaps not – it appears to an ordinary decoder like a bitstream from which some packets have been lost.
Remark: A specified decoder behavior in response to the missing data may needed.
Question: How much better is the perceptual quality of pruning using this proposal than the kind of pruning that can be performed without it?
Remark: The lack of conformance of such a bitstream that is (deliberately) delivered to a decoder poses a conceptual problem – we generally do not work on explicitly enabling deliberate construction of non-conforming bitstreams.
Remark: The work seems somewhat preliminary.
Further investigation would be needed to determine the value of this scheme relative to what we can now do without it.
Presentation is available.