File Duration Mismatch When Using multifilesink

General Discussion
1

Description:
I’m facing an issue with the multifilesink element in GStreamer where the duration logged upon closing a file doesn’t match the actual duration when verified. Specifically, although I set the maximum file duration to 1 minute in the pipeline, the resulting file stream_101_00002.tts has an actual duration of 1:14 when analyzed with gst-discoverer-1.0.

Pipeline -

GST_DEBUG=“multifilesink*:6” gst-launch-1.0 udpsrc address=239.202.122.214 port=6310 do-timestamp=true timeout=60000000000 buffer-size=0 caps=“application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)MP2T,payload=(int)103” ! rtpbin name=recv_rtp ! watchdog timeout=300000 ! tee name=raw_stream raw_stream. ! rtpmp2tdepay2 ! video/mpegts,packetsize=192 ! queue ! multifilesink next-file=5 max-file-duration=600000000000 location=stream_%05d.tts

Details:

  • Added debug logs in multifilesink’s gst_multi_file_sink_close_file and gst_multi_file_sink_write_buffer functions to inspect the duration at the time of closing each file.
  • The logs show a calculated duration (based on PTS) of 1:00 (60 seconds) for stream_101_00002.tts, even though the actual file duration, as reported by gst-discoverer-1.0, is 1:14.

Relevant Logs:

0:03:00.096861942 ^[[32m83215^[[00m 0x55ff7c5b7240 ^[[36mINFO   ^[[00m ^[[00m       multifilesink gstmultifilesink.c:742:gst_multi_file_sink_write_buffer:<multifilesink0>^[[00m new_duration: 600001       15419, max. duration 60000000000
0:03:00.097155245 ^[[32m83215^[[00m 0x55ff7c5b7240 ^[[36mINFO   ^[[00m ^[[00m       multifilesink gstmultifilesink.c:1124:gst_multi_file_sink_close_file:<multifilesink0>^[[00m File 'stream_101_0000       2.tts' duration (calculated with PTS): 0:01:00.000115419
201271 0:03:00.097160480 ^[[32m83215^[[00m 0x55ff7c5b7240 ^[[36mINFO   ^[[00m ^[[00m       multifilesink gstmultifilesink.c:1134:gst_multi_file_sink_close_file:<multifilesink0>^[[00m Buffer DTS is invalid
201272 0:03:00.097256008 ^[[32m83215^[[00m 0x55ff7c5b7240 ^[[36mINFO   ^[[00m ^[[00m       multifilesink gstmultifilesink.c:1099:gst_multi_file_sink_open_next_file:<multifilesink0>^[[00m opening file stre       am_101_00003.tts

Verification with gst-discoverer-1.0:

image
image904×340 42.2 KB

Are there recommended approaches to ensure that the actual file duration aligns closely with the specified maximum duration in the pipeline

Any insights or recommendations on resolving this discrepancy would be highly appreciated. Thank you!

2

I think few aspects needs to be analyzed. The time measured to stop recording is based on RTP time only. While the discoverer will use the MPEG TS time information to measure duration. There could be a significant error between the two timeline caused by the sender.

The use of mpegtsparse with the smoothing latency and timestamp reconstruction property could mitigate this. The parser would use the MPEG TS PCR to recreate timestamps.

The second aspect is the nature of the content. multifilesink predates splitmuxsink (which I recommand over multifilesink). The sink may actually wait for non-delta buffers or other generic flags on buffers. Let’s say you have a video stream with key frames every 20s, that gives a split précision of ±20s.

p.s. there is also sinks specialized for HLS and DASH if that is your goal.

3

hi,
Using mpegtsparse with smoothing-latency and set-timestamps=true was suggested as a way to address the TS duration mismatch by reconstructing timestamps based on the MPEG TS PCR. I applied these settings, but unfortunately, the duration issue persisted.

Additionally, I tested dashsink as an alternative, yet the discrepancy remained unresolved.

It’s possible that the duration issue might relate to the use of 192-byte packet sizes for TS files, as these settings appear to work correctly for standard 188-byte TS files.

4

That could be, reading the code that guesses the duration is the way forward.