Yeah I saw this post and also going over documentation on mpegtsmux (again) I saw this nugget:
alignment : Number of packets per buffer (padded with dummy packets on EOS) (-1 = auto, 0 = all available packets, 7 for UDP streaming)
So I set the alignment to 7 and also added a queue upstream of the mpegtsmux element. Streaming from my Laptop to the Nvidia Jetson, this seemed to help things a lot, but only if I don’t push the bitrate. At bitrate=4000000 it seems to be ok. pushing it to 6000000 causes the issue to reappear.
Streaming from the jetson to my laptop, this same fix definitely helps, but there is still significant packet loss, so I suspect mpegtsmux is still reaching its limit.
I have a camera that streams the 720p at 6 Mb/s and I can receive it no problem. My goal is to receive that stream, do some processing on it and then restream it with the processing results. I would think the stream muxing, etc. should be well within the compute capabilities of the Jetson and my laptop, so I’m a little surprised that mpegtsmux appears to be struggling with this.
One sort of big difference between the pipeline on the Jetson and my laptop is that since the jetson is headless, I don’t have a display sink (in addition to the udp sink) so I have to set sync=true to the udp sink so the video streams real-time.
It is curious that this appears to work fine when streaming from the jetson:
gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,width=1280,height=720,framerate=30/1 ! nvvideoconvert ! nvv4l2h264enc bitrate=4000000 preset-level=3 idrinterval=30 ! h264parse config-interval=-1 ! queue ! mpegtsmux alignment=7 ! queue ! udpsink host=10.100.101.52 port=15004
even though it’s streaming at 30fps not 5 fps like my normal pipeline is.