NV bug on gst_buffer_copy

Take nvvidconv plugin as example.
Since no mem_copy is implemented in GstNvFilterMemoryAllocator, if a NV buffer is copied by gst_buffer_make_writable or gst_buffer_copy, then the default _fallback_mem_copy would be called.
The associated GstMemory of destination buffer would be allocated and initialized by default system memory allocator.
This would cause problems in some plugin like nvcompositor which will check memory type through ‘inmem->allocator->mem_type’.

Let me give some pipeline example.
// This pipeline works fine
gst-launch-1.0 videotestsrc is-live=1 ! nvvidconv ! ‘video/x-raw(memory:NVMM),width=640,height=480,format=RGBA,framerate=30/1’ ! comp.sink_0 nvcompositor name=comp sink_0::width=1920 sink_0::height=1080 sink_0::xpos=0 sink_0::ypos=0 ! ‘video/x-raw(memory:NVMM),format=RGBA’ ! nvvidconv ! nv3dsink

// But if we add interpipesink and interpipesrc in between, we will see black screen with some noise points.
gst-launch-1.0 videotestsrc is-live=1 ! nvvidconv ! ‘video/x-raw(memory:NVMM),width=640,height=480,format=RGBA,framerate=30/1’ ! interpipesink name=t forward-events=1 async=false sync=false interpipesrc is-live=1 format=time stream-sync=0 listen-to=t ! comp.sink_0 nvcompositor name=comp sink_0::width=1920 sink_0::height=1080 sink_0::xpos=0 sink_0::ypos=0 ! ‘video/x-raw(memory:NVMM),format=RGBA’ ! nvvidconv ! nv3dsink

Please advise how to fix such issue in NV plugins. Thanks.
(Implement a new mem_copy in nvvidconv ?)

You can download source code of nvvidconv plugin and debug further. Please download this package:
Jetson Linux R32.7.1 Release Page | NVIDIA Developer

L4T Driver Package (BSP) Sources

Hi DaneLLL,

I already did that.
Not only nvvidconv but all NV plugins which has customized allocator have this issue.
That’s why I think this is a NV bug.

I am not sure if Nvidia implemented this way on puropose.
Could you please forward and check with internal development team?
Why mem_copy is not implemented?

In our test cases and use-case, we don’t call GstMemoryCopyFunction, so it is not implemented. Your use-case looks advancing and if the callback is required, you may implement it on your own. We have the source code public so that doing customization for further use-cases is possible and flexible.

But not all NV plugins are open source.
Take nvvideoconvert as example, can Nvidia provide source code?
If not, will Nvidia provide patch on this issue?

nvvideoconvert plugin is used in DeepStream SDK. It is not open source. Most plugins are open source but there is concern for a few plugins. So some plugins are private.

Could you check with RidgeRun for further help? Since they develop interpipesink and interpipesrc. They should be familiar with the plugins.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.