Discrepancy Between File Name Timestamps and ffprobe Start Times in .ts Video Segments

[cdgraff]

Summary

There is a discrepancy between timestamps extracted from file names (in Unix timestamp format) and the start values reported by ffprobe when analyzing .ts video files. This discrepancy affects continuity checks between consecutive video segments.

---

Problem Description

File Names

The .ts files are named using Unix timestamps in milliseconds, e.g., 1731941156130.ts and 1731941124624.ts.

ffprobe Output

The start field from ffprobe shows the starting time of each video segment in seconds:

• For 1731941156130.ts: start: 84503.516978
• For 1731941124624.ts: start: 84473.516978

Discrepancy

1. File Name Difference:
   Calculating the time difference between file names:

Difference = (1731941156130 - 1731941124624) / 1000 = 31.506 seconds

2. ffprobe Difference:
   Using the start values from ffprobe:
   Difference = 84503.516978 - 84473.516978 = 30.000 seconds

Issue

There is a 1.506-second discrepancy between the calculated difference from file names and the ffprobe-reported start values. This inconsistency raises concerns about how timestamps are generated or interpreted, potentially affecting time-sensitive operations like video concatenation or synchronization.

---

Version
SRS/7.0.0(Hang) - Trunk

To Reproduce

vhost __defaultVhost__ {
    http_hooks {
        enabled         on;
        on_hls          https://xxxxx.x.pipedream.net/;
    }
    hls {
        enabled         on;
        hls_path        ./objs/nginx/html;
        hls_fragment    30;
        hls_window      3600;
        hls_dispose     3600;
        hls_ts_file     [app]/[stream]/[timestamp].ts;
    }
}

Start stream and wait is not into all cases some times works well, but in out production cluster we saw the issue many time by hour.
TS files attached as example
1731941156130__144556.ts.zip
1731941124624__144524.ts.zip

Timstamp is really important to us, we use them to create DVR storage and rebuild the HLS manifest on demand, if we can't trust into Timestamp is really complex, and in some cases capture node go internet down, and we need to push async the ts created during that time.

thanks!