[Bug] [TC-PAVSTI-1.1,1.2] TH is not playing video received from DUT in user Prompt step.

[Ashwinigrl]

Describe the bug

While validating the TC-PAVSTI-1.1 and TC-PAVSTI-1.2 test cases, TH is not able to show the live video in user prompt steps 20 and 22(TC-PAVSTI-1.1) 12 and 14(TC-PAVSTI-1.2) . Followed the steps available in the user guide for run the camera test cases.

Steps followed:

1. The camera feature requires GStreamer to be installed on the Raspberry Pi. Use the following linux command to install into the system:

sudo apt-get install \
    libgstreamer1.0-dev \
    libgstreamer-plugins-base1.0-dev \
    libgstreamer-plugins-bad1.0-dev \
    gstreamer1.0-plugins-base \
    gstreamer1.0-plugins-good \
    gstreamer1.0-plugins-bad \
    gstreamer1.0-plugins-ugly \
    gstreamer1.0-libav \
    gstreamer1.0-tools \
    gstreamer1.0-x \
    gstreamer1.0-alsa \
    gstreamer1.0-gl \
    gstreamer1.0-gtk3 \
    gstreamer1.0-qt5 \
    gstreamer1.0-pulseaudio

2. Follow the following steps to enable this required flag:

3. Open the Chrome browser and navigate to chrome://flags/ in a new tab

4. Search for Insecure origins treated as secure flag

5. Enter the IP of the Test Harness into the field and enable the flag.

6. Relaunch the Browser.

When we run the Other camera test cases like TC-WEBRTC-1.1 to TC-WEBRTC-1.6, We are able to see the live video in TH.

Steps to reproduce the behavior

1. Open the UI
2. Upload the relevant PICS file.
3. Update the UI configuration as per the Test case requirements.
4. Ensure TC-PAVSTI-1.2 test case is selected
5. Executed the below mentioned command to put DUT into a commissionable state, ./apps/chip-camera-app --camera-test-audiosrc
6. Click the Start button on Test-Harness user interface.

Expected behavior

TH should play live video received from DUT.

Log files

TC_PAVSTI_1_2_2026_05_27_04_36_34.log
TC-PAVSTI-1.2(DUT).txt

Logs from TC-WEBRTC-1.1 Test case, we can see the live video in TH user prompt:

TC-WEBRTC-1_1_2026_05_27_10_31_34.log

TC_WEBRTC_1_1(DUT).txt

PICS file

Camera AV Stream Management Cluster Test Plan.xml

Push AV Stream Transport Cluster Test Plan.xml

Screenshots

Environment

TH Version: v2.15+spring2026
Sha: 2ac562d

Additional Information

No response

[abhisheksingh-esp]

The DUT's segment uploads are being rejected by the Push AV server in --strict-mode. From your DUT log:

PUT /streams/1/session_1/video/segment_1001.m4s
< 400 {"errors":["Track name mismatch: video != media, must match TrackName provided in ContainerOptions"]}

Same 400 for every .init and .m4s upload under video/ and audio/ — only session_1/index.mpd is accepted. TH is sending trackName="media" correctly (TH log lines 6905/6995; TC_PAVSTI_1_2.py:252-253), so the DUT may not be honoring CMAFContainerOptions.TrackName from AllocatePushTransport.

[vnkavali]

• If the VideoStreamID field of the passed in TransportOptions is present:
    ◦ Add the provided or selected VideoStreamID as a new entry in the passed in
TransportOptions VideoStreams list using the VideoStreamName 'video'.

• If the AudioStreamID field of the passed in TransportOptions is present:
    ◦ Add the provided or selected AudioStreamID as a new entry in the passed in
TransportOptions AudioStreams list using the AudioStreamName 'audio'.

After the spec updates in 1.5.1, video and audio are the expected paths, not media. So the TC or Test Harness needs to be updated.

I believe the following PRs are related

project-chip/connectedhomeip#71625
project-chip/certification-tool-frontend#35

CC @chulspro

[cecille]

So if a 1.5.1 camera (built off the 1.5 SDK branch) were to go through certification currently

1. would it pass the tests on the 1.5.1 test harness
2. would it pass the tests on the 1.6 test harness
3. would it be spec compliant to 1.5.1?

If a camera were built off the 1.6 branch currently

1. would it pass the tests on the 1.5.1 test harness
2. would it pass the tests on the 1.6 test harness
3. would it be spec compliant to 1.5.1?
4. would it be spec compliant to 1.6?

[cecille]

TrackName is marked as O,D in the current spec and was in 1.5.1 as well. Is the expectation that a device needs to perform actions based on a deprecated field if it's still marked as optional?

[vnkavali]

TrackName is marked as O,D in the current spec and was in 1.5.1 as well. Is the expectation that a device needs to perform actions based on a deprecated field if it's still marked as optional?

@aronrosenberg can answer this best.

From what I know, 1.5.1 DUT simply ignores the TrackName field. It might be marked optional for backwards compatibility with 1.5 controllers.

[aronrosenberg]

TrackName is marked as O,D in the current spec and was in 1.5.1 as well. Is the expectation that a device needs to perform actions based on a deprecated field if it's still marked as optional?

@aronrosenberg can answer this best.

From what I know, 1.5.1 DUT simply ignores the TrackName field. It might be marked optional for backwards compatibility with 1.5 controllers.

TrackName should be ignored in all cases. The O is there to not break 1.5.0 clients.