[BUG] SRT/MPEG-TS Decoding Failure: Progressive PTS Drift in Receiver (Stable on VLC/FFmpeg)

[carlo899]

Hello HaishinKit Team,

I am reporting a stability issue when using HaishinKit as an SRT receiver (player) for live streams contained within MPEG-TS.

The symptom is a progressive Presentation Timestamp (PTS) drift in the player, which eventually leads to video stutters, Audio/Video desynchronization, and failure after a short period.

1. The Core Problem: PTS Sensitivity
   The decoder in HaishinKit exhibits extreme sensitivity to minor PTS inconsistencies that are common in real-time streams, even when the data transmission itself is highly reliable.

2. Definitive Test Results
   We have eliminated network corruption and encoder flaws as the root cause by performing two definitive long-term tests:

Definitive Test Results (Continuous Text)
We have eliminated network corruption and encoder flaws as the root cause by performing two definitive long-term tests, both of which failed unequivocally:

FFmpeg PTS/DTS Correction Test: We applied forced correction filters (setpts=PTS and atempo=1.0) to the source stream to ensure the Presentation Timestamps were clean. Despite this stabilization, the PTS drift in HaishinKit persisted, confirming that simply cleaning the stream is insufficient for the HaishinKit decoder.
SRT Reliability Test with transtype=file (12 hours): We tested the HaishinKit player using the most reliable SRT transport mode (transtype=file) for over 12 hours. This mode virtually eliminates data corruption caused by network packet loss. The PTS drift returned even under these optimal conditions, definitively proving that the issue resides in the internal PTS logic of the decoder, not in network data corruption.
The exact same stream, even the one generated with transtype=file, is decoded perfectly stable and without drift by VLC Media Player and analyzed without critical PTS errors by the FFmpeg decoder.

3. Comparison with Other Players
   The exact same stream (even the one using transtype=file) that causes HaishinKit to drift is decoded perfectly stable by VLC Media Player and analyzed without critical PTS errors by the FFmpeg decoder (libavformat).

4. Action Request
   Based on the evidence, we kindly request an investigation into the robustness of the SRT/MPEG-TS decoding logic in HaishinKit, particularly how it analyzes and maintains the timeline (PTS). The decoder needs to be more tolerant and resilient to minor stream irregularities, similar to standard decoders based on libavformat.

This issue appears related to historical problems with stream stability (e.g., [Issue #1677: High bitrate using SRT may cause video data corruption]), suggesting the need for improved handling of the media layer over SRT.

Thank you for your time and consideration.

[shogo4405]

Every time I see posts like this, I start to think about closing Discussions and Issues, or even shutting down HaishinKit itself.

It’s a long message, but with just “there’s a bug,” “it doesn’t work,” or “it works fine with ffmpeg or VLC, so HaishinKit must be the problem!”—with that level of information, nobody can improve anything.

On my side, I test locally and with other CDNs, and I have never encountered the reported symptoms. You should provide information about your testing environment and setup, as clearly stated in the SUPPORT guidelines. https://github.com/HaishinKit/.github/blob/main/SUPPORT.md

What’s actually “bugged” is this post itself, and it’s a violation of the SUPPORT guidelines.
If things work fine with VLC or ffmpeg, then perhaps you should use those instead.