RTMP usually enters a conversation next to a camera, an encoder and a streaming server. That makes it easy to think of it as something that turns images into video. It doesn't. Encoding and transport are separate jobs, and RTMP also has a useful history of carrying application commands and structured data.
The rtmp-sharp revision I saved focuses on that less visible side of the protocol: a .NET client for remote calls and serialized objects. Its README describes a data-oriented library, not a camera capture system or a video encoder. That distinction matters when deciding where a dependency belongs in an application.
Suppose a client wants to ask a server for the state of a shared session. At the application level, this is a method name and some arguments. Those values need a representation that the other side can decode. AMF, the Action Message Format used in this ecosystem, provides a way to serialize values and objects. RTMP carries the resulting messages over the connection. A response then travels back and must be associated with the request that caused it.
These are several different failure boundaries. A connection can be healthy while a method name is wrong. A message can arrive intact while an object cannot be mapped to the expected type. A call can execute successfully on the server while its response is lost before the client receives it. Reporting all three as a generic streaming error would make debugging unnecessarily difficult.
The last case is particularly awkward. A timeout doesn't prove that nothing happened. If the call changes state, blindly retrying may perform the operation twice. An application needs a policy: make the operation idempotent, attach a request identifier that the server can recognize, or ask for the resulting state before deciding what to do next. A transport library can't invent that policy from the method name.
Video has its own separate path. An encoder produces compressed media. The transport packages and sends it. The receiver needs an appropriate decoder and a presentation clock. Adding a library capable of remote calls does not supply those other pieces, even when the same protocol family can carry media messages.
I like repositories that make this boundary visible. They encourage a diagram with explicit responsibilities: application values, serialization, protocol messages and connection management. That is more useful than a box labeled streaming with everything hidden inside.
For a Unity or .NET project, the practical question is therefore quite narrow: do I need this library's data communication behavior? If the missing piece is capturing a texture or compressing a frame, I need to look elsewhere. Naming the missing layer is often the fastest way to stop adding the wrong code.