Pipeline blocking when part of an mp4mux is not receiving data

[Nicolas Dufresne]

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.

> 
> thanks!
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel