[FEATURE REQUEST] no std support

[Lohann]

Would be very helpful for me if this library support no_std environments, this would make this crate usable in embedded hardware such as the surveillance cameras, this also improves the performance, once doing heap allocation for encode/decode every message is quite expensive.

If the maintainer think this could be an good idea, I can help on remove the std dependency for this project, at first glance the only dependency which requires STD is the url library, that can be replaced by fluent-uri.

Another plus would be make alloc optional too and only expose MessageRef and other ref only structs when alloc is disabled.

[sdroege]

this would make this crate usable in embedded hardware such as the surveillance cameras

Are there actually any cameras out there that do not run a full (usually Linux) OS? Running a full RTSP server without any full OS or support for heap allocations sounds unfeasible and I'm not aware of any such cameras.

this also improves the performance, once doing heap allocation for encode/decode every message is quite expensive.

That would indeed be useful to solve but requires careful redesign of the API and implementation. It's not "easy".

at first glance the only dependency which requires STD

Also tinyvec as external dependency, and there's usage of String, BTreeMap and other types.

that can be replaced by fluent-uri.

Did you check if that handles RTSP URIs correctly? Also for url I had to add https://github.com/servo/rust-url/pull/668 for making it actually useable for RTSP client/server implementations.

Just because both crates say "URL", this needs careful consideration.

---

If the maintainer think this could be an good idea

I think that's a good idea but you should probably look at the different aspects of the whole effort separately. Getting rid of all heap allocations for example is going to be quite a bit of effort, but would be useful independent of nostd support too.

[Lohann]

Are there actually any cameras out there that do not run a full (usually Linux) OS?

In my example specifically, I'm experimenting on using an ESP32 to connect to an IP camera, and forward the packets to a server to make the stream public available without having to open ports in my router, still WIP. Basically I want to convert any RTSP camera to push the stream to a server, instead having the server to connect to the camera, which leads to a lot of issues when the IP is not static, firewall blocking, etc...

That would indeed be useful to solve but requires careful redesign of the API and implementation. It's not "easy".

I manage to get this project working without std and without alloc by simply using the message_ref.rs without any big changes in the code, I simply had to make the attributes public, and replace the tinyvec::TinyVec by tinyvec::ArrayVec, I think 16 headers is a good limit, I don't know about any message which requires more than 16 headers, but if supporting more headers is necessary, it can be done by doing something like this:

pub struct RequestRef<'a, const HEADERS_LIMIT: usize> {
    pub method: MethodRef<'a>,
    pub request_uri: Option<&'a str>,
    pub version: Version,
    pub headers: ArrayVec<[HeaderRef<'a>; HEADERS_LIMIT]>,
    pub body: &'a [u8],
}

or this:

#[cfg(feature = "std")]
type HeadersVec<'a> = tinyvec:TinyVec<[HeaderRef<'a>; 16]>;

#[cfg(not(feature = "std"))]
type HeadersVec<'a> = tinyvec:ArrayVec<[HeaderRef<'a>; 16]>;

pub struct RequestRef<'a> {
    // ..
    pub headers: HeadersVec<'a>,
}

Did you check if that handles RTSP URIs correctly?

Yes I use this library when I need to validate/parse URLs for no_std targets, like wasm32-unknown-unknown, it is faster than url crate and fully RFC 3986 compliant.

[Lohann]

As example, the FFMPEG library decode/encode rtsp messages without heap allocations, each message is constrained to 4096 bytes maximum, the issue is that it mixes the code that parsers the RTSP message, manage the tcp connection and RTSP state: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtsp.c#L1183-L1328

The code is very efficient, but a mess..

[scottlamb]

Getting rid of all heap allocations for example is going to be quite a bit of effort, but would be useful independent of nostd support too.

In retina, I've played with a ring buffer-based approach for the RTSP TCP connections, and a pool for the UDP packets. (https://github.com/scottlamb/retina/issues/6) The goal is just to minimize allocations in the steady state rather than to completely eliminate them in the whole program. It's still a significant redesign and some extra complexity, so I'm not sure if I'll ever finish it or not.