Issue: rtsp server/v4l2h264enc: Running out of buffers

Archit Taneja architt at codeaurora.org
Tue Mar 26 16:23:29 UTC 2019


Hi,

I'm using the Gst RTSP server to run the following pipeline on a DB410c-like
platform:

v4l2src device=/dev/video0 ! \
video/x-bayer,format=bggr,width=640,height=360 ! bayer2rgb ! \
videoconvert ! videoflip video-direction=90l ! v4l2h264enc ! \
h264parse ! rtph264pay name=pay0 \
alsasrc device=mic ! audioconvert ! rtpL16pay ! name=pay1 pt=97

The video runs for around a minute or so and then freezes, but the audio
continues playing. From the debug logs, it looked like the sink pad
of v4l2h264enc eventually ran out of buffers:

0:02:19.374641729 22423 0xffff60004630 LOG bufferpool gstbufferpool.c:1133:default_acquire_buffer:<v4l2h264enc0:pool:sink> no buffer, trying to allocate
0:02:19.374788761 22423 0xffff60004630 DEBUG bufferpool gstbufferpool.c:304:do_alloc_buffer:<v4l2h264enc0:pool:sink> max buffers reached
0:02:19.374868345 22423 0xffff60004630 LOG bufferpool gstbufferpool.c:1173:default_acquire_buffer:<v4l2h264enc0:pool:sink> waiting for free buffers or flushing

The "waiting for free buffers or flushing" condition happens only if I
restart the RTSP client.

The alsa device here is a "dsnoop" plugin. If I replace it with a
plugin closer to the real hardware(i.e, hw/plughw) I stop seeing the
issue. I also stop seeing the issue if I get rid of the audio portion
of the pipeline altogether.

With the audio pipeline, I also on some occasions see:

0:15:39.195517421 22423 0xaaaaedec8680 WARN audiobasesrc gstaudiobasesrc.c:849:gst_audio_base_src_create:<alsasrc0> warning: Dropped 22528 samples. This is most likely because downstream can't keep up 
and is consuming samples too slowly.
0:15:39.195842787 22423 0xaaaaedec78a0 WARN rtspmedia rtsp-media.c:2446:default_handle_message: 0xffff8405f340: got warning Can't record audio fast enough (gstaudiobasesrc.c(849): 
gst_audio_base_src_create (): /GstPipeline:media-pipeline/GstBin:bin0/GstAlsaSrc:alsasrc0:
Dropped 22528 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.)

I wasn't fully clear on why v4l2h264enc0:pool:sink is reaching the max
buffer (seems like it is 32) condition. I'm assuming the video pipe is
stalled so as to stay in sync with audio?

How can one get around such issues? I tried to put a queue element
between videoflip and v4l2h264enc, but that didn't help.

Thanks,
Archit




More information about the gstreamer-devel mailing list