Gstreamer 1.0 no video when udpsink pipeline runs before udpsrc pipeline

Question

I'm trying to stream a webcam feed from Computer A to Computer B via udpsink. If Computer A's pipeline sends data to Computer B before Computer B starts its receiving pipeline through udpsrc, I get no display using vaapisink, xvimagesink, or ximagesink. If Computer B starts his pipeline before any data is streamed to it, I can display Computer A's video feed just fine.

Here are the pipelines I am using from the command line: Computer A:

sudo gst-launch-1.0 -v v4l2src device=/dev/video0 do-timestamp=true ! \
"video/x-raw, format=I420, width=640, height=480, framerate=30/1" ! \
vaapiencode_h264 ! rtph264pay ! udpsink host=192.168.0.31 port=5400

Computer B:

sudo gst-launch-1.0 -v udpsrc port=5400 ! "application/x-rtp, payload=96, \
encoding-name=H264" ! rtph264depay ! vaapiparse_h264 ! vaapidecode ! \
videoconvert ! xvimagesink sync=false async=false

When I use GST_DEBUG=4 on Computer B, I see no errors. What I see through the debug output is that when Computer B starts his pipeline before A, Computer B receives a new GST_EVENT from gst_event_new_caps, and then processes Computer A's stream. But if Computer A's stream is already streaming to Computer B without B's pipeline being initialized, this event is never raised.

Answer 1

Resolution: Add "config-interval=1" (I'm sure another interval amount would be fine - anything but 0) to "rtph264pay" in Computer A's pipeline to read:

sudo gst-launch-1.0 -v v4l2src device=/dev/video0 do-timestamp=true ! \
"video/x-raw, format=I420, width=640, height=480, framerate=30/1" ! \
vaapiencode_h264 ! rtph264pay config-interval=1 ! udpsink host=192.168.0.31 port=5400

Here's what I found out by adding GST_DEBUG=4 to Computer A and B.

When Computer A starts its pipeline, it appears that new GST_EVENTs are called to set new caps only once by default. If Computer B doesn't have its pipeline running, listening on a UDP port for data, it won't detect any new GST_EVENTs that tell Computer B what caps to set.

This explains why these pipelines worked if Computer B's pipeline was running prior to Computer A's; Computer B would catch Computer A's GST_EVENT telling Computer B the type of caps to set.

With config-interval set to something greater than 0, it appears Computer A's stream can then continuously raise GST_EVENTs, letting Computer B stop/start his pipeline and immediately know which caps to set.