vaaapidecode, shmsink, and allocator

[kmliu]

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.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/