I am looking for a method to upgrade the default gstreamer version that does not break deepstream.
At the moment, you can easily upgrade your gstreamer to 1.20 by building it from source, however you will lose all hardware acceleration, and deepstream will fail if you try to use it. You will then need to re-flash the board to get deepstream working again (thanks for the warning btw).
Does nvidia have a special recipe for building gstreamer from source , if they do can they share it ?
What is the reason for not being compatible with the latest gstreamer ? Is the issue related source code in the proprietary plugins ?
I’d like to know if its an impossible task or not, before i fully dive into the rabbit hole, so if you have any knowledge or experience on the issue, please share it.
That’s a shame, there are some very powerful new plugins in 1.20…
Is there an internal plan to do so ? or are you guys just building against the default ubuntu version that l4t is based on ?
It seems quite silly to not be up-to-date with gstreamer when deepstream completely relies on it to function, and in-terms of media applications (transcoding, live-streaming,recording,relaying) without HW acceleration my AGX Xavier performs worse than a rasberry pi 4b.
So i’m thinking the best way around this, without porting HW acceleration, is to basically rewrite my application, separate all of the deepstream elements from my main pipeline, then put them in a separate microservice, then install gstreamer1.20 locally, instead of system wide, and finally link my application to the gstreamer v1.20 libs ?
Well, originally i was more focused on the new rust webrtc/onvif plugins, i easily recreated the ONVIF parsers in C, but i can only do so much and i cannot backport the webrtc plugins or onvif payloader/depayloader or fix rtspsrc because 1.16 lacks many core features required for modern A/V development.
So many little things have been changed, fixed, and updated since 1.16 that i cannot possibly list them all. In short, i don’t ‘want’ it to be compatible with 1.20/latest, all of us NEED deepstream to be compatible with 1.20/latest.
Many of the questions on this forum are directly related to issues within the outdated gstreamer version, such as IP cameras not connecting to deepstream if they have vnd.onvif.metadata in the stream, or IP cameras periodically cutting out over rtsp, etc.
I’ve been back-porting gstreamer plugins from 1.20 to 1.16 for the last 21 days, and i’m still no where near finished. It would be helpful to have a roadmap from deepstreams core developers, i’ll feel like a complete idiot if i spend the next 3 months porting code, for you guys to just randomly release an upgrade
I’m not sure, i’ve been hesitant to attempt @Fiona.Chen method, as i basically did the same steps when upgrading to 1.20 and it took away support for HW acceleration, so i had to re-flash it then reinstall everything again.
Yeah. From my understanding, gstreamer 1.20 or the newer 1.22 will only give us standard plugins while the plugins provided by Deepstream would not be available (HW accelerated plugins, for example, hw encoders for Jetson). Is there a way to link those plugins myself for a newer version of gstreamer? What would need to be changed for this to happen.
From what @Fiona.Chen said, it seems that it’s not possible in anyway, shape, or form for us to link the HW accelerated plugins to the new versions of gstreamer.
Like i’ve said before, if you try to upgrade to 1.20+ you will lose the ability to perform any hardware acceleration on the device, and you’ll need to do a complete re-flash.
I’m not sure about 1.18.6, i still need to try it.
You can however, build a local copy of 1.20 and link your application directly to those libs. The downside is that you cannot mix and match gstreamer versions, plugins from 1.16 will not work with 1.20.
So all of your 1.20 elements will be running on CPU only, and you will not be able to use rtpav1depay and any of the deepstream/hardware accelerated elements in the same pipeline.
If you desperately need them, then you’ll need to backport the 1.20 av1 plugins to 1.16, which may or may not be possible.
Yes, I can build it, but it requires gst >= 1.20 and nvv4l2av1enc is not available for gst 1.20. Is it possible to build nvv4l2av1enc to support gst 1.20?
I can confirm that there is “currently” no way to make HW encoders run on Jetson Nano using source compiled GST versions of newer kind, like 1.20 or 1.22 (just tested the latter). I also see no way that this will change, even there are scattered promises here and there.
I’m considering the Nano as retired (maybe the whole gang of those devices). The product care of NV is horrible. Having still to rely on 18.04 three years after retirement is rediculous.
But even the many 20.04 images and even an update to CUDA 12 will never allow you to come over this here:
(response to gst-inspect-1.0 nvcodec after a full source compilation of 1.22 with CUDA 12 drivers (?), Video_SDK 12 and Ubuntu 20.04):
0:00:00.982542146 8435 0x559b1e7400 ERROR nvenc gstnvenc.c:963:gst_nvenc_load_library: Could not query max supported api version, ret -781753212
0:00:00.982587980 8435 0x559b1e7400 WARN nvcodec plugin.c:100:plugin_init: Failed to load nvenc library
0:00:01.023590212 8435 0x559b1e7400 INFO cudacontext gstcudacontext.c:246:gst_create_cucontext: GPU #0 supports NVENC: yes (NVIDIA Tegra X1) (Compute SM 5.3)
0:00:01.137356564 8435 0x559b1e7400 INFO cudacontext gstcudacontext.c:269:gst_create_cucontext: Created CUDA context 0x559bc17bd0 with device-id 0