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

    v0.7.0 Stable

    builduser released this 2026-09-07 04:29:04 +02:00 | 13 commits to main since this release

    Adds a desktop client for the machines running OBS, and update checking for
    the sink. Also fixes the virtual camera audio gap and the device contention
    that made the first camera device fail.

    A client with a window

    streamsink-client does the same work as streamsink-agent and is for the
    other kind of machine: an operator's, rather than a rack. It shows whether the
    sink is reachable, whether OBS is publishing, and above all whether capture
    times are coming from OBS's timeline or merely from packet arrival, which is
    the difference between a machine that stays in step and one that drifts. It
    also shows the address to paste into OBS, with a button to copy it.

    The headless agent is unchanged and remains the right choice for a service.

    Updates

    The sink checks for newer releases and says so in Settings. Installing is
    always a decision: replacing the program someone is relying on partway through
    an event is not something to do unasked.

    Downloads are verified against the SHA256SUMS published with each release
    from this version on, and the new binaries are made to run and identify
    themselves before anything is replaced. A release without checksums cannot be
    installed automatically, and a download that does not match is discarded. The
    previous binaries stay alongside with a .old suffix until the new version has
    started. A private repository needs a token, set under Settings.

    Audio for virtual cameras

    A v4l2 loopback carries video and nothing else, so a rig on virtual cameras had
    no sound. Each source can now also play into a virtual audio device, whose
    monitor OBS takes as an ordinary Audio Input Capture. Both outputs are driven
    by one ffmpeg process, so sound stays locked to picture.

    Audio devices need no privileges and the interface creates them directly.
    Camera devices need a kernel module, so that button asks through polkit and
    prints the command to run by hand if there is no agent to ask.

    Why the first camera device did not work

    Virtual video nodes were listed by their place in sysfs and offered regardless
    of what they were. A machine can have virtual video nodes that are not
    loopbacks, and OBS takes hold of video devices when it starts, so a device it
    grabbed before StreamSink was running could never be written to.

    Devices are now interrogated with VIDIOC_QUERYCAP, so only real v4l2loopback
    nodes that accept output are offered, and StreamSink names the process holding
    a device rather than reporting "busy". Setup also places devices at
    video_nr=10,11, clear of the numbers OBS reaches for, which removes the
    start-order dependency entirely.

    Check the whole path with:

    ./streamsink -check

    Downloads

    File For
    streamsink-0.7.0-linux-amd64.tar.gz Linux server, client and agent
    streamsink-0.7.0-windows-agent-amd64.zip Windows agent, headless
    streamsink-0.7.0-windows-server-amd64.zip Windows server and client, with the GTK4 runtime
    streamsink-0.7.0-windows-decoder-amd64.zip Windows decoder, for the program view
    SHA256SUMS checksums, used by the updater

    Still unverified

    Virtual camera output has not been exercised end to end here, because
    v4l2loopback is not installed on the build machine; -check tests it on a
    machine that has it. The virtual audio path is tested end to end against a
    real sound server. The Windows binaries have not been executed.

    Downloads