Compiled from real, verified usage — not official documentation

Why this document exists

Cinegy.Srt.Wrapper (NuGet package, published by Cinegy) is a C# wrapper around the native SRT (Secure Reliable Transport) library, distributed under the internal dependency name SrtSharp. As of this writing, its public documentation is minimal: the GitHub repository (Cinegy/Cinegy.SRT) provides two demo console applications (Cinegy.Srt.Send and Cinegy.Srt.Recv) and a short README, but no inline API reference, no XML doc comments surfaced in IntelliSense, and no worked code samples showing the actual class usage.

Everything below was confirmed directly against the real compiled assembly — first through Visual Studio’s Object Browser, then by decompiling the assembly itself (ICSharpCode.Decompiler) to inspect the real source — rather than assumed from the package name or guessed from convention. Version referenced: 1.0.9.43042.

Package details

• NuGet package: Cinegy.Srt.Wrapper
• Underlying native dependency: SrtSharp (installed automatically as a transitive dependency)
• Target framework observed: net6.0 (works fine when referenced from a net8.0 project)
• Namespace: Cinegy.Srt.Wrapper

Core class: SecureReliableTransport

This is the entry point, but its constructor is private. Do not attempt new SecureReliableTransport() — it will not compile (“does not contain a constructor that takes 0 arguments”), since the only public constructor requires a LoggerOptions argument, and that constructor itself is private regardless.

The correct way to obtain a usable instance is the static factory method:

public static ISecureReliableTransport Setup(LoggerOptions options = null)

options can be omitted entirely for default logging behavior:

ISecureReliableTransport srt = SecureReliableTransport.Setup();

Setup() internally calls the native srt_startup() function and configures logging hooks if a LoggerOptions object is supplied. SecureReliableTransport also implements IDisposable — its Dispose() method calls the native srt_cleanup(). In a long-running host process (a background service, a web server), it’s reasonable to keep one instance alive for the process’s lifetime rather than creating and disposing it repeatedly.

Interface: ISecureReliableTransport

The interface returned by Setup(). Exposes three factory methods, each returning its own role-specific interface:

ISecureReliableTransportSender CreateSender(IPEndPoint endpoint);
ISecureReliableTransportReceiver CreateReceiver(IPEndPoint endpoint, int bufferSize);
ISecureReliableTransportBroadcaster CreateBroadcaster(IPEndPoint endpoint, BroadcasterSettings broadcasterSettings);

ISecureReliableTransportSender

void Accept();
void Send(byte[] data);
// Address property also present

Important behavioral note, confirmed by the method’s presence and name: a “Sender” in this library listens on the given IPEndPoint and accepts an incoming connection — it does not connect outward itself. Accept() blocks the calling thread until a remote peer connects, so it must be run on a background thread/task, never on a request-handling thread in a web server — otherwise every incoming HTTP request would hang until an SRT peer connects.

This means the connection direction is: the receiving side connects OUT to the sender’s address — the reverse of what “sender/receiver” naming might suggest if you assume the sender always initiates the network connection.

Typical usage:

var srt = SecureReliableTransport.Setup();
var sender = srt.CreateSender(new IPEndPoint(IPAddress.Any, 9001));

// Accept() BLOCKS until a receiver connects -- run on a background task.
Task.Run(() =>
{
    sender.Accept();
    // connection is now established; Send() is now safe to call
});

// Later, once accepted:
sender.Send(Encoding.UTF8.GetBytes("hello"));

ISecureReliableTransportReceiver

ISecureReliableTransportChunk GetChunk();
object GetStats(); // exact return type not yet confirmed

Not yet fully explored (this project’s receiver work happens on the Android side via srtdroid, not this C# receiver interface) — documented here for completeness since it’s part of the same discovered API surface.

ISecureReliableTransportChunk

The data structure returned by GetChunk():

byte[] Data;
int DataLen;
IPEndPoint Endpoint;
object MessageControl; // exact type not yet confirmed

ISecureReliableTransportBroadcaster and BroadcasterSettings

Present in the API surface (CreateBroadcaster), not yet explored in this project. Documented here as a known gap for future reference.

Known gaps / not yet confirmed

• Exact behavior/timeout semantics of GetChunk() (does it block indefinitely, return null on no data, or throw?)
• Exact shape of GetStats()‘s return value
• ISecureReliableTransportBroadcaster‘s full member list
• Runtime behavior has only been confirmed to the extent of a successful build; a full send/receive round-trip test (engine to a real box) is the next validation step, not yet completed as of this document.

How this was discovered (methodology note)

For future reference, if this library (or a similarly under-documented one) needs investigating again:

1. Web search alone did not surface real usage examples — only package listing pages.
2. The GitHub repository’s README (fetched directly) confirmed the package was real and gave high-level context, but no method-level detail.
3. Visual Studio’s Object Browser (View → Object Browser, search the package name) revealed the actual class and interface names, and their method signatures — a live, first-hand view of the compiled API surface, independent of any external documentation.
4. Where a compile error suggested the assumed usage was wrong (e.g. the “no 0-argument constructor” error), Go to Definition (F12) on the class name opened a decompiled view of the actual source, which resolved the remaining ambiguity definitively.

This progression — Object Browser for the shape, decompilation for the behavioral detail — is a reliable way to work with any .NET library that ships without adequate public documentation.