A simple pipeline with two sinks freezes

Here is the pipeline:

gst-launch-1.0 -v filesrc location=/home/saihaze/Videos/test.mp4 ! decodebin name=d
d. ! queue ! audioconvert ! avenc_aac ! mux.
d. ! queue ! videoconvert ! tee name=t ! queue ! x264enc ! mux.
mpegtsmux name=mux ! udpsink host=224.1.1.1 port=5000 auto-multicast=true
t. ! queue ! autovideosink

It freezes at the beginning (0 : 0). If I remove autovideosink, the pipeline normally streams the video. In other words, I remove the last line and the pipeline works:

gst-launch-1.0 -v filesrc location=/home/saihaze/Videos/test.mp4 ! decodebin name=d
d. ! queue ! audioconvert ! avenc_aac ! mux.
d. ! queue ! videoconvert ! tee name=t ! queue ! x264enc ! mux.
mpegtsmux name=mux ! udpsink host=224.1.1.1 port=5000 auto-multicast=true

In my application, autovideosink’s replaced by gtk4paintablesink, and the pipeline still freezes.

I do not have x264enc and replace it with vah264enc. The following pipeline works on my computer Ubuntu 22.04 and Gstreamer 1.24.3
gst-launch-1.0 -v filesrc location=/home/saihaze/Videos/test.mp4 ! decodebin name=d
d. ! queue ! audioconvert ! avenc_aac ! mux.
d. ! queue ! vapostproc ! tee name=t ! queue ! vah264enc ! mux.
mpegtsmux name=mux ! udpsink host=127.0.0.1 port=5000 auto-multicast=true
t. ! queue ! autovideosink

In its default configuration x264enc will consume a lot of input buffers (often 2.5-3 seconds worth) before outputting any data, for best quality.

However, queue by default can only accommodate up to 1s of data (max-size-time property), at which point it will block the input.

Here, the audio and the video come from the same input (qtdemux inside decodebin), so when the audio queue runs full the qtdemux gets blocked and no more video data goes into the x264enc which hasn’t output anything yet. This is a problem because GStreamer has a “preroll” process where all sinks in the pipeline need a first buffer for the pipeline to preroll and go into PAUSED state, which is needed before the pipeline can go into PLAYING state.

You can fix this by

  1. setting e.g. x264enc tune=zerolatency (at expense of quality, but you can also reduce the lookahead via other properties to find a middle ground).
  2. setting queue max-size-time=0 max-size-buffers=0 max-size-bytes=0 on the queue in the audio branch, so that it can expand until x264enc starts outputting things.