Nvivafilter before nvinfer

• Hardware Platform (Jetson / GPU) Jetson Nx Xavier
• DeepStream Version 6.0
• JetPack Version (valid for Jetson only) 4.6.1
• TensorRT Version 8.0.1.6

Following the steps in this post I was able to successfully use nvivafilter to undo the fisheye distortion (fisheye is not available in nvdewarper in this version of Deepstream) using opencv CUDA. To make it work you need to set bufapi-version=false:

gst-launch-1.0 nvarguscamerasrc sensor-id=3 do-timestamp=TRUE wbmode=4 bufapi-version=false ! \
	'video/x-raw(memory:NVMM),format=(string)NV12,width=(int)960,height=(int)540,framerate=(fraction)30/1' ! \
	nvivafilter cuda-process=true customer-lib-name="lib-gst-custom-opencv_cudaprocess.so" ! \
	'video/x-raw(memory:NVMM),format=(string)RGBA,width=(int)960,height=(int)540' ! \
	nvvidconv ! videoconvert ! fpsdisplaysink -v

If I set bufapi-version=true, which is necessary for the correct functioning of nvstreammux and nvinfer in later elements:

0:00:01.849964973 25633   0x55bc5fcd90 WARN                 basesrc gstbasesrc.c:3055:gst_base_src_loop:<nvarguscamerasrc0> error: Internal data stream error.
0:00:01.850033166 25633   0x55bc5fcd90 WARN                 basesrc gstbasesrc.c:3055:gst_base_src_loop:<nvarguscamerasrc0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0: Internal data stream error.
Additional debug info:
gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0:
streaming stopped, reason error (-5)
Execution ended after 0:00:00.518412317
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
CONSUMER: ERROR OCCURRED
GST_ARGUS: Cleaning up
Setting pipeline to NULL ...
Freeing pipeline ...

I have seen that this is a problem that has already been mentioned and where it has been said that the use of both is not compatible: “Nvivafilter and Nvinfer” and “Nvivafilter and Deepstream pipeline compatibility”

Is there any way to modulate two different pipelines communicating via shmsink/src, udpsink/src or similar so that the first pipeline uses the old buffer api structure and the second uses the new one?

Solution found here