No. We do not support to port the HW accelerated plugins to GStreamer1.20.x now.
@Fiona.Chen Thank you for the quick response.
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 ?
Can you tell us which new feature in GStreamer 1.20.x you want? Can you port the new feature back to Gstreamer 1.16?
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
In order to migrate to newer gstreamer version (e.g. gstreamer-1.18.6) follow below steps:
- Prerequistes: Install below pacakges
apt install meson
apt-get install libmount-dev
apt-get install flex
apt-get install flex bison
apt-get install libglib2.0-dev
- Compilation and installation steps
#Remove older version
apt-get remove *gstreamer*
#e.g. mkdir /tmp/gst-1.18.6
#e.g. cd /tmp/gst-1.18.6
#Clone the repository
git clone https://gitlab.freedesktop.org/gstreamer/gst-build.git
#Switch to gst-version
git checkout <gst-version-branch>
#e.g. git checkout 1.18.6
meson build --prefix=/usr
ninja -C build/
rm -rf <directory created in step 2>
#e.g. rm -rf /tmp/gst-1.18.6
3. Check and confirm the newly installed gstreamer version
hi, thanks for the upgrade steps. I want to know if it’s possible to support the HW accelerated plugins in gstreamer 1.18.6?
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.
My goal is to use rtpav1pay and rtpav1depay to try av1 streaming with Jetson Orin device. It seems those plugins requires gst 1.2 to compile (net/rtp/Cargo.toml · main · GStreamer / gst-plugins-rs · GitLab)
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.
Thanks your reply! This is what I thought too but I just wanted to find some possible ways.
I have a simmilar problem. I bought Jetson Orin to use AV1 endcoding with Webrtc, but without rtpav1pay it is not possible.
@doubleecao Have you found any solution to your problem? Have you tried porting rtpav1pay to 1.16?
@Fiona.Chen Do you have any plans to provide AV1 support for webrtc in gstreamer (arpav1pay)?
I don’t think Ubuntu has any plan to distribute gst-plugins-rs, you can build by yourself.
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?
We never tested it with GStreamer 1.20, you can try it with GStreamer 1.20 after you upgrade the GStreamer.
But is it possible to build nvvideo4linux2 from sources? I can find sources for nvarguscamerasrc, but I cannot find for nvvideo4linux2.
I think the code is in Working With Sources — Jetson Linux Developer Guide documentation (nvidia.com) if you are working with Jetson platform.
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:
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
End of life, so to say. The sad it is.
Do you get a result of attempting
gst-inspect-1.0 nvv4l2decoder ?
Yes. Not found or something like this
I wasn’t able to update the default gstreamer either but so far I’ve had luck with building 1.22 and running it from another location so that it doesn’t replace any of the default gstreamer libraries.