Seamless protection switching does not work

[DianaEs2]

Describe the bug
When secondary stream is enabled, receiver cannot get video at all, showing "get frame time out". The receiver gets video from primary only or secondary only just fine.

To Reproduce
To reproduce this, we need to simulate a differential path delay between the primary and secondary.

1. Adjust config to run on your system local_tx_rx_1v.json
   The config runs two st20p tx_sessions. It separates primary and secondary video into its own session. The second session will be delayed (see next step). It also includes one rx_session to receive this video with redundancy.
2. Apply patch to main branch commit-a99be44.patch
   The path simulates a 33 ms delay between primary and secondary tx_sessions.
3. Check the errors in the log_MTL: 2025-08-13 11:10:23, RX_VIDEO_SESSION(1,0:app_rx_st20p_0): fps 0.000000 frames 0 pkts 4933250MTL: 2025-08-13 11:10:23, RX_VIDEO_SESSION(1,0): throughput 5222.458237 Mb/s, cpu busy 1.306945
   MTL: 2025-08-13 11:10:23, RX_VIDEO_SESSION(1,0): incomplete frames 3712362, pkts (idx error: 0, offset error: 0, idx out of bitmap: 0, missed: -1902968538)
   MTL: 2025-08-13 11:10:23, RX_VIDEO_SESSION(1,0): succ burst max 14, avg 1.040188
   MTL: 2025-08-13 11:10:23, RX_st20p(0,app_rx_st20p_0), p(0:free) c(0:free)
   MTL: 2025-08-13 11:10:23, RX_st20p(0), frame get try 10 succ 0, put 0
   MTL: 2025-08-13 11:10:23, * * E N D S T A T E * *_

Expected behavior
Do not apply patch, check the logs
MTL: 2025-08-13 11:11:37, RX_VIDEO_SESSION(1,0:app_rx_st20p_0): fps 59.899091 frames 599 pkts 2466496
MTL: 2025-08-13 11:11:37, RX_VIDEO_SESSION(1,0): throughput 5221.762846 Mb/s, cpu busy 1.233267
MTL: 2025-08-13 11:11:37, RX_VIDEO_SESSION(1,0): redundant pkts 2466496
MTL: 2025-08-13 11:11:37, RX_VIDEO_SESSION(1,0): succ burst max 128, avg 1.039385
MTL: 2025-08-13 11:11:37, RX_st20p(0,app_rx_st20p_0), p(0:free) c(0:free)
MTL: 2025-08-13 11:11:37, RX_st20p(0), frame get try 600 succ 600, put 600
MTL: 2025-08-13 11:11:37, * * E N D S T A T E * *

Configuration and command-line
./tests/tools/RxTxApp/build/RxTxApp --config_file ./config/local_tx_rx_1v.json -test_time 30 --utc_offset -37

Status report
mtl_system_status_20250813114059.zip

Logs
patch.log
main.log

HW specification:

• MTL Version or commit hash
  756b592 ("Add loging into file. Update results with compliance results fixture (Add loging into file. Update results with compliance results fixture #1214)", 2025-07-25)
• OS: Ubuntu 22.04 LTS

Screenshots
Not applicable.

Additional context
Assuming your receiver is Class A, Low-Skew. It should still be able to get video from either of the two streams.
See page 7, st2022-7-2019.pdf

[DawidWesierski4]

Hi
#1300

This PR should fix the issue. Please try it out

[DianaEs2]

I see repeated packets in ancillary rx. Tested this config local_tx_rx_1d.json

Applied this patch commit-2f245fb.patch

Check the log
MTL: 2025-10-28 11:43:34, rx_ancillary_session_handle_pkt(0,1), redundant seq now 1237 session last 1237
MTL: 2025-10-28 11:43:34, rx_ancillary_session_handle_pkt(0,1), redundant seq now 1238 session last 1238
MTL: 2025-10-28 11:43:34, rx_ancillary_session_handle_pkt(0,1), redundant seq now 1239 session last 1239
MTL: 2025-10-28 11:43:34, rx_ancillary_session_handle_pkt(0,1), redundant seq now 1240 session last 1240

[DianaEs2]

Checked 9ed19e6 ("Add: Consistent redundant stream logging", 2025-10-28). It works a little better for ancillary Rx.
But for some reason, the Rx session does not always start up consistently. Ancillary Tx/Rx are in loopback, but still these lines are observed in the log mtl_out.log

MTL: 2025-10-28 15:01:38.041, RX_ANC_SESSION(0:rx_st40_3): fps 0.000000 frames 0 pkts 0 (redundant 1198)
MTL: 2025-10-28 15:01:38.041, TX_ANC_SESSION(0:tx_st40_3): fps 59.900298 frames 599 pkts 599:599

[DawidWesierski4]

yes

The TX side of MTL seemed not to initialize the first packet rtp timestamp of TX, making the initialization of RX think the starting stream time is 0

Hard to shield from this from the RX side (if some stream will send first packet in the "future" the RX will wait for that moment in time, due to the clock used in wraparound. )
The bug from the TX side was fixed in ebfba8f