upnp-client-rs VS desktop-streaming

The UPnP Client library for Rust provides a convenient and easy-to-use solution for discovering and communicating with UPnP devices on a network. With its powerful features, developers can quickly build UPnP-enabled applications in Rust. If you're interested in contributing to the upnp-client-rs project, you're more than welcome to do so! This Rust crate is open-source and hosted on GitHub at https://github.com/tsirysndr/upnp-client-rs, so feel free to check it out and make any contributions you feel would be useful. Whether you have bug fixes, improvements, or new features, all contributions are appreciated. Before submitting a pull request, please make sure to review the contribution guidelines in the repository's CONTRIBUTING.md file.

UPnP client library for Rust https://github.com/tsirysndr/upnp-client-rs

I'm using webrtc-rs for my personal project and their RTP stack is chock full of allocations/deallocations. I, on the other hand, prefer to use preallocated buffers so I find myself having to reimplement a lot of RTP functionalities.

Finished the native Android client of my desktop streamer and latency still sucks. I looked over at Moonlight's code and they have lots of vendor-specific hacks for lowering latency. But I can't just copy that because: 1) it's GPL, 2) I'm doing the decoder initialization purely in Rust so I don't have convenient access to the Java methods.

I found it easier to integrate NvEnc to webrtc-rs. libwebrtc is too tightly integrated and would need a massive C++ shim. Would like to see how your implementation would look.

Made a desktop streamer using Window's IDXGIOutputDuplication API and the webrtc crate.