gst-rtsp-server share v4l2src accross several mounting points
Nicolas Dufresne
nicolas at ndufresne.ca
Mon Nov 25 20:59:52 UTC 2019
Le lundi 25 novembre 2019 à 12:22 -0600, jean-philippe a écrit :
> I return to this topic as the pipeline using intervideosink/src drops frames
> when running my SoC (i.MX8M Mini).
>
> The app implements an RTSP server and I'm sharing the v4l2src with several
> pipelines.
>
> *Pipeline #1* is OK: “v4l2src ! vpuenc_h264 ! rtph264pay”
>
> *Pipeline #2* drops frames:
> “v4l2src ! intervideosink channel=c sync=false”
> “intervideosrc channel=c ! vpuenc_h264 ! rtph264pay”
>
> About 1/3 of frames are dropped intermittently. The pipeline may run well
> for 10 minutes and then drops frames and then recover after a few minutes.
>
> I am wondering if the problem is related to the BufferPool used.
>
> I have noticed that when pipeline #2 starts it prints
> “gstv4l2bufferpool.c:794: … Uncertain of not enough buffers, enabling copy
> threshold”. This does not happen with pipeline #1.
For your information, this means that intervideosink does not reply to
the allocation query. This can have all sort of implication, I think
for your sure case, intervideosink should be fixed. It cannot offer a
pool of course, but it can request more buffers to compensate that
these will be held in a downstream pipeline. Note that it will never be
ideal as the intervideosink protocol is stateless. Maybe the long term
is to add a property.
Enabling GstVideoMeta support in the allocation query (and handling the
absence on the intervideosrc) seems like a better idea, otherwise you
may endup in a situation where you always copy, and to make things
worst you may not be copying in the right type of memory.
>
> I have also noticed the differences below in the debug outputs that make me
> think the BufferPool used is different.
>
> Pipeline #1
> v4l2bufferpool
> gstv4l2bufferpool.c:509:gst_v4l2_buffer_pool_set_config:<v4l2src0:pool:src>
> config GstBufferPoolConfig, caps=(GstCaps)"video/x-raw\,\
> format\=\(string\)YUY2\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\
> framerate\=\(fraction\)30/1\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\
> colorimetry\=\(string\)bt709\,\ interlace-mode\=\(string\)progressive",
> size=(uint)4147200, min-buffers=(uint)5, max-buffers=(uint)5,
> allocator=(GstAllocator)"\(GstVpuAllocator\)\ vpuallocator0",
> params=(GstAllocationParams)NULL, options=(string)<
> GstBufferPoolOptionVideoMeta >;
>
> Pipeline #2
> v4l2bufferpool
> gstv4l2bufferpool.c:509:gst_v4l2_buffer_pool_set_config:<v4l2src0:pool:src>
> config GstBufferPoolConfig, caps=(GstCaps)"video/x-raw\,\
> format\=\(string\)YUY2\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\
> framerate\=\(fraction\)30/1\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\
> colorimetry\=\(string\)bt709\,\ interlace-mode\=\(string\)progressive",
> size=(uint)4147200, min-buffers=(uint)4, max-buffers=(uint)4,
> allocator=(GstAllocator)"NULL", params=(GstAllocationParams)NULL;
>
> Could this explain the lost frames? If so, is there any way I can specify
> the BufferPool that should be used? Reading the doc on Bufferpool, I cannot
> see how to specify a specific Bufferpool on a pad before negotiation.
>
> Is using intervideosink/src a 'bad idea'? Are there better elements to use
> to share a v4l2src?
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191126/9bc8572f/attachment.sig>
More information about the gstreamer-devel
mailing list