Work Plan for Advanced Video Formats and Operation Points (FS_AVFOPS_MED)

Document Overview

This document (S4-260130) from Xiaomi proposes a work plan for the Study Item on Advanced Video Formats and Operation Points (FS_AVFOPS_MED). The study focuses on identifying and documenting new video representation formats and their integration into 3GPP specifications, particularly TS 26.265.

Study Objectives

The study item encompasses eight main objectives:

Objective 1: New Representation Formats

• Identify relevant new representation formats not yet documented in TS 26.265
• Analyze benefits in terms of user experience
• Consider format specificities for:
• Capture at interoperability point 2
• Rendering at interoperability point 4
• Candidate representations include:
• Support for alpha
• Depth together with stereo
• Additional colour subsampling (4:2:2 or 4:4:4)

Objective 2: Video Signal Generation Feasibility

Study feasibility of generating video signals corresponding to the hypothetical optical system (interoperability point 2) by: - Sub-objective 2a: Document requirements of real-time capturing systems to meet video signal characteristics (interface points 1a and 1b), including: - Temporal alignment of captured pictures - Frame rate - Bit depth - Sub-objective 2b: Identify different types of video processing functions applied to video source signals from typical UE capturing systems, including the possibility of AI-based image generation (interoperability point 2)

Objective 3: Compression Options

• Identify compression options for representation formats based on video codecs supported in 3GPP specifications
• Priority codec: HEVC (interoperability points 3 and 3bis)

Objective 4: Transport System Integration

• Identify opportunities and needs to integrate representation formats into different transport systems:
• Messaging
• Real-time communication
• Split rendering
• Streaming formats
• Applies to interoperability points 3 and 3bis

Objective 5: Traffic Characteristics

• Define expected traffic characteristics for new representation formats to meet certain quality thresholds

Objective 6: Bitstream Conformance Environment

• Further develop the bitstream conformance environment, including:
• Hosting
• Tooling and process
• Collect sample bitstreams illustrating the new representation formats identified in Objective 1

Objective 7: Gap Identification

Identify gaps in specifications and provide guidance: - In 3GPP specifications: Especially on operation points, provide guidance for potential normative work - In other SDO specifications (e.g., MPEG): Coordinate possible actions with relevant SDOs

Objective 8: Coordination with External Organizations

• Perform work in coordination with related SDOs and industrial fora:
• MPEG
• SVTA
• CTA-WAVE
• IETF
• Reference related specifications:
• Common Media Application Format (CMAF)
• ISO base media file format (ISOBMFF)

Study Working Methods

Contribution Process

The study adopts the following working methods: - Individual CRs created for specific aspects of work (e.g., one CR per new scenario) - A merged CR will be created at the end of the study to compile all changes to TR 26.966 - Company proposals to progress CRs submitted as "discussion" TDocs - Upon agreement, the responsible person of the CR implements the agreement

Current CR Status

Three CRs are currently in progress:

| CR | Title | Latest TDoc | Clause | Responsible | |---|---|---|---|---| | 0001r12 | New scenario: Video with changeable background | S4-252016 / S4aV250069 | 5.6 (new) | Emmanuel Thomas | | 0002r12 | New scenario: Refocusable video | S4aV250071 / S4-252018 | 5.7 (new) | Emmanuel Thomas | | 0003 | New scenario: Video with semantic segmentation map | S4aV250072 | 5.8 (new) | Emmanuel Thomas |

Detailed Work Plan Timeline

SA4#134 (November 17-21, 2025, Dallas, US)

• Start work on objectives 1, 2, and 3
• If needed, communicate with external organizations (objective 8)

Video SWG AHG Telco (December 16, 2025)

• Continue work on objectives 1, 2, and 3
• Submission deadline: December 15, 3pm CET
• Host: Qualcomm

SA4#135 (February 9-13, 2026, Goa, IN) - Current Meeting

• Continue work on objectives 1, 2, and 3
• If needed, communicate with external organizations (objective 8)

Video SWG AHG Telcos (TBD 2026)

Three telcos planned (dates TBD): - First two telcos: Continue work on objectives 1, 2, and 3 - Third telco: - Continue work on objectives 1, 2, and 3 - Start work on objectives 4, 5, 6, and 7 - Host: Qualcomm

SA#111 (March 10-13, 2026, Fukuoka, JP)

• No action

SA4#135-bis-e (April 13-17, 2026)

• Continue work on objectives 4, 5, 6, and 7
• If needed, communicate with external organizations (objective 8)

SA4#136 (May 11-15, 2026, Montreal, CA)

• Complete work on all objectives 1 to 7
• If needed, communicate with external organizations (objective 8)
• Endorsement of Work Item Summary

SA#112 (June 9-12, 2026, Singapore, SG)

• Approval of CR to TR 26.966

Proposal

The document proposes to agree on the work plan provided in the timeline above.

Summary of 3GPP Technical Document S4-260131

Document Information

• Type: Change Request (CR 0001 rev 3)
• Specification: TS 26.966 v19.0.0
• Category: B (addition of feature)
• Release: Rel-20
• Work Item: FS_AVFOPS_MED
• Source: Xiaomi Communications
• Meeting: SA4#135, India, 9-13 Feb 2026

Main Purpose

This CR proposes adding a new scenario to TS 26.966 addressing video with changeable background functionality, progressing objective 1 on identifying relevant new representation formats not yet documented in TS 26.265.

Technical Contributions

New Scenario #5: Video with Changeable Background (Clause 5.6)

Overview (5.6.1)

The CR introduces a scenario addressing the growing use case of mobile video editing where users: - Record and edit videos directly on their devices - Upload source video to cloud services for editing, or - Use local applications to generate final video

The key technical requirement is video compositing where: - One video is overlaid on another visual content - Alpha blending is performed using an alpha channel - Pixel-accurate transparency information is required - Alpha channel is typically carried in lossless manner

The CR includes four illustrative figures showing: 1. Original video frame 2. Associated alpha plane 3. Video frame with alpha plane applied 4. Alpha blended video frame with background image

Review of Previous Work (5.6.2)

The CR notes that coded representation of alpha auxiliary channels as part of video bitstream has not been addressed in 3GPP specifications until now.

Review of Related Work (5.6.3)

MV-HEVC Support (5.6.3.1)

• MV-HEVC video coding standard enables encoding of alpha channel as auxiliary layer
• Auxiliary layer identified as alpha auxiliary layer
• Contains alpha channel information SEI message
• Reference to Clause 6.9 Solution #4.1: MV-HEVC with auxiliary depth/alpha channels

ISO/IEC 23091-2:2025 CICP Video

• ISO/IEC JTC 1/SC 29/WG 5 specification defines codec-agnostic code points
• New colour primaries field code point (value 129) indicates decoded picture represents alpha channel
• Properties:
• Colour Primaries: Alpha channel
• HasChromaticityCoordinates: 0
• One colour component representing alpha channel
• Can be carried in VUI parameters in AVC and HEVC bitstreams
• Enables alpha channel indication without relying on auxiliary layers design

MIAF and HEIF Support (5.6.3.2)

• Multi-Image Application Format (MIAF) builds on HEIF for storing multiple images
• Both specify same alpha plane format
• Alpha planes defined as "image specifying transparency information of master image"
• Identified using auxiliary image item type: urn:mpeg:mpegB:cicp:systems:auxiliary:alpha

Alpha Plane Interpretation Rules: - Minimum sample value: Transparency (co-located pixel is transparent) - Maximum sample value: Opacity (co-located pixel is opaque) - Alpha value: Normalized between 0.0 and 1.0 - Sample values divided by maximum value (e.g., 255 for 8-bit) provides multiplier for master image intensity - Requirement: Encoded alpha planes must use full sample range (0-255 for 8-bit)

SMPTE RP 157:2012 (5.6.3.3)

Defines signal properties for key/alpha/matte signals (terms used interchangeably):

Properties: - Black level: Complete transparency - White level: Complete opacity - Transfer function: Out of scope, but assumed linear; black/white levels conform to image format specifications - Alpha value: Normalized 0.0 (fully transparent) to 1.0 (fully opaque) - Sample mapping: Co-located with corresponding fill luminance or RGB samples (zero pixel offset) - Timing: Timed coincident with associated fill video signal

ISO/IEC 23008-2 HEVC / ITU-T H.265 (5.6.3.4)

• MV-HEVC enables alpha channel encoding as auxiliary layer
• MPEG Systems WG03 developing Amendment 2 of ISO/IEC 14496-12 8th edition
• Specifies storage of alpha maps in auxiliary video track linked to main video track
• Covers: media handler, track referencing, metadata box for alpha map interpretation

ISO/IEC 14496-12 ISOBMFF (5.6.3.5)

• Amendment 2 in development for alpha map storage
• Auxiliary video track linked to main video track
• Addresses media handler, track referencing, and metadata box aspects

SMPTE ST 268-1:2014 DPX Format (5.6.3.6)

• Digital Picture Exchange Format v2.0 for exchanging digital moving pictures
• Uses ".dpx" file extension
• Stores single raster image with up to eight image elements
• Supports alpha signal carriage
• Alpha element uses same pixel format/data type as other elements (8-bit, 10-bit, 12-bit, 16-bit, or 32-bit floating point)
• Allows both pre-multiplied and non-pre-multiplied alpha

Code Points Supporting Alpha: - Value 4: Alpha (matte) - Value 51: R, G, B, Alpha (A) - Value 52: A, B, G, R - Value 101: CB, Y, A, CR, Y, A (4:2:2:4) - Value 103: CB, Y, CR, A (4:4:4:4)

Functional Requirements (5.6.4)

The CR establishes functional analysis framework based on:

Hardware Impact Assessment

Two possibilities: 1. Existing hardware support: Reference to example hardware products 2. No existing hardware support: Discussion/description with justifications on expected hardware implementation impact, or reference to existing demos

Codec Capabilities

• Capability to losslessly encode alpha information

Impact

• Affected Clauses: 5.6 (new)
• Other Specifications: None affected
• Test Specifications: None affected
• O&M Specifications: None affected

Revision History

• S4-252016
• S4aV250069

Summary of 3GPP Technical Document S4-260143

Document Information

• Type: Change Request (CR 0002 rev 3)
• Specification: TS 26.966 v19.0.0
• Work Item: FS_AVFOPS_MED (Feasibility Study on Audio Video File Operations for Media)
• Category: B (addition of feature)
• Release: Rel-20
• Source: Xiaomi Communications

Purpose and Scope

This CR proposes adding a new scenario (Scenario #6) on Refocusable Video to TR 26.966, addressing objective 1 of identifying relevant new representation formats not yet documented in TS 26.265.

Main Technical Contributions

5.7.1 Overview - Use Case Description

The CR introduces the concept of refocusable video, which enables post-capture modification of depth of field effects (bokeh). Key points:

• Traditional portrait photography achieves bokeh through lens selection
• Digital photography can simulate this effect pre-encoding
• Growing user expectation (especially prosumers) to refocus already captured content
• Technical approach: record sharp video + depth map sequence, then generate bokeh effect per frame during playback/editing

5.7.2 Previous Work in 3GPP

Identifies gap: coded representation of depth maps as part of video bitstream has not been addressed in 3GPP specifications.

5.7.3 Review of Related Work

Comprehensive survey of depth map representation across multiple standards bodies:

5.7.3.1 ISO/IEC 23091-2:2025 CICP Video

• MV-HEVC enables depth map encoding via auxiliary layers
• Auxiliary layer identified as depth auxiliary layer containing depth representation information SEI message
• New color primaries code point (value 130) defined to indicate decoded picture represents depth map
• HasChromaticityCoordinates = 0 (one color component)
• Can be carried in VUI parameters for AVC/HEVC without relying on auxiliary layer design

5.7.3.2 ISO/IEC 23000-22 MIAF and ISO/IEC 23008-12 HEIF

• MIAF builds on HEIF for multiple images, groups, sequences with defined relationships
• Depth maps defined as auxiliary image items
• Identified using auxiliary image item type: urn:mpeg:mpegB:cicp:systems:auxiliary:depth
• Depth map interpretation out of scope; recommends including depth representation information SEI message as item property for HEVC-encoded auxiliary items

5.7.3.3 SMPTE ST 2087:2016 Depth Map Representation

Defines comprehensive depth map data representation with key definitions:

Terminology: - Reference Camera: Camera corresponding to viewpoint (can be virtual) - Depth Map: Array of depth values corresponding to image pixels - Depth Value: Distance in meters from reference camera to object surface, measured parallel to optical axis - Relative Depth Value: Offset and scaled representation of depth value

Two representations specified:

1. 32-bit floating point:
2. IEEE 754 single-precision format
3. Unit: meter (1.0 = 1 meter)
4. Max value: positive infinity (+INF, 0x7F800000)
5. Unknown value: NaN

6. Co-located sample mapping

7. 16-bit floating point:

8. IEEE 754 half-precision format
9. Relative depth values (unitless)
10. Max value: positive infinity (+INF, 0x7C00)
11. Unknown value: NaN
12. Requires metadata: DepthScaleFactor and DepthOffset

5.7.3.4 ISO/IEC 23008-2 HEVC / ITU-T H.265

• MV-HEVC enables depth map encoding as auxiliary layer
• Auxiliary layer identified as depth auxiliary layer with depth representation information SEI message
• References Clause 6.9 Solution #4.1

5.7.3.5 ISO/IEC 14496-12 ISOBMFF

• MPEG Systems WG03 developing Amendment 2 of 8th edition
• Specifies storage of depth map video sequences in auxiliary video track linked to main video track
• Covers: media handler, track referencing, metadata box for depth map interpretation

5.7.3.6 SMPTE ST 268-1:2014 DPX Format

Digital Picture Exchange Format v2.0 for moving pictures:

Depth component support: - Code value 8: Depth (Z) component

Transfer characteristics: - Code 11: Z (depth) – linear - Code 12: Z (depth) – homogeneous (requires distance to screen and angle of view in user-defined section)

5.7.4 Functional Requirements

Outlines analysis framework based on:

1. Hardware impact assessment:
2. Option a: Reference existing hardware product-grade support

3. Option b: Describe expected hardware implementation impact with justifications

4. Codec capabilities: TBD

References Added

The CR adds 9 new normative/informative references covering: - Android AOSP camera bokeh documentation - JVET documents on CICP extensions - ISO/IEC standards (MIAF, ISOBMFF amendments) - SMPTE standards (RP 157, ST 268-1, ST 2087) - Google Dynamic Depth specification - Android MP4-AT file format

Impact Assessment

• Specifications affected: Only TR 26.966
• Other specs: None
• Test specifications: None
• O&M specifications: None

Summary of 3GPP Technical Document S4-260174

Document Information

• Type: Change Request (CR 0003 rev 1)
• Specification: TS 26.966 v19.0.0
• Category: B (addition of feature)
• Release: Rel-19
• Work Item: FS_AVFOPS_MED (Feasibility Study on AVFOPS for Media)
• Source: Xiaomi Communications

Purpose

This CR proposes adding a new scenario to TS 26.966 addressing video with semantic segmentation maps, progressing objective 1 on identifying relevant new representation formats not yet documented in TS 26.265.

Main Technical Contributions

5.8 Scenario #57: Video with Semantic Segmentation Maps

5.8.1 Overview and Use Case Description

Semantic Segmentation Fundamentals - Technique where every pixel in an image is classified into one or more semantic classes - Example classes from Android ARCore Scene Semantics API: sky, building, tree, road, vehicle, sidewalk, terrain, structure, water, object, person - Enables AR applications with advanced video processing (sky replacement, realistic lighting effects)

Mobile Implementation Context - Real-time capture of segmentation maps alongside camera view is commonly available on recent mobile devices - Leverages high-capacity camera/video pipelines and AI frameworks with hardware optimizations - Specialized models exist for specific content types (e.g., multi-class selfie segmentation)

Multi-class Selfie Segmentation Model - Provides 7 classes for selfie shots: - Background - Hair - Body-skin - Face-skin - Clothes - Others (accessories)

Use Cases - Video effects (hair replacement, face filtering) - Video indexing - AI search

5.8.1.2 Example Image Segmentation Method on Mobile Platform

Processing Pipeline Three main steps identified: 1. Frame acquisition 2. AI inference 3. Generation of segmentation map

Implementation Details - Uses Google Media Pipe framework API for image segmentation - AI model performs inference on camera frames - Output format: 2D array of unsigned 8-bit integers - Each value represents estimated category for each input pixel

Class Identifier Mapping For multi-class selfie segmentation: - 0: background - 1: hair - 2: body-skin - 3: face-skin - 4: clothes - 5: others (accessories)

Efficiency Considerations - Direct class identifier representation is inefficient (only 6 values out of 255 used) - Mapping class identifiers to sample value ranges improves: - Transport efficiency - Robustness to encoding artifacts

Example Mapping Table | Class ID | Assigned Value | Sample Range | |----------|---------------|--------------| | 0 | 21 | 0-42 | | 1 | 64 | 43-85 | | 2 | 107 | 86-128 | | 3 | 150 | 129-171 | | 4 | 193 | 172-214 | | 5 | 235 | 215-255 |

5.8.2 Review of Previous Work

• Coded representation of semantic segmentation maps as part of video bitstream has not been addressed in 3GPP specifications until now

5.8.3 Review of Related Work

5.8.3.1 In ISO/IEC 23008-2 HEVC / ITU-T H.265

Current Status in JVET - Encoding of semantic maps not currently enabled by MV-HEVC standard - JVET developing possible MV-HEVC extension with: - New auxiliary layer type called "segmentation plane" - Picture segmentation information SEI message for interpreting decoded samples as class identifiers - Reference: JVET-AN2032 (40th Meeting, Geneva, October 2025)

5.8.4 Functional Requirements

Assessment Framework Two aspects for functional analysis:

1. Hardware Impact Assessment
2. Option a: Existing hardware product-grade support (provide examples)

3. Option b: No existing hardware support (provide justification/description of expected implementation impact)

4. Codec Capabilities

5. TBD (to be determined)

References

• [x1]: ARCore Scene Semantics API documentation
• [x2]: Google AI Edge MediaPipe image segmentation guide
• [x3]: Qualcomm AI Hub semantic segmentation Android
• [x4]: JVET-AN2032 on VSEI extensions
• [x5]: MediaPipe ImageSegmenter API documentation
• [x6]: MediaPipe multi-class selfie segmentation model card

Change Request Summary: FS_AVFOPS_MED Solutions and Mapping Updates

Document Information

• CR Number: 0005
• Specification: TS 26.966 v19.0.0
• Category: B (addition of feature)
• Release: Rel-19
• Work Item: FS_AVFOPS_MED

Purpose

This CR updates the possible solutions related to new use cases, specifically adding solutions for Scenario #5: Video with changeable background.

Main Technical Contributions

1. Updated Solution-to-Scenario Mapping (Clause 6.0)

The CR extends Table 6.0-1 to include two new solutions for Scenario #5:

• Solution #5.1: Multi-layer HEVC with auxiliary alpha layer
• Solution #5.2: Multi-HEVC bitstreams with alpha signalling using CICP

These solutions address video with changeable background use cases.

2. Solution #5.1: Multi-layer HEVC with Auxiliary Alpha Layer (New Clause 6.10)

High-level Description

This solution leverages HEVC multi-layer extensions to carry alpha planes as auxiliary channels:

• Base layer: Contains the video content
• Auxiliary layer: Contains the alpha plane for background changing

Technical Approach

Auxiliary Picture Signalling: - Uses scalability_mask_flag in the Video Parameter Set (VPS) - Sets scalability mask index to '3' (reserved for "Auxiliary" scalability dimension) - AuxId value determines auxiliary picture type: - AuxId = 1: Alpha plane (AUX_ALPHA) - AuxId = 2: Depth picture (AUX_DEPTH) - Additional interpretation information carried via SEI messages (Alpha channel information, Depth representation information)

Profile Considerations

Two possible approaches identified for further study: 1. Multiview profiles (though only one view is present) 2. Combination of non-Multiview profile for base layer with monochrome profile for auxiliary layer

Open Issues: - Different chroma subsampling between layers - Different encoding configurations - Spatial resolution differences - Bit depth variations

3. Solution #5.2: Multi-HEVC Bitstreams with Alpha Signalling Using CICP (New Clause 6.11)

High-level Description

This solution uses two independent HEVC bitstreams: 1. First bitstream: Video content 2. Second bitstream: Alpha plane sequence

Technical Approach

Alpha Plane Signalling: - Alpha plane carried as a single-layer HEVC bitstream - Current HEVC specification lacks explicit signalling for alpha plane sequences - Proposed solution: Use specific code points in VUI information - Reference to potential CICP extension [x2] for signalling via colour_primaries parameter in VUI

VUI Parameters: - Signalling through colour_description_present_flag and related parameters - colour_primaries, transfer_characteristics, and matrix_coeffs fields in VUI

Profile Considerations

Since bitstreams are independent: - Video content bitstream: Any HEVC profile - Alpha plane bitstream: - Monochrome profiles (Monochrome, Monochrome 10, Monochrome 12, Monochrome 16) - 4:2:0 profiles

References Added

• [x2]: JVET-AN1005, "Future CICP extensions (Draft 2)", Joint Video Experts Team, 40th Meeting, Geneva, October 2025

Items for Further Study

Both solutions (#5.1 and #5.2) have evaluation sections marked as "For further study", indicating: - Performance evaluation pending - Profile compatibility analysis needed - Implementation considerations to be determined

3GPP TSG-SA WG4 Meeting #135 - AVFOPS Permanent Document v2.0.0

Document Information

Source: Xiaomi (PD editor)
Title: AVFOPS Permanent Document v2.0.0
Version: 1.1.0
Meeting: SA4#135, February 2026, Goa, India
Agenda Item: 9.5
Document for: Agreement

Main Technical Contributions

1. Introduction and Scope

This permanent document consolidates all conformance-related material for video operation points (VOPS), gathering requirements, frameworks, and test content submitted to SA4 meetings. The document has evolved from VOPS work item to FS_AVFOPS study item.

2. Conformance Framework (Clause 4)

2.1 Sample Bitstream Platform Overview (4.1)

The platform architecture consists of: - Database: Contains descriptions of available sample bitstreams - Hosting server(s): Store submitted bitstreams - Public portal: Enables external users to search and download bitstreams - Bitstream validator: Validates compliance with TS 26.265 constraints prior to upload

The database is proposed as a git repository on web-based platforms (GitHub/GitLab) using JSON/markup files. Each bitstream links to TS numbers and profiles via URNs.

2.2 Bitstream Validator (4.2)

Repository location: https://forge.3gpp.org/rep/sa4/ts-26.265/conformance/bitstream-validator

Key capabilities: - Validates bitstream compliance with video coding specifications and profiles - Validates compliance with TS 26.265 bitstream constraints - Uses reference decoder (JVET) for codec conformance checking - Implements programmatic constraint validation via XML schema

Technical approach: 1. Parse input bitstream and generate XML dump of syntax elements 2. Express VOPS constraints as XML schema (XSD 1.1) 3. Validate XML bitstream description against constraint schemas

Usage workflow: ```

Generate XML description

python -m sa4_bitstream_validator dump bitstream_path description.xml

Validate against operation point schema

python -m sa4_bitstream_validator validate description.xml bitstream_rules/operation_point.xsd ```

Advantages: - Codec-agnostic constraint expression - No programming knowledge required for constraint definition - Reusable bitstream descriptions for database

2.3 VOPS Operation Points as XML Schema (4.2.4)

Constraints defined using XSD 1.1 with xs:assert elements. Example schema provided for MV-HEVC stereo operation point (vops_3gpp-mv-hevc-stereo.xsd) includes validation of: - VPS multi-layer parameters - Layer set configuration - Scalability mask and ScalabilityId constraints - VUI-specific constraints for MV-HEVC - three_dimensional_reference_displays_info SEI message parameters

3. Framework Development Status (4.6)

Comprehensive status tracking table provided covering:

3.1 3GPP Video Representation Formats (4.6.2)

• High-Definition: None implemented
• High Dynamic Range: None implemented
• Stereoscopic format: None implemented

3.2 Common Bitstream Constraints (4.6.3)

AVC Bitstreams: - Motion-vector constraints: None implemented - Rate constraints: None implemented

HEVC Bitstreams: - Progressive constraints: Done - VUI constraints: Work-in-progress (done but not tested with bitstreams) - Frame-packing constraints: None implemented

Specific VUI constraint validations include: - vui_parameters_present_flag = 1 - aspect_ratio_info_present_flag = 1 - video_signal_type_present_flag = 1 and colour_description_present_flag = 1 - video_full_range_flag = 0 - overscan_info_present_flag = 0 - chroma_loc_info_present_flag = 1

Note: Timing information constraints proposed for removal (marked as issues)

3.3 Decoding Capabilities (4.6.4)

Status for various decoder profiles: - AVC decoders (FullHD, UHD, 8K): None implemented - HEVC decoders (HD, FullHD, 8K): None implemented - MV-HEVC-Main-Dual-layers-UHD420-Dec: Work-in-progress - MV-HEVC-Ext-Dual-layers-UHD420-Dec: None implemented - HEVC-Frame-Packed-Stereo-Dec: None implemented

3.4 Video Operation Points (4.6.5)

• AVC/HEVC HD/HDR/UHD operation points: None implemented
• HEVC Stereo operation point: None implemented
• 3GPP MV-HEVC Stereo Operation Point: Work-in-progress
• 3GPP MV-HEVC-Ext Stereo: None implemented

4. Key Changes in Version 1.1.0 (SA4#135)

Alignment with TS 26.265 V19.1.0: - Validation of multi-layer parameters in VPS - Validation of ScalabilityId constraint added - Validation of VUI-specific constraints for MV-HEVC operation points - Validation of three_dimensional_reference_displays_info SEI message

MV-HEVC Stereo Common Bitstream Requirements (6.3.6.2):

Implemented validations: - vps_num_layer_sets_minus1 >= 1 - layer_id_included_flag[1][0] = 1 with at least one other layer included - scalability_mask_flag[1] = 1 - ScalabilityId[1][1] = 1 - default_output_layer_idc = 0 - chroma_format_idc = 1 - aspect_ratio_idc = 1 - Colour primaries/transfer/matrix combinations for SDR HD or HDR - three_dimensional_reference_displays_info SEI message presence and constraints: - num_ref_displays_minus1 = 0 - left_view_id[0] and right_view_id[0] validation against view_id_val

5. Conformance Material (Clause 5)

5.1 HEVC Conformance Material

Source Content: - Polytech Nantes database: 31 sequences, 1920x1080, 10-bit 4:2:2 YUV at 25 fps (availability issues noted)

Compressed Bitstreams:

1. JVET conformance bitstreams: MV-HEVC Extended 10 and Multiview Main 10 profile test streams
2. 2-view configurations
3. 1024x768 and 1920x1088 resolutions

4. Level 4, 30 fps, 300 frames

5. Hummingbird_Spatial (5.1.2.2): New submission

6. Two-layer stereo MV-HEVC bitstream
7. Layer 0: HEVC Main profile (left-eye view)
8. Layer 1: HEVC Multiview Main profile (right-eye view)
9. Includes three_dimensional_reference_displays_info SEI message
10. No frame packing used

Reference Software: - HM reference software for HEVC - HTM reference software for MV-HEVC and 3D-HEVC extensions

6. External References and Background

Annex A provides background on DASH-IF conformance suite approach, noting that existing tools (DASH-IF, GPAC/MP4Box) can parse NAL units and generate XML dumps but do not implement comprehensive video bitstream validation against 3GPP operation point constraints.

Summary

This document represents significant progress in establishing a comprehensive conformance framework for 3GPP video operation points. The main achievements include:

1. Architectural design for bitstream validation platform
2. Working implementation of XML-based validation tool for MV-HEVC stereo constraints
3. Detailed status tracking of all operation points and constraints
4. Initial conformance bitstreams including the new Hummingbird_Spatial sequence

The work-in-progress items focus primarily on MV-HEVC stereo operation points, with most AVC and single-layer HEVC operation points awaiting implementation.