ZigzUtils/StreamSink
3
0
Fork 0
Code Issues Pull requests Projects Releases 14 Packages Wiki Activity Actions
14 releases 14 tags
  • v0.5.0 8d8eec48dc

    v0.5.0 Stable

    builduser released this 2026-09-06 07:00:49 +02:00 | 16 commits to main since this release

    Receives live streams from several machines running OBS, holds them until they
    line up, and passes them on synchronised.

    RTMP timestamps restart at zero on every connection and carry no shared
    reference, so a sink receiving several feeds cannot tell which frames were
    captured at the same instant. A small agent runs beside each OBS: it keeps
    an NTP-style clock offset against the sink, and reads capture times from OBS's
    own timeline over obs-websocket rather than guessing from when packets arrive.
    Nothing is transcoded on the relay path; encoded media is passed through byte
    for byte.

    Getting the output into OBS

    Delivery is usually where multi-camera rigs come apart: a player pulling a
    stream applies its own buffering, two players buffer differently, and feeds
    that left in step arrive out of step. Three options, best first:

    • Virtual camera (Linux) — each source becomes an ordinary Video Capture
      Device at its own resolution, with nothing buffering it on the way in.
      Needs v4l2loopback, the same module OBS uses for its own virtual camera.
    • Program view — sources decoded and drawn into a window for OBS to
      capture. Tiled into one window, or one window each. Works on both platforms.
    • RTMP push or pull — for a downstream that is not OBS. Subject to
      whatever buffering that downstream applies.

    Downloads

    File For
    streamsink-0.5.0-linux-amd64.tar.gz Linux server and agent
    streamsink-0.5.0-windows-agent-amd64.zip Windows agent, for each OBS machine
    streamsink-0.5.0-windows-server-amd64.zip Windows server, with the GTK4 runtime
    streamsink-0.5.0-windows-decoder-amd64.zip Windows decoder, only for the program view

    Run streamsink.exe from inside its extracted folder; GTK loads its runtime
    from alongside it. For the program view, extract the decoder archive into that
    same folder. The Linux server needs GTK4 installed; the agent is static and
    needs nothing.

    Known limitations

    • Virtual cameras are Linux only. On Windows a camera is a signed driver
      registered with administrator rights, which an application cannot supply.
    • Virtual camera output is untested end to end. v4l2loopback was not
      available on the build machine. Device discovery, permission and
      configuration checks are tested; ffmpeg writing frames into a loopback node
      is not.
    • The Windows binaries have not been executed. They are verified by
      construction and by import analysis over every bundled binary, not by
      launching them.
    • Sync reaches back as far as OBS, and no further. A capture card holding
      frames or a camera's own processing delay is invisible to StreamSink; the
      per-source offset exists for that residual.
    • Relay, not transcode. Every source must already be in a format the
      downstream accepts.
    Downloads