1

I'm relatively new to gstreamer, looking for some debugging ideas. I'm looking at video streaming with H264, RTP, UDP and set up some test send and receive scripts as a proof of concept. Instead of actual network I used localhost and kept all code on a single PC.

Sender

gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480 !\
timeoverlay !\
x264enc tune=zerolatency byte-stream=true bitrate=3000 !\
h264parse  !\
rtph264pay !\
udpsink host=localhost port=5200

Receiver

gst-launch-1.0 udpsrc port=5200 !\
application/x-rtp,encodingname=H264,payload=96 !\
rtph264depay !\
h264parse !\
avdec_h264 !\
autovideosink

This nearly works. The test video is shown, but after a few seconds most of the image (the colour blocks) disappears and only the noise box is shown bottom right. Then a few seconds later it flickers back, and so on.

I can see it's likely to be something with queuing or buffering or sync or bandwidth? It's not lost content on actual network because I'm going through localhost for the UDP traffic. Kinda thrashing about here, adding and removing various parameters and not making much difference. And yes, some of this is copypasta and I may not know quite what I'm doing.

If there's nothing obvious, how can I go about debugging this?

I don't think it's raw CPU power, as top doesn't indicate I'm close to 100% CPU.

Rob Burbidge
  • 23
  • 5
  • SHould add - I guess it's entirely possible that I'm just flooding too many UDP packets. Should I try dropping the transmission bitrate, or adding a queue on receiever? – Rob Burbidge Jan 27 '22 at 18:00
  • Cautiously I may have a solution. Adding a queue element in the received before rtph264depay works better, so I guess it was just dropping too many UDP packets across the localhost interface? Still wishing the diagnostics were more user friendly, but then again I accept this is subjective and the subject matter is not trivial. – Rob Burbidge Jan 28 '22 at 12:03

1 Answers1

1

You may try adding rtpjitterbuffer in receiver:

gst-launch-1.0 udpsrc port=5200 ! application/x-rtp,encoding-name=H264,payload=96 ! rtpjitterbuffer latency=0 ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink
SeB
  • 1,159
  • 6
  • 17
  • Would the be INSTEAD of the queue I suggested (which is what you've said) or maybe IN ADDITION? I guess, the former. As I say I am still learning. – Rob Burbidge Jan 31 '22 at 13:13
  • You can keep a queue after rtpjitterbuffer, but it may not be required. Just try the pipelinie. – SeB Jan 31 '22 at 18:45