Issue with mpegtsmux when m2ts-mode=true

General Discussion
1

Description: I’m encountering an issue with the mpegtsmux element in my GStreamer pipeline when setting the m2ts-mode property to true . When m2ts-mode=true , the pipeline fails to process pending packets correctly, leading to problems with PCR values and packet accumulation.

Pipeline -

GST_DEBUG=“mpegtsmux*:7” gst-launch-1.0 filesrc location=video_file.mp4 ! decodebin name=decoder ! queue ! videoconvert ! videoscale ! timeoverlay ! tee name=t t. ! queue ! fakesink sync=false t. ! queue ! openh264enc ! video/x-h264 ! mpegtsmux name=mux m2ts-mode=false ! udpsink host=127.0.0.1 port=5002 sync=false

type or pas0:00:03.172236159  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:231:new_packet_m2ts:<mux> Outputting a packet of length 192 PCR 97753553450
0:00:03.172240387  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:231:new_packet_m2ts:<mux> Outputting a packet of length 192 PCR 97753767700
0:00:03.172245336  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:231:new_packet_m2ts:<mux> Outputting a packet of length 192 PCR 97753981950
0:00:03.172264087  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:231:new_packet_m2ts:<mux> Outputting a packet of length 192 PCR 97754196200
0:00:03.172268119  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:231:new_packet_m2ts:<mux> Outputting a packet of length 192 PCR 97754410450
0:00:03.172271714  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:249:new_packet_m2ts:<mux> Outputting a packet of length 192 PCR 97754624700
0:00:03.172277238  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:156:new_packet_m2ts:<mux> Have buffer 0x7184dc0387e0 with new_pcr=-1
0:00:03.172284941  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:165:new_packet_m2ts:<mux> Accumulating non-PCR packet
0:00:03.172289960  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:156:new_packet_m2ts:<mux> Have buffer 0x7184dc015120 with new_pcr=-1
0:00:03.172292576  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:165:new_packet_m2ts:<mux> Accumulating non-PCR packet
0:00:03.172312822  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:156:new_packet_m2ts:<mux> Have buffer 0x7184dc045240 with new_pcr=-1
0:00:03.172315704  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:165:new_packet_m2ts:<mux> Accumulating non-PCR packet
0:00:03.172322334  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:156:new_packet_m2ts:<mux> Have buffer 0x7184dc051b40 with new_pcr=-1
0:00:03.172327389  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:165:new_packet_m2ts:<mux> Accumulating non-PCR packet
0:00:03.172409417  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:156:new_packet_m2ts:<mux> Have buffer (nil) with new_pcr=-1
0:00:03.172415643  6269 0x603ea509ab00 LOG                mpegtsmux gstmpegtsmux.c:187:new_packet_m2ts:<mux> Processing pending packets; previous pcr 97754624700, previous offset -192, current pcr -1, current offset 768
te code here

However, when I set m2ts-mode=false , the issue seems to be resolved, and I can receive packets from the udpsink port.

image
image1853×218 38.6 KB

Gstreamer Version - Gstreamer 1.20.3

2

Not sure for your case, but I’ve successfully tried with 1.20.3:

Sender:

gst-launch-1.0 filesrc location=video_file.mp4 ! decodebin ! queue ! autovideoconvert ! videoscale ! timeoverlay ! tee name=t     t. ! queue ! fakesink sync=0    t. ! queue ! openh264enc ! h264parse ! mpegtsmux m2ts-mode=true ! udpsink host=127.0.0.1 port=5002

You may also try adding udpsink property such as buffer-size=8000000

Receiver:

gst-launch-1.0 udpsrc address=127.0.0.1 port=5002 ! video/mpegts,systemstream=true,packet-size=192 ! queue ! tsdemux ! decodebin ! queue ! autovideoconvert ! autovideosink

buffer-size is also a property of udpsrc.

Hope it helps. If not enough, you may provide receiver pipeline and errors.

1 Like
3

Thank you for the response !

Trying to extract the payload and determine the stream type (interlace or progressive) on the receiver’s side. Specifically, I want to get the payload information from rtpbin and the stream type from the decodebin pads from the script in which through gstreamer pipeline.

We verified that the frames are being received correctly by using ffplay - udp://address:port and VLC, and the stream plays smoothly.

I’ve tried making changes to the sender pipeline using various elements to set the payload, but I haven’t been able to achieve the desired results.

Could the issue be related to the packet size setting, which is currently limited to 192 bytes?

4

Not sure if you can use m2tsmode=true with rtp.
rtpmp2tpay only supports systemstream with packet size 188.

Sender:

gst-launch-1.0 filesrc location=video_file.mp4 ! decodebin ! queue ! autovideoconvert ! videoscale ! timeoverlay ! tee name=t     t. ! queue ! fakesink sync=0    t. ! queue ! openh264enc ! h264parse ! mpegtsmux ! rtpmp2tpay ! udpsink host=127.0.0.1 port=5002

Receiver:

gst-launch-1.0 udpsrc address=127.0.0.1 port=5002 ! application/x-rtp,encoding-name=MP2T,clock-rate=90000,payload=33 ! rtpmp2tdepay ! video/mpegts,systemstream=true,packet-size=188 ! queue ! tsdemux ! decodebin ! queue ! autovideoconvert ! autovideosink

Not sure if I can help more your case. Someone better skilled may better advise.