JP5.1 - python gstreamer cant load plugin nvv4l2h265enc

[pw_irl]

Hi,

Our vendor has supplied us with a new JP5.1 image for their custom xavier box.

I think there is a folder missing from the nvidia container runtime mapping? I see a lot of errors with gstreamer complaining about /lib/modules/5.10.104-tegra missing. This error goes away after adding the mapping or updating the /etc/nvidia-container-runtime/l4t.csv. Not sure if this is a spurious error or if important.

Even after fixing the above I still get strange failures when I use gstreamer with python inside container. This all worked fine on JP4.6 - and the only change I made now is to update the base used (tried l4t-base:35.2.1 and deepstream-l4t:6.2-base).

Strangely when I run gst-launch-1.0 videotestsrc ! nvvidconv ! nvv4l2h265enc ! fakesink - this works fine. Also gst-inspect-1.0 nvv4l2h265enc works fine in container - can’t see any blacklisted plugins.

It seems to be able to load most plugins fine, just not nvv4l2h265enc in this case.

0:00:03.821581130 1 0x192a3320 INFO GST_PLUGIN_LOADING gstplugin.c:902:_priv_gst_plugin_load_file_for_registry: plugin “/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvidconv.so” loaded
0:00:03.821651437 1 0x192a3320 INFO GST_ELEMENT_FACTORY gstelementfactory.c:360:gst_element_factory_create: creating element “nvvidconv” named “convertor”
0:00:03.822160870 1 0x192a3320 INFO GST_ELEMENT_PADS gstelement.c:671:gst_element_add_pad:GstBaseTransform@0x19b73570 adding pad ‘sink’
0:00:03.822225257 1 0x192a3320 INFO GST_ELEMENT_PADS gstelement.c:671:gst_element_add_pad:GstBaseTransform@0x19b73570 adding pad ‘src’
2023-03-06 20:35:08 INFO Creating H265 Encoder
0:00:03.854722083 1 0x192a3320 WARN GST_PLUGIN_LOADING gstplugin.c:527:gst_plugin_register_func: plugin “/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so” failed to initialise
0:00:03.854840073 1 0x192a3320 WARN GST_PLUGIN_LOADING gstplugin.c:1330:gst_plugin_load_by_name: load_plugin error: File “/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so” appears to be a GStreamer plugin, but it failed to initialize
0:00:03.854918573 1 0x192a3320 WARN GST_PLUGIN_LOADING gstpluginfeature.c:132:gst_plugin_feature_load: Failed to load plugin containing feature ‘nvv4l2h265enc’.
0:00:03.855143864 1 0x192a3320 WARN GST_ELEMENT_FACTORY gstelementfactory.c:398:gst_element_factory_create: loading plugin containing feature encoder returned NULL!
0:00:03.855255805 1 0x192a3320 INFO GST_ELEMENT_FACTORY gstelementfactory.c:463:gst_element_factory_make: couldn’t create instance!
2023-03-06 20:35:08 ERROR Unable to create encoder

How can I find out why this plugin failed to initialise?

I tried to make a minimal sample with python using gst_parse_launch but that worked fine - just as with gst-launch-1.0. So maybe the problem lies with the python GObject factory?

The code that is failing:
encoder = Gst.ElementFactory.make(“nvv4l2h265enc”, “encoder”)
if not encoder:
logger.error(" Unable to create encoder")
return(-1)

[pw_irl]

I seem to have fixed this - by moving the Gst.Init() and Gst.ElementFactory.make() further up in the file near the top. Not sure why this would make any difference tho!?

I see strange new warnings in gstreamer output now as well:
0:07:47.326174101 1 0x39a4b700 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:encoder:pool:sink Buffer 0xfffef45ef360 without the memory tag has maxsize (192) that is smaller than the configured buffer pool size (3133440). The buffer will be not be reused. This is most likely a bug in this GstBufferPool subclass
0:07:47.357673274 1 0x39a4b700 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:encoder:pool:sink Buffer 0xffff5c04eb40 without the memory tag has maxsize (192) that is smaller than the configured buffer pool size (3133440). The buffer will be not be reused. This is most likely a bug in this GstBufferPool subclass
0:07:47.359274280 1 0x39a4ecc0 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:encoder2:pool:sink Buffer 0xffff5c03e900 without the memory tag has maxsize (192) that is smaller than the configured buffer pool size (3133440). The buffer will be not be reused. This is most likely a bug in this GstBufferPool subclass

[DaneLLL]

Hi,
Probably the python version triggers the issue. Please try python 2.7 and 3.8, to clarify if the failure is specific to either version.

[user138956]

I’m using the python3.8 provided in the l4t-base:35.2.1 container. It does work now after reordering but I don’t understand why.

Can there be a race condition trying to load plugins?

[DaneLLL]

Hi,
We have tried this sample and it works:
Nvv4l2decoder sometimes fails to negotiate with downstream after several pipeline re-launches - #16 by DaneLLL

Please give it a try. Calling Gst.init(None) at the very beginning looks good and valid.

[pw_irl]

I don’t have any problem when I use gst_parse_launch - but this is not useful for a more complex pipeline.

Indeed it may depend on when Gst.init(None) is called. Moving this right up to the top seems to fix everything - but I don’t understand why. This worked fine with older jetpack.

[DaneLLL]

Hi,
Jetpack 4 releases are with gstreamer 1.14.5 and Jetpack 5 releases are with 1.16.3. Maybe this is why the behavior is different.

[pw_irl]

For sure that’s the reason.

With some help from my colleague we were able to narrow down the cause of the issue to a signal line in python. It seems some old code meant to prevent zombies was breaking the plugin loader mechanism - but ONLY for the h265 encoder component.

The offending line:
signal.signal(signal.SIGCHLD, signal.SIG_IGN)

Please mark issue as resolved.