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.