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!

[cdgraff]

@winlinvip is this real bug? I'm able tu sponsor this fix to go up into prioritization, that currently is affecting my implementation. let me know! thanks!

[cdgraff]

@winlinvip do you think is possible the HLS creation file be atomic operation?

look that something is delayed into the file creation that desynchronise all the timestamps

internal "start" time is perfect but file timestamp is not aligned

Input #0, mpegts, from '1735171995959.ts':
  Duration: 00:00:30.04, start: 6840.001000, bitrate: 2795 kb/s
  Program 1 
    Stream #0:0[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 169 kb/s
    Stream #0:1[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1024x720 [SAR 1:1 DAR 64:45], 25 fps, 25 tbr, 90k tbn, 50 tbc
--
Input #0, mpegts, from '1735172029105.ts':
  Duration: 00:00:30.03, start: 6870.001000, bitrate: 2797 kb/s
  Program 1 
    Stream #0:0[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 136 kb/s
    Stream #0:1[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1024x720 [SAR 1:1 DAR 64:45], 25 fps, 25 tbr, 90k tbn, 50 tbc
--
Input #0, mpegts, from '1735172059100.ts':
  Duration: 00:00:30.03, start: 6900.001000, bitrate: 2797 kb/s
  Program 1 
    Stream #0:0[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 162 kb/s
    Stream #0:1[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1024x720 [SAR 1:1 DAR 64:45], 25 fps, 25 tbr, 90k tbn, 50 tbc
    

The time differences between the timestamps are:

Between 1735171995959 and 1735172029105: 33 seconds and 146 milliseconds.
Between 1735172029105 and 1735172059100: 29 seconds and 995 milliseconds.

The total difference between the first timestamp (1735171995959) and the last one (1735172059100) is 63 seconds and 141 milliseconds.

I tested with RTMP and SRT as origin, just to discard any issue into the source protocol, both cases similar problem, is not constant but many time over a day.

thanks in. advance!