Open blokfyuh opened 2 years ago
Would it be feasible at all ?
With a lot of effort, probably. The combiner uses various aggregator APIs that are only available since 1.18 and not using these APIs complicates things considerably.
It would be possible to build a copy of newer aggregator/etc as part of the plugin when targetting older GStreamer versions if someone wants to bother setting up things accordingly. The fallbackswitch plugin is doing something like that. It's not beautiful but might also be sufficient here.
I'm stuck because I'm using Nvidia Jetson Nano, and it's strongly discouraged to upgrade Gstreamer version. Their support says that a lot of stability issues could appear as all Nvidia's proprietary softwares are only tested against Gstreamer 1.14.5.
The joys of proprietary platforms :)
Hi @sdroege,
Thanks for the quick reply.
It would be possible to build a copy of newer aggregator/etc as part of the plugin when targetting older GStreamer versions if someone wants to bother setting up things accordingly. The fallbackswitch plugin is doing something like that. It's not beautiful but might also be sufficient here.
Would you mind guiding me on this part ?
From what I understood: You have a base folder in the fallbackswitch plugin, where you copied a Gstreamer 1.18.0 gstaggregator version. Then you define a specific build process in the build.rs file, where you point to the newer aggregator implem. After that, you define your Rust wrapper classes using this newer aggreg version... And voilà... ? Am I completely lost ?
Let's say, I copy your fallbackswitch's base folder and the build.rs file, then I replace every "Fallback" occurrences by "NDI" (for namespace purposes), and I paste them into the ndi plugin folder. Should it work as a drop-in ? Or will it be way more complicated ?
Sorry for the naive questions, but I'm not fluent in Rust, so I try to figure it out on the fly.
Thanks.
Yes that's basically all. The tricky part is to make sure that it only uses that copy if older GStreamer versions are targetted and otherwise use the one from GStreamer directly.
Give it a try :)
Thanks @sdroege. I'll give it a try.
Would you be interested in a PR about that ? To make ndisink more accessible ? Or it's not something you want upstream anyway ?
Something for @samuvlad to answer, I guess. I don't mind either way as long as someone else makes sure to keep it up to date.
Hello.
At the moment this plugin is not a priority for the company, so I can't dedicate too much time to it.
Personally I'm very interested in this project, but I don't have much experience in Gstreamer and I'm starting with Rust.
I'm very sorry, but I can't commit to actively maintain this project.
In the next weeks/months I will try to improve my Gstreamer, Rust and NDI skills to be able to maintain and improve the project.
Hey @sdroege do you mind taking a look at #78? It adds a sink-v1_14
feature that backports the aggregator locally, as the fallback switch does.
Hello guys,
Would it possible to make ndisink (and its companion ndisinkcombiner) compatible with gst 1.14.5 ?
I tried to tweak Cargo.toml to remove the version assertions in the [features] block, but it complains about some missing AggregatorPad and Aggregator... I don't know if there are others incompatibilities. Would it be feasible at all ?
I'm stuck because I'm using Nvidia Jetson Nano, and it's strongly discouraged to upgrade Gstreamer version. Their support says that a lot of stability issues could appear as all Nvidia's proprietary softwares are only tested against Gstreamer 1.14.5.
What do you think ?