Issues with GStreamer multifilesink

General Discussion
1

Hi,
I’m working with a GStreamer pipeline to receive an RTP stream and save it as multiple .m2ts files using multifilesink, splitting them every 5 minutes. Here’s the pipeline I’m using:

GST_DEBUG="multifilesink*:4" 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=300000000000 location=stream_%05d.m2ts

The pipeline runs without errors and successfully splits the files at the expected intervals. However, when I analyze the first file (stream_00000.m2ts) using gst-discoverer-1.0, I notice a discrepancy between the file duration logged by multifilesink and the actual duration shown by gst-discoverer.

Logs from multifilesink:

image
image1854×319 68.1 KB

Output from gst-discoverer:

It reports a duration of only 50.52 seconds-

image
image812×367 41.7 KB

Any insights, suggestions, or examples of similar pipelines that work would be greatly appreciated. Thank you!

2

Hi @Nikita

I tested the following pipelines:

UDPSINK

gst-launch-1.0 videotestsrc is-live=true pattern=ball \
! videoconvert ! queue \
! x264enc tune=zerolatency bitrate=500 \
! mpegtsmux !  rtpmp2tpay \
! udpsink host=127.0.0.1 port=5000

UDPSRC

GST_DEBUG="multifilesink*:4" gst-launch-1.0 udpsrc port=5000 \
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" ! rtpmp2tdepay \
! decodebin ! videoconvert  \
! x264enc ! mpegtsmux ! queue \
! multifilesink next-file=5 max-file-duration=300000000000 \
location=stream_%05d.m2ts

With the following logs

0:00:06.486880059 326127 0x624d4a0fe2a0 INFO           multifilesink gstmultifilesink.c:1082:gst_multi_file_sink_open_next_file:<multifilesink0> opening file stream_00000.m2ts
0:05:06.529198818 326127 0x624d4a0fe2a0 INFO           multifilesink gstmultifilesink.c:725:gst_multi_file_sink_write_buffer:<multifilesink0> new_duration: 300033015636, max. duration 300000000000
0:05:06.529816244 326127 0x624d4a0fe2a0 INFO           multifilesink gstmultifilesink.c:1082:gst_multi_file_sink_open_next_file:<multifilesink0> opening file stream_00001.m2ts
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:06:07.652052387
Setting pipeline to NULL ...
Freeing pipeline ...

st-discoverer-1.0 stream_00000.m2ts 
Analyzing file:///tmp/stream_00000.m2ts
Done discovering file:///tmp/stream_00000.m2ts

Properties:
  Duration: 0:05:00.042515370
  Seekable: yes
  Live: no
  container #0: MPEG-2 Transport Stream
    video #1: H.264 (High 4:4:4 Profile)
      Stream ID: a27ecf4b193cfcfde136f34bb1991263db7dcec3424b9d8225e550e211667010:1/00000041
      Width: 320
      Height: 240
      Depth: 30
      Frame rate: 30/1
      Pixel aspect ratio: 1/1
      Interlaced: false
      Bitrate: 0
      Max bitrate: 0

I hope this helps.
Regards!

3

hi @eduardo.salazar
Thank you for the suggested solution! It works well, but I’d like to avoid any encoding and decoding processes when saving the file. Additionally, I’d prefer to use the rtpmp2tdepay2 element (which supports a 192-byte packet size) instead of rtpmp2tdepay (which only supports a 188-byte packet size).

Thanks!