Pipeline blocking when part of an mp4mux is not receiving data

Hi everyone,

I noticed in gstreamer 1.18 there is a patch which has ported mp4mux to GstAggregator
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/commit/e2462005fbac72bd49c4158e9476c5f76919f887

I retested the below pipeline example with 1.18.2, but noticed that it still does not work, and the video output blocks after a
few frames of video. I am using async=false everywhere, so hoped that this would work now.

Does anyone have any other suggestions on how to make this work with optional inputs?

thanks,
Wayne

On Sun Aug 25 2019, Nicolas Dufresne wrote: 
>Le jeudi 15 août 2019 à 13:15 -0700, Wayne Piekarski a écrit :
>> Hi everyone,
>> 
>> I have a use case where I'm recording a V4L H264 camera along with a UDP 
>> audio stream into an mp4mux file, and also displaying the video to the 
>> screen.
>> 
>> gst-launch-1.0 -v \
>> mp4mux name=combo fragment-duration=1000 ! fakesink async=false \
>> \
>> v4l2src 
>> device=/dev/v4l/by-path/pci-0000:00:14.0-usb-0:2:1.0-video-index1 
>> do-timestamp=false ! video/x-h264, width=320, height=240, framerate=15/1 
>> ! h264parse ! tee name=tv0 ! queue ! h264parse ! avdec_h264 ! 
>> videoconvert ! autovideosink    tv0. ! queue ! combo.video_0 \
>> \
>> udpsrc port=5701 do-timestamp=false ! application/x-rtp, 
>> clock-rate=44100, config=40002410adca00 ! rtpmp4adepay ! aacparse ! 
>> queue ! combo.audio_1
>> 
>> This works fine if there are UDP packets coming in. However, if the UDP 
>> source has not sent any packets, then the video stops displaying on the 
>> screen after about 50 frames of working fine.
>> 
>> However, if you send just one valid RTP packet to the port, then 
>> everything starts working, and stays working, even though no new UDP 
>> packets are arriving.
>> 
>> Is there anyway to tell the pipeline to not block like this? I tried 
>> putting async=false everywhere as recommended to me in 
>> https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/628 but 
>> that is not working in this new scenario. I've tested this on the latest 
>> gstreamer 1.16.0.
>
>Muxers using GstCollectPad facility have this issue. This could be
>resolved by porting the respective muxer to GstAggregator base class.
>From my knowlege, flvmux has been ported.