This is on the latest jetpack 5.0.2
We have a custom gstreamer based application where to keep it simple we implement 4 App sources which we feed into an nvcompositor, the app sources and nvcompositor are seperate pipelines linked through gst-interpipe.
However about 9 out of 10 times it crashes, so I compiled my own gst-nvcompositor, (which by the way did not work out of box, a pkgconfig pkg in the makefile was not found and the libs was still set to nvbuf_utils and not nvbufsurface/nvbufsurftransform, which doesn’t make me very confident about how under control sources for these things are per release)
And I found that it crashes in get_nvcolorformat which is called from gst_nvcompositor_fixate_caps in the sinkpads loop.
The GstNvCompositorPad which is cast from the GstVideoAggregatorPad from the data of the sinkpad seems to be invalid and causes a crash in GST_VIDEO_INFO_FORMAT.
Would anyone have any idea why it ever iterates over all these elements and end up with an invalid pointer so often and maybe someone at nvidia who can clarify the sources status of the gst nodes as the provided sources don’t seem to match what is compiled into a jetpack release?
I can at least prevent the crash by adding a check in get_nvcolorformat if info->finfo is a null pointer or not, but a root cause here or a better way to fix this would be appreciated.
Just to add, if I add the nullptr check for finfo, and manually return the RGBA format type nothing else blocks or crashes and I can correctly process the composition