Challenges in Sequential Broadcasting of raw TS Files on UDP Port Using GStreamer with User-Specified Timestamps

Newcomers
1

I’m trying to broadcast raw TS files on a UDP port based on user-specified start and end times, broadcasting each file sequentially within that time range. Trying to broadcast multiple files in sequence but didn’t work. Below is the pipeline I’m using:

Pipeline -

pipeline = f"filesrc location={file_path} ! queue ! tsparse set-timestamps=true ! rtpmp2tpay ! .send_rtp_sink_0 rtpbin ! udpsink host={udp_address} port={udp_port}"

Seek -

    seek_success = pipe.seek_simple(Gst.Format.TIME, Gst.SeekFlags.FLUSH | Gst.SeekFlags.ACCURATE, start_seconds * Gst.SECOND)

For postion check -
success, position = pipe.query_position(Gst.Format.TIME)

Logs -

File start time in seconds: 59400
Start time in seconds: 56
End time in seconds: 94
Calculated duration: 38 seconds
File duration: 120.665312 seconds
0:00:00.074264423 11005 0x58362b7aef60 WARN                 default descriptions.c:747:format_info_get_desc: Unexpected MPEG-1 layer in audio/mpeg, mpegversion=(int)1
0:00:00.074331621 11005 0x58362b7aef60 WARN                 default gst/parse/grammar.y:540:gst_parse_no_more_pads:<tsdemux0> warning: Delayed linking failed.
0:00:00.074336841 11005 0x58362b7aef60 WARN                 default gst/parse/grammar.y:540:gst_parse_no_more_pads:<tsdemux0> warning: failed delayed linking some pad of GstTSDemux named tsdemux0 to some pad of GstRTPMP2TPay named rtpmp2tpay0
0:00:00.074512428 11005 0x58362b7aef00 WARN                 basesrc gstbasesrc.c:3127:gst_base_src_loop:<filesrc0> error: Internal data stream error.
0:00:00.074527849 11005 0x58362b7aef00 WARN                 basesrc gstbasesrc.c:3127:gst_base_src_loop:<filesrc0> error: streaming stopped, reason not-linked (-1)
0:00:00.074552630 11005 0x58362b7aef00 WARN                   queue gstqueue.c:992:gst_queue_handle_sink_event:<queue0> error: Internal data stream error.
0:00:00.074562315 11005 0x58362b7aef00 WARN                   queue gstqueue.c:992:gst_queue_handle_sink_event:<queue0> error: streaming stopped, reason not-linked (-1)

When i run the same pipeline through command line -

image
image1837×175 29.9 KB

Any suggestions or alternatives for handling multiple file broadcasting within the specified time range? Thank you!

2

Why does your debug log with the fatal error talk about GstTSDemux and tsdemux0 even though your pipeline uses tsparse?

3

Apologies for the confusion earlier. It seems the logs were mistakenly attached from a different pipeline involving tsdemux.

4

I have checked using Gst.QueryType but it returned as False.
Log file link - https://drive.google.com/file/d/1LuzyRKnMUknVLrojAI4CsZjn1uU8apCR/view?usp=drive_link

Additionally, I changed the pipeline to do transcoding (decode/encode) and query/seek operation was successfully.
Pipeline -

filesrc location={file_path} ! decodebin ! x264enc tune=zerolatency ! mpegtsmux ! rtpmp2tpay pt=33 ! udpsink host=239.202.0.1 port=3000

However, I want to avoid re-encoding so is there any way I can seek without transcoding the stream?

5

Just checking on this issue. Any updates or suggestions would be greatly appreciated. Thanks!

6

Hi,

The issue is that rtpmp2tpay (and more generically paylaoders, encoders and muxers) only expect continuous streams, and therefore no seeking/flushing.

The trick is to “flatten/swallow” all of those so that the input to those elements is continuous. You could try inserting identity single-segment=True for example, but I’m not 100% sure it will drop the flushes.