Change Request Summary: Missing Description of TD Renderer File Format

Document Information

• Specification: TS 26.258 v18.3.0
• CR Number: 0007
• Category: F (Correction)
• Release: Rel-18
• Work Item: IVAS_Codec

Change Request Details

Reason for Change

The binary file format for the TD (Time Domain) binaural renderer was missing from the specification, making it difficult for implementers to understand and use the TD binaural renderer file.

Summary of Change

This CR adds the missing binary file format specification for the TD binaural renderer by introducing a new Table 3G in clause 5.10.

Technical Contributions

TD Binaural Renderer Binary File Format (New Table 3G)

The CR introduces a comprehensive specification for the HR (Head-Related) filters for the TD binaural renderer entries, including:

Basic Parameters

• Filter method: TDREND_HRFILT_Method_BSplineModel (value 0)
• Latency value and scaling factor
• UseItdModel flag: Indicates if ITD (Interaural Time Difference) model is used
• Sampling rate: 16, 32, or 48 kHz
• Filter length: K
• Number of elevation basis functions: P

Elevation and Azimuth B-Spline Model Parameters

• Elevation knot sequence (elevKSeq) with length P-2
• For each elevation:
• Number of azimuth basis functions
• Azimuth start index
• Azimuth knot sequence (azimKSeq) including both 0 and 360 degrees

Alpha Weights

• Number of alpha weights (AlphaN)
• Scaling factor for alpha weights
• Alpha weights for both left and right channels (AlphaN * K elements each)

Azimuth B-Spline Shape Parameters

• Number of unique azimuth B-spline shapes (N_azim)
• For each unique shape:
• Number of azimuth B-spline shape elements
• Scaling factor
• Shape elements
• Number of azimuth segment samples
• Azimuth shape indices for each elevation knot point
• Azimuth shape sampling factors

Elevation B-Spline Parameters

• B-spline lengths (4 coefficients)
• B-spline start indices (4 coefficients)
• Number of elevation spline shape elements (N_elev)
• Scaling factor and shape elements
• Number of elevation segment samples

Energy Parameters

• Scaling factor for energy of impulse response
• Energy of impulse response for left channel (3 * AlphaN elements)
• Energy of impulse response for right channel (3 * AlphaN elements)

Conditional ITD Model Parameters (if UseItdModel = 1)

When the ITD model is enabled, the following additional parameters are included:

• Number of elevations in ITD model (P_ITD)
• ITD elevation knot sequence (elevKSeqITD) with length P_ITD - 2
• Number of ITD azimuth basis functions (Q_ITD)
• ITD azimuth knot sequence (azimKSeqITD) with length Q_ITD - 3
• Weight W parameters:
• Number of elements (WN)
• Scaling factor
• Weight elements
• Azimuth ITD B-spline parameters:
• Lengths (4 elements)
• Start indices (4 elements)
• Number of shape elements (N_azim_ITD)
• Scaling factor and shape elements
• Number of segment samples
• Elevation ITD B-spline parameters:
• Lengths (4 elements)
• Start indices (4 elements)
• Number of shape elements (N_elev_ITD)
• Scaling factor and shape elements
• Number of segment samples

Integration with Existing Framework

The new Table 3G is integrated into the existing HRTF filter file format structure defined in clause 5.10, which already includes: - File header format (Table 3A) - Entry headers (Table 3B) - HR filters for other renderer types (Tables 3C-3F)

The TD renderer entry follows the same container format with header and raw data structure as other renderer types, maintaining consistency with the specification's overall architecture.

Change Request Summary: Missing TD Renderer File Format

Document Information

• Specification: TS 26.258 v19.1.0
• CR Number: 0008
• Category: A (mirror corresponding to a change in an earlier release)
• Release: Rel-19
• Work Item: IVAS_Codec

Change Request Details

Reason for Change

The binary file format for the TD (Time Domain) binaural renderer was missing from the specification, making it difficult for implementers to understand and use the TD binaural renderer file.

Summary of Change

This CR adds the missing binary file format specification for the TD binaural renderer by introducing a new Table 3G in clause 5.10.

Technical Contribution

TD Binaural Renderer Binary File Format (New Table 3G)

The CR defines a comprehensive binary file format structure for the TD renderer with the following key components:

Basic Parameters (Offsets 0-12)

• Filter method: TDREND_HRFILT_Method_BSplineModel (value 0)
• Latency value and scaling factor
• UseItdModel flag: Indicates if ITD (Interaural Time Difference) model is used
• Sampling rate: 16, 32, or 48 kHz
• Filter length (K)

B-Spline Model Parameters (Offsets 14+)

• Elevation basis functions (P): Number and knot sequence
• Azimuth parameters: For each elevation, includes:
• Number of azimuth basis functions
• Azimuth start index
• Azimuth knot sequence with scaling factor

Alpha Weights (Variable Offsets)

• Number of alpha weights (AlphaN)
• Scaling factor
• Alpha weights for both left and right channels (AlphaN * K elements each)

Azimuth B-Spline Shapes

• Number of unique azimuth B-spline shapes (N_azim)
• For each shape:
• Number of elements
• Scaling factor
• Shape elements
• Number of segment samples
• Shape indices and sampling factors for each elevation knot point

Elevation B-Spline Parameters

• B-spline lengths and start indices (4 coefficients)
• Number of elevation spline shape elements (N_elev)
• Scaling factor and shape elements
• Number of elevation segment samples

Energy Parameters

• Scaling factor for impulse response energy
• Energy values for left and right channels (3 * AlphaN elements each, corresponding to HRTF_MODEL_N_SECTIONS = 3)

Optional ITD Model Parameters (if UseItdModel = 1)

When ITD modeling is enabled, additional parameters are included:

• ITD Elevation Parameters:
• Number of elevations (P_ITD)

• ITD elevation knot sequence with scaling factor

• ITD Azimuth Parameters:

• Number of ITD azimuth basis functions (Q_ITD)
• Azimuth knot sequence for ITD

• B-spline lengths and start indices (4 coefficients)

• Weight Parameters:

• Number of weight elements (WN)
• Scaling factor

• Weight elements (W)

• ITD B-Spline Shapes:

• Azimuth B-spline shape elements (N_azim_ITD) with scaling
• Number of azimuth segment samples
• Elevation B-spline lengths and start indices (4 coefficients)
• Elevation B-spline shape elements (N_elev_ITD) with scaling
• Number of elevation segment samples

Integration with Existing File Format

The new Table 3G integrates with the existing HRTF binary file structure defined in the specification: - Uses the same header format (Table 3A) with "IVASHRTF" identifier - Uses the same entry header format (Table 3B) with renderer type HRTF_READER_RENDERER_BINAURAL_OBJECTS_TD - Input audio configuration is always BINAURAL_INPUT_AUDIO_CONFIG_UNDEFINED for TD renderer - Can be combined with other renderer types in the same binary file

Technical Notes

• All filter values are represented in fixed-point format
• The notation refers to equation (7.2-6) in clause 7.2.2.2.2 of the referenced specification
• The format supports variable-length data structures with explicit size parameters
• Scaling factors are provided throughout to enable proper fixed-point arithmetic

Summary of 3GPP CR S4-260085

Change Request Details

• Specification: TS 26.114 v18.12.0
• CR Number: 0605
• Category: F (Correction)
• Release: Rel-18
• Work Item: IVAS_Codec

Main Technical Contribution

Problem Statement

The document identifies an inconsistency in the bandwidth computation procedure for the IVAS codec specified in clause Z.2 compared to the general session setup procedures defined in clause 6.2.7.2 of TS 26.114. Specifically, the IVAS-specific procedure includes RTCP bandwidth in the b=AS (Application-Specific maximum bandwidth) calculation, while other codecs and general procedures do not.

Technical Solution

The CR proposes a correction to clause Z.2 "Procedure for computing the bandwidth" to align the IVAS codec bandwidth calculation with existing procedures for other codecs.

Modified Bandwidth Calculation Procedure

The updated procedure for computing b=AS when no extra bandwidth is allocated for redundancy:

1. Use the highest negotiated bitrate for the IVAS codec included in the SDP (using ibr or ibr-recv parameters if specified)
2. Calculate bitrate for the RTP payload header
3. Add bandwidth needed for PI (Primary Importance) data (using pi-br or pi-br-recv parameters if specified)
4. Add bandwidth needed for IP, UDP and RTP headers assuming 50 frames per second:
5. 16 kbps for IPv4
6. 24 kbps for IPv6
7. ~~Add bandwidth needed for RTCP~~ (REMOVED)
8. The b=AS bandwidth is the sum of the above listed bitrates after rounding up to nearest integer kbps

Key Change: Step 5 (adding RTCP bandwidth) has been removed from the calculation procedure, and the subsequent step has been renumbered from 6 to 5.

Impact

The CR ensures consistency across TS 26.114 by removing the RTCP bandwidth component from the IVAS-specific b=AS calculation, aligning it with the treatment of other codecs in the specification. This eliminates ambiguity in bandwidth modifier handling for IVAS codec implementations.

Summary of 3GPP CR S4-260086

Change Request Details

• Specification: TS 26.114 v19.2.0
• CR Number: 0606
• Category: A (mirror CR)
• Release: Rel-19
• Work Item: IVAS_Codec

Main Technical Contribution

Problem Statement

This CR addresses an inconsistency in the bandwidth computation procedure for the IVAS codec specified in clause Z.2 of TS 26.114. The current procedure includes RTCP bandwidth in the b=AS (Application-Specific maximum bandwidth) calculation, which is inconsistent with: - Bandwidth computation procedures for other codecs - General session setup procedures defined in clause 6.2.7.2

Technical Solution

The CR modifies the bandwidth computation procedure in clause Z.2 by removing step 5 which adds bandwidth for RTCP to the b=AS calculation.

Modified Procedure

The updated bandwidth calculation procedure for IVAS codec (when no extra bandwidth is allocated for redundancy) now consists of:

1. Use the highest negotiated bitrate for IVAS codec from SDP (using ibr or ibr-recv parameters if specified)
2. Calculate bitrate for RTP payload header
3. Add bandwidth for PI (Primary Importance) data (using pi-br or pi-br-recv parameters if specified)
4. Add bandwidth for IP, UDP and RTP headers assuming 50 frames per second:
5. 16 kbps for IPv4
6. 24 kbps for IPv6
7. ~~Add bandwidth needed for RTCP~~ (REMOVED)
8. Round up the sum to nearest integer kbps to determine b=AS bandwidth

For SDPs with multiple codecs/configurations, the b=AS is set to the highest calculated bandwidth across all configurations.

Impact

This alignment ensures consistent bandwidth handling across all codecs in TS 26.114 and removes ambiguity in IVAS codec bandwidth computation. Without this correction, implementations could incorrectly allocate bandwidth for IVAS sessions.

Summary of S4-260156: Non-BE Conformance of Metadata Output in IVAS

1. Introduction and Background

The document addresses conformance testing issues for IVAS codec as defined in TS 26.252. Current conformance requirements include: - Bit-exact conformance for both fixed-point and floating-point implementations (audio signal and metadata output) - Non-bit-exact conformance with tolerances for floating-point implementations - Current limitation: Metadata output deviation is set to zero (no deviation allowed)

2. Observed Issues

Platform-Specific Non-Bit-Exact Behavior

Post-Release 19 experiments revealed that metadata output does not always remain bit-exact compared to conformance references across different platforms.

Specific example identified: - Platform: Apple MacBook Pro with M4 ARM processor, Mac OS 15.7.3, Clang 16 - Issue: OMASA decoder conformance test vector produces minor numeric differences in output MASA metadata - Specific differences: - Direct-to-total and diffuse-to-total ratios affected - 9 frames contain maximum absolute difference of 1/255 each - Subjective impact is minimal

Broader Implications

• Similar differences expected on other platforms
• Encoder-side implementation differences may create larger differences in spatial direction metadata due to minor metadata value changes affecting encoding decisions

Analysis Tool Development

A MASA metadata difference tool has been developed as part of IVAS public collaboration to analyze metadata differences: - Provides overall and frame-by-frame statistics - Reports maximum and mean absolute difference values for spatial metadata parameters - Includes difference reporting for descriptive metadata parameters - Details provided in Annex A

3. Conclusions and Recommendations

The source proposes that non-bit-exact tolerance for metadata in Annex A.3.1.2 of TS 26.252 should be adjusted.

Next steps requested: - Additional experiments needed to establish suitable criteria for non-bit-exact metadata conformance - Invitation to IVAS codec implementors to share non-bit-exact results - Goal: Set reasonable limits for both MASA metadata and ISM metadata conformance - Ensure high-quality implementations across different platforms

Annex A: MASA Metadata Difference Tool (masaDiffTool)

A.1 Purpose and Scope

Informative tool designed to support evaluation of non-bit-exact behavior in MASA-format metadata produced by IVAS implementations. Primary use case: comparison between reference and alternative implementations.

A.2 Tool Functionality

Validation and comparison features: - Validates both inputs use IVASMASA format - Performs structured comparison of descriptive and spatial metadata across all frames - Reports exact matches or identifies differing frames - Computes aggregated difference measures (maximum and mean absolute deviations) for key spatial parameters - Returns 0 only if metadata files are identical

Error handling: - Stops comparison if metadata format doesn't match IVASMASA - Classifies frames with mismatched numbers of spatial directions as entirely different and continues with next frame

A.3 Tool Usage

Command syntax: masaDiffTool [options] refMetaFile cutMetaFile

Optional output formats:

1. Text report (--report <file>): Frame-by-frame summary including spatial and descriptive metadata differences
2. CSV report (--csv <file>): Structured per-frame table with key difference indicators and summary metrics

Standard output includes: - Overall metadata difference status - Count of frames with differences - Summary status for descriptive and spatial metadata - Aggregated maximum and mean absolute differences across all frames for: - Direction - Energy ratios - Coherence measures

A.4 Availability

• Binary version available in IVAS codec public repository (3GPP Forge)
• Will be contributed to official TS 26.252 software package during next update cycle

Summary of 3GPP Technical Document S4-260166

Document Information

• Change Request: CR 0002 rev 1 to TS 26.119 v18.0.0
• Title: Assignment of IVAS levels to device types
• Source: Dolby Laboratories Inc.
• Work Items: MeCAR, IVAS_Codec
• Category: F (correction)
• Release: Rel-18

Purpose and Rationale

Reason for Change

The specification previously lacked concrete assignments of IVAS (Immersive Voice and Audio Services) capabilities to XR device types. Placeholder notes indicated that such assignments would be made once IVAS capability levels were defined. Since IVAS capability levels are now specified, this CR removes the placeholder notes and provides the actual capability assignments.

Consequences if Not Approved

Without this correction, implementers would remain unclear about which IVAS capability levels need to be implemented in AR/XR devices, leading to potential interoperability issues and implementation confusion.

Technical Changes

The CR modifies four subclauses (10.2.4, 10.3.4, 10.4.4, and 10.5.4) corresponding to the four XR device types. The changes follow a consistent pattern across device types, with variations in the specific IVAS levels assigned.

Device Type 1 (Clause 10.2.4)

Decoding Capabilities: - Should support: Changed from generic "IVAS" with placeholder note to specific "IVAS-SR" capability - Removed placeholder note about refinement

Encoding Capabilities: - Should support: Changed from generic "IVAS" with placeholder note to specific "IVAS-L1" capability - Removed placeholder note about refinement

Device Type 2 (Clause 10.3.4)

Decoding Capabilities: - Should support: Changed from generic "IVAS" with placeholder note to specific "IVAS-L1" capability - Removed placeholder note about refinement

Encoding Capabilities: - Should support: Changed from generic "IVAS" with placeholder note to specific "IVAS-L1" capability - Removed placeholder note about refinement

Device Type 3 (Clause 10.4.4)

Decoding Capabilities: - Should support: Retains generic "IVAS" (full capability) - Removed placeholder note about refinement

Encoding Capabilities: - Should support: Retains generic "IVAS" (full capability) - Removed placeholder note about refinement

Device Type 4 (Clause 10.5.4)

Decoding Capabilities: - Should support: Retains generic "IVAS" (full capability) - Removed placeholder note about refinement

Encoding Capabilities: - Should support: Retains generic "IVAS" (full capability) - Removed placeholder note about refinement

Implementation Approach

Revision History: - Initial version (SA4#134): Implemented changes with direct referencing of IVAS codec specifications - Rev 1 (SA4#135): Modified implementation to reference IVAS decoding capabilities in TS 26.117

Related Specifications

This CR affects: - TS 26.117 CR 0013: Related change request (presumably defining the IVAS capability levels referenced)

Summary of IVAS Level Assignments

| Device Type | Decoding Capability | Encoding Capability | |-------------|---------------------|---------------------| | Type 1 | IVAS-SR | IVAS-L1 | | Type 2 | IVAS-L1 | IVAS-L1 | | Type 3 | IVAS (full) | IVAS (full) | | Type 4 | IVAS (full) | IVAS (full) |

The assignment shows a tiered approach where Device Types 1 and 2 support specific IVAS levels (SR and L1), while Device Types 3 and 4 support full IVAS capabilities, likely reflecting different device complexity and capability requirements.

Change Request Summary: Assignment of IVAS Levels to Device Types

CR Metadata

• Document: TS 26.119 v19.0.0
• CR Number: 0003 rev 1
• Category: A (mirror corresponding to a change in an earlier release)
• Release: Rel-19
• Work Items: MeCAR, IVAS_Codec
• Source: Dolby Laboratories Inc.

Reason for Change

The specification currently contains placeholder notes indicating that IVAS capability levels would be assigned to XR device types once the IVAS capability levels were defined. Since IVAS capability levels have now been specified, this CR removes the placeholder notes and provides the actual assignment of IVAS capabilities to the different XR device types.

Summary of Technical Changes

This CR updates the audio/speech capabilities support clauses for all four XR device types by: 1. Removing informative notes stating that IVAS level assignments would be refined later 2. Specifying concrete IVAS capability levels for each device type 3. Implementing the change by referencing IVAS decoding capabilities defined in TS 26.117

Detailed Technical Contributions

Device Type 1 Audio/Speech Capabilities (Clause 10.2.4)

Decoding Capabilities: - Changed from generic "IVAS-SR" (with note) to specific "IVAS-L1" as a SHOULD requirement - Removed placeholder note about future refinement

Encoding Capabilities: - Maintains "IVAS-L1" as a SHOULD requirement - Removed placeholder note about future refinement

Device Type 2 Audio/Speech Capabilities (Clause 10.3.4)

Decoding Capabilities: - Changed from generic "IVAS-SR" (with note) to specific "IVAS-L1" as a SHOULD requirement - Removed placeholder note about future refinement

Encoding Capabilities: - Maintains "IVAS-L1" as a SHOULD requirement - Removed placeholder note about future refinement

Device Type 3 Audio/Speech Capabilities (Clause 10.4.4)

Decoding Capabilities: - Maintains generic "IVAS" as a SHOULD requirement (no level specified) - Removed placeholder note about future refinement

Encoding Capabilities: - Maintains generic "IVAS" as a SHOULD requirement (no level specified) - Removed placeholder note about future refinement

Device Type 4 Audio/Speech Capabilities (Clause 10.5.4)

Decoding Capabilities: - Maintains generic "IVAS" as a SHOULD requirement (no level specified) - Removed placeholder note about future refinement

Encoding Capabilities: - Maintains generic "IVAS" as a SHOULD requirement (no level specified) - Removed placeholder note about future refinement

Related Specifications

This CR has a corresponding change in: - TS 26.117 CR 0014 (related specification for IVAS capabilities)

Consequences if Not Approved

Without this CR, implementers would remain confused about which IVAS capability levels need to be implemented in AR/XR devices, as the specification would continue to contain only placeholder notes rather than normative requirements.

Revision History

• Initial version (SA4#134): Implemented the change with direct referencing of IVAS codec specifications
• Rev 1 (SA4#135): Modified implementation to reference IVAS decoding capabilities in TS 26.117 instead of direct codec specification references

Summary of 3GPP Technical Document S4-260176

Document Information

• CR Number: 0013
• Specification: TS 26.117 v18.4.0
• Category: F (Correction)
• Release: Rel-18
• Work Item: IVAS_Codec

Purpose and Rationale

This Change Request addresses the incomplete referencing of IVAS codec levels defined in TS 26.250. The document removes placeholder text stating "IVAS codec level setting is TBD" and replaces it with proper IVAS level-specific capabilities to prevent implementer confusion regarding required encoder/decoder capabilities for given services.

Technical Contributions

1. Decoding Capabilities (Clause 5.2)

Additions: - Introduced three distinct IVAS decoding capability levels: - IVAS-L1: All decoding and rendering requirements for level 1 of the IVAS codec - IVAS-L2: All decoding and rendering requirements for level 2 of the IVAS codec - Both reference the complete suite of IVAS specifications (TS 26.250-26.258)

Clarifications: - Maintained existing IVAS capability definition (all levels) - Maintained IVAS-SR (split rendering) capability definition - Retained note that IVAS decoder supports EVS decoding, meaning IVAS/IVAS-L1/IVAS-L2 capabilities imply EVS capability support

2. Encoding Capabilities (Clause 5.3)

Additions: - Introduced two distinct IVAS encoding capability levels: - IVAS-L1: All encoding requirements for level 1 of the IVAS codec - IVAS-L2: All encoding requirements for level 2 of the IVAS codec - Both reference TS 26.250, 26.252, 26.253, 26.251 (fixed-point), and 26.258 (floating-point)

Clarifications: - Maintained existing IVAS encoding capability definition (all levels) - Retained note that IVAS encoder supports EVS encoding, meaning IVAS capability implies EVS capability support

3. IVAS Operation Point - Bitstream Encoding Requirements (Clause 6.3.5.1)

Removals: - Deleted placeholder note: "IVAS codec level setting is TBD"

No changes to: - Input audio format requirements (mono, stereo, binaural, multi-channel, scene-based, MASA, object-based, OSBA, OMASA) - Sampling frequency requirements (8 kHz, 16 kHz, 32 kHz, 48 kHz) - Bitstream encoding specifications

4. IVAS Operation Point - Receiver Requirements (Clause 6.3.5.2)

Modifications: - Updated to reference specific IVAS capability levels: "respective IVAS, IVAS-L1, IVAS-L2 or IVAS-SR media decoding capability" - Added explicit reference to "supported IVAS codec level 1, 2 or 3 or the IVAS split rendering feature"

Removals: - Deleted placeholder note: "IVAS codec level setting is TBD"

Retained: - Note regarding EVS decoding support implication

5. IVAS Operation Point - Sender Requirements (Clause 6.3.5.3)

Modifications: - Updated to reference specific encoding capabilities: "respective IVAS, IVAS-L1 or IVAS-L2-Enc media encoding capability" - Added explicit reference to "supported IVAS codec level 1, 2 or 3"

Removals: - Deleted placeholder note: "IVAS codec level setting is TBD"

No changes to: - Audio format support requirements - Sampling frequency requirements

6. Content Generation Requirements (Clause 7.5.2.5)

Modifications: - Updated first bullet to reference all three encoding capabilities: "IVAS, IVAS-L1 or IVS-L2" - Updated second bullet to reference all three sender requirements: "IVAS, IVAS-L1 or IVAS-L2"

No changes to: - CMAF Track generation requirements - CMAF Media Profile 'civs' conformance - ABR distribution and CMAF Switching Set requirements

Impact

This CR provides clarity on IVAS codec level capabilities, enabling proper implementation guidance for: - Decoder implementations supporting different IVAS levels - Encoder implementations supporting different IVAS levels - Service providers selecting appropriate codec levels for their use cases - Interoperability between different IVAS capability levels

Summary of 3GPP Technical Document S4-260238

Document Information

• CR Number: 0014
• Specification: TS 26.117 v19.1.0
• Category: A (mirror CR for earlier release)
• Release: Rel-19
• Work Item: IVAS_Codec

Purpose and Rationale

This Change Request addresses the incomplete referencing of IVAS codec levels defined in TS 26.250. The document removes placeholder "TBD" (To Be Determined) notes regarding IVAS codec level settings and replaces them with proper references to IVAS level-specific capabilities (Level 1, Level 2, and Level 3).

Main Technical Contributions

1. Decoding Capabilities (Clause 5.2)

Additions: - Introduced three new IVAS level-specific decoding capabilities: - IVAS-L1: All decoding and rendering requirements for Level 1 of the IVAS codec - IVAS-L2: All decoding and rendering requirements for Level 2 of the IVAS codec - Both reference the complete set of IVAS specifications (TS 26.250-26.256, 26.251, 26.258)

Clarifications: - Maintained existing IVAS capability definition (all levels) - Maintained IVAS-SR (split rendering) capability definition - Retained NOTE clarifying that IVAS decoder support implies EVS decoding capability support

2. Encoding Capabilities (Clause 5.3)

Additions: - Introduced two new IVAS level-specific encoding capabilities: - IVAS-L1: All encoding requirements for Level 1 of the IVAS codec - IVAS-L2: All encoding requirements for Level 2 of the IVAS codec - Both reference TS 26.250, 26.252, 26.253, 26.251 (fixed-point), and 26.258 (floating-point)

Clarifications: - Maintained existing IVAS capability definition (all levels) - Retained NOTE clarifying that IVAS encoder support implies EVS encoding capability support

3. IVAS Operation Point - Receiver Requirements (Clause 6.3.5.2)

Changes: - Removed: "NOTE: IVAS codec level setting is TBD" - Modified: Updated receiver requirements to explicitly reference support for "respective IVAS, IVAS-L1, IVAS-L2 or IVAS-SR media decoding capability according to clause 5.2 and to the supported IVAS codec level 1, 2 or 3 or the IVAS split rendering feature" - Retained NOTE about EVS backward compatibility

4. IVAS Operation Point - Sender Requirements (Clause 6.3.5.3)

Changes: - Removed: "NOTE: IVAS codec level setting is TBD" - Modified: Updated sender requirements to reference "respective IVAS, IVAS-L1 or IVAS-L2-Enc media encoding capability according to clause 5.3 in real-time for the audio formats according to the supported IVAS codec level 1, 2 or 3"

5. Content Generation Requirements (Clause 7.5.2.5)

Changes: - Updated to reference support for "all media encoding capabilities for IVAS, IVAS-L1 or IVAS-L2 as defined in clause 5.3" - Updated sender requirements reference to "IVAS, IVAS-L1 or IVAS-L2 as defined in clause 6.3.5.3"

Impact

Consequences if not approved: - Implementers may be confused about required IVAS encoder/decoder capabilities for given services - Lack of clarity on which codec level implementations are needed for specific use cases - Ambiguity in conformance testing and implementation requirements

Technical Specifications Referenced

• TS 26.250-26.256: IVAS codec specifications
• TS 26.251: IVAS fixed-point implementation
• TS 26.258: IVAS floating-point implementation
• Multiple EVS, AMR-WB, and other codec specifications (context)