Unrecoverable "error user timestamp" in 2110-20 Tx

[DianaEs2]

The MTL, when used for ST 2110-20 (Uncompressed Video) transmission (Tx), exhibits a lack of resilience to brief data flow interruptions. A short pause in the video data stream results in a fatal, unrecoverable "error user timestamp" condition, requiring a restart of the Tx session.

This branch was tested 88c3566 ("Add: Remove unnecessary alignment of interlaced frames (#1266)", 2025-09-25)
Against this config local_tx_1v.json

A 100ms pause was simulated in app_tx_st20p_frame_thread(), after which the "error user timestamp" appeared in the log. The transmission was broken after this point and was unable to recover.
MTL: 2025-09-29 15:27:43, * * M T D E V S T A T E * *
MTL: 2025-09-29 15:27:43, DEV(0): Avr rate, tx: 1305.139378 Mb/s, rx: 0.000000 Mb/s, pkts, tx: 1233150, rx: 0
MTL: 2025-09-29 15:27:43, SCH(0:sch_0): tasklets 2, lcore 1(t_pid: 1451800), avg loop 204 ns
MTL: 2025-09-29 15:27:43, CNI(0): eth_rx_rate 0.000000 Mb/s, eth_rx_cnt 0
MTL: 2025-09-29 15:27:43, PTP(0): time 1759174100888045689, 2025-09-29 15:28:20
MTL: 2025-09-29 15:27:43, TX_VIDEO_SESSION(0,0:app_tx_st20p_0): fps 59.898881 frames 599 pkts 1233546:0 inflight 69779:69852
MTL: 2025-09-29 15:27:43, TX_VIDEO_SESSION(0,0): throughput 1305.532163 Mb/s: 0.000000 Mb/s, cpu busy 0.655332
MTL: 2025-09-29 15:27:43, TX_VIDEO_SESSION(0,0): error user timestamp 599
MTL: 2025-09-29 15:27:43, TX_VIDEO_SESSION(0,0): interlace first field 300 second field 299
MTL: 2025-09-29 15:27:43, TX_st20p(0,app_tx_st20p_0), p(0:in_transmitting) c(1:in_user)
MTL: 2025-09-29 15:27:43, TX_st20p(0), frame get try 599 succ 600, put 599
MTL: 2025-09-29 15:27:43, * * E N D S T A T E * *

It is expected that MTL should ideally continue transmitting a VRX-compliant stream after a brief interruption (potentially drop a few frames).

[Sakoram]

Failure to deliver video frames in a timely manner causes gaps in the stream because MTL has nothing to send. These “gaps” break compliance, so this is already a bad state that should not be created by the application, but...
Currently, If the application is even slightly late, the frame transmission time is shifted to the next possible time slot, i.e., 1 frame later (e.g., 33 ms later for 30 frames per second). This causes increased delay for all subsequent frames. The delay accumulates with each "gap", which is a serious problem. I agree that we should add an option to recover from this.

My first recommendation to prevent this situation is to fill the MTL frame buffers so that, on average, there are enough frames in the buffer to cover the underflows. This will increase end to end latency, as all buffers will wait longer in the queue.

Currently, there is a statistic that informs you that this “gap” in the stream has been created. It is called “epoch drop.”
As a mitigation, I see two options:

1. In this case, the library should inform the application that an “epoch drop” has occurred. ( e.g. by callback, pollable statistic, event in an event queue etc.) It should be the responsibility of the application to adjust the frame delivery speed to MTL so that frames do not accumulate and consequently do not overflow the frame buffers. This gives the application better control. It can drop some frames or slow down if, for example, it is reading data from a file.
2. MTL should discard late frames itself. This limits the scope of the application's responsibilities and the amount of its control.

If the lib will drop frames it has to be parametrized, as I assume that there are use cases in which dropping frames is not acceptable. Perhaps both solutions can be implemented. I need to investigate this a little bit more.

What are your opinions? What behavior would be desirable in your case?

[cwhite102]

Hi Sakoram,
Thank you for the write up. I agree with your analysis.
It is certainly the case that we never intend to deliver a frame late, but the fact that it can happen means we need it to be recoverable (return to a compliant stream after the glitch).

The simplest and best solution for us would be option (2). I agree it likely should be a parametrized option to indicate the app wants MTL to drop frames which are provided too late to send at their indicated timestamp.