revisit nvcompositor source build/usage

[goetzdd]

Its a bit of a stretch, but I'm trying to get nvcompositor building within the confines of the current branch we're using (hardknott/R32.5.2) and while it builds, it then SEGSEVG faults while running a pipeline:

root@ESP-E4DE:~# gst-launch-1.0 \
nvcompositor name=comp background-w=1920 background-h=1080 \
    sink_0::xpos=0 sink_0::ypos=0 sink_0::width=1920 sink_0::height=1080 \
! nvvidconv \
! nvoverlaysink \
videotestsrc is-live=true \
! nvvidconv ! 'video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1,format=RGBA' \
! queue \
! comp.sink_0 -e
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Caught SIGSEGV
#0  0x0000007f7a510b1c in poll () from /lib/libc.so.6
#1  0x0000007f7a6ad56c in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x0000007f7a6ad9a8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0x000000558241326c in ?? ()
#4  0x0000007f7a46e94c in __libc_start_main () from /lib/libc.so.6
#5  0x00000055824133b8 in _start ()
Spinning.  Please run 'gdb gst-launch-1.0 5157' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

I've tried to mirror the changes applied for the dunfell-R32.6.1 branch in meta-tegra\receipes-mulitmedia\gstreamer to add a 1.18.6-r32.5.2 version (some changes in nvcompositor code between 32.5.2 and 32.6.1 required recreating the patch, devtool modify, apply by hand, create new patch, etc)

I tried the same to apply the patches for nvvidconv and also ended up with the SEGSEVG when running a simple pipeline using only vidtestsrc

root@ESP-E4DE:~# gst-launch-1.0 \
videotestsrc is-live=true \
! nvvidconv ! 'video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1,format=RGBA' \
! nvoverlaysink -e

but backed those changes out to concentrate on nvcompositor

I found a post on nvidia forums for the same error, and the nvidia post said it was for internal use only, while there are other later posts that show it being used and nvidia helping to solve issues with its use.

gstreamer version is 1.18.6, hardknott has 1.18 receipes in meta/receipes-multimedia/gstreamer used by setting GST_VERSION ?= "1.18%" in machine conf

though from

gst-inspect-1.0 nvcompositor

the plugin details show 1.8.3 - the most ancient version...

Plugin Details: Name nvcompositor Description Video Compositor Filename /usr/lib/gstreamer-1.0/libgstnvcompositor.so Version 1.8.3 License Proprietary Source module gstreamer-nvcompositor-plugin Binary package GStreamer NvCompositor Plugin Origin URL http://nvidia.com/

I did see somewhere that there was an addition in master to the 1.20 bb to ignore the 3rdpartyheaders.tbz2 but this doesn't seem to do anything.

the simplest example

gst-launch-1.0 \
nvcompositor name=comp \
    sink_0::xpos=0 sink_0::ypos=0 sink_0::width=1920 sink_0::height=1080 \
! nvoverlaysink \
videotestsrc ! comp. -e
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
nvbuf_utils: Invalid width=0 height=0 layout=0
NvBufferCreateEx with memtag 3841 failed
nvbuf_utils: dmabuf_fd 0 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD... Exiting...
NvBufferGetParams failed for src_dmabuf_fds[0] 
nvbuffer_composite Failed

(gst-launch-1.0:5408): GStreamer-CRITICAL **: 10:27:36.054: gst_mini_object_unlock: assertion '(state & access_mode) == access_mode' failed

(gst-launch-1.0:5408): GStreamer-WARNING **: 10:27:36.054: free_priv_data: object finalizing but still has parent (object:0x7f89dce010, parent:0x55974ac5a0)
Caught SIGSEGV
#0  0x0000007f90812b1c in poll () from /lib/libc.so.6
#1  0x0000007f909af56c in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x0000007f909af9a8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0x000000558ab3f26c in ?? ()
#4  0x0000007f9077094c in __libc_start_main () from /lib/libc.so.6
#5  0x000000558ab3f3b8 in _start ()
Spinning.  Please run 'gdb gst-launch-1.0 5408' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
0:00:00.0 / 99:99:99.

probably seems obvious it is some difference brought on by 32.5.x vs 32.6.x...

[madisongh]

Can you test using a sink other than nvoverlaysink? The NVIDIA OpenMAX plugins have known issues with gstreamer 1.16 and later - see #907 and #1368.

Also, the patches you picked from the dunfell-32.6.1 branch were for gstreamer 1.16. You might be better off starting off with the patches in 4353e1ec and 32644c8d, which were for gstreamer 1.18.