vaaapidecode, shmsink, and allocator

[Nicolas Dufresne]

Le jeudi 12 décembre 2019 à 11:37 +0100, Víctor Jáquez a écrit :
> On Wed, 11 Dec 2019 at 20:30, kmliu wrote:
> > I'm running the following pipeline that decodes H.264 video from a file and
> > then sends the raw video to a shmsink. I have another pipeline that picks up
> > the raw video from a corresponding shmsrc.
> > 
> > gst-launch-1.0 --gst-debug=vaapidecode:6,shmsink:6 filesrc
> > location=bbb_sunflower_1080p_30fps_normal.mp4 ! qtdemux ! vaapih264dec !
> > shmsink wait-for-connection=false socket-path=/tmp/tmpsock sync=true
> > 
> > It works but I see more memory reads and writes than I expected. BTW, I run
> > 16 instances of this pipeline to get GBs per second of reads and writes. So
> > I started looking into the ALLOCATION query between vaapih264dec and
> > shmsink. The shmsink seems to propose a custom allocator that allocates from
> > its shared memory buffer. But in gst_vaapi_plugin_base_decide_allocation(),
> > it simply keeps a reference to shmsink's allocator in other_srcpad_allocator
> > and proceeds to use its own allocator instead. I think because of this,
> > shmsink needs to do a memcpy as indicated by the following debug message.
> > BTW, this message is kind of misleading. I think it means the memory in the
> > buffer was not allocated by shmsink's own allocator and it's allocated by
> > vaapivideoallocator0 instead.
> > 
> > shmsink gstshmsink.c:714:gst_shm_sink_render:<shmsink0> Memory in buffer
> > 0x7f2aa8052480 was not allocated by <vaapivideoallocator0>, will memcpy
> > 
> > I don't understand vaapidecode enough to tell why it doesn't just agree to
> > use shmsink's allocator. The only place other_srcpad_allocator is used is in
> > gst_vaapidecode_push_decoded_frame(). It doesn't look like that particular
> > codepath is taken though.
> 
> I haven't tested shmsink, but vaapi needs to use its own source pad allocator,
> because it produces VASurfaces. Those surface have to be "downloaded" to another
> memory area, and that's a memcpy for many use cases.

shmsrc/sink is not zero-copy. It creates one segment of shared memory
and everything not writing to that segment directly (that is the case
for VAAPI, it simply can't), will have to be copied into it.

If I had a project with this multi-process requirement, I would use
pipewire daemon. You can get VAAPI to export dmabuf, and pipewire is
able to stream dmabuf and memfd across processes without copying.

> 
> vmjl
> 
> > 
> > 
> > --
> > 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
> > 
> _______________________________________________
> 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/20191212/ef828ed4/attachment.sig>