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

    v0.10.0 Stable

    builduser released this 2026-09-08 02:00:07 +02:00 | 0 commits to main since this release

    The virtual camera path was finally run rather than reasoned about, which
    found two faults. The configuration is also considerably smaller: 950 lines of
    it removed, most being questions with only one sensible answer.

    Existing configuration is not migrated. Camera and audio assignments are
    recorded differently now, so switch each source's Camera and Audio back on
    once after upgrading.

    Two faults, found by testing against a real device

    A source carrying no audio got no camera at all. ffmpeg refuses an output
    that ends up with no stream in it, and that refusal took the whole process
    down, video included, restarting every second. Making the audio mapping
    optional does not help, since the output is still empty. Audio is now added
    only when the source is actually sending some, asked afresh for each process.

    -check was broken and would have failed on a working setup. A generated
    test pattern written without -re goes as fast as the machine can manage, so
    the writer finished in a fraction of a second and had let go long before the
    read. The device then reverts to output only and reports "not a video capture
    device", which reads as broken hardware rather than a test racing itself.

    The hub's log now also goes to standard error. It only ever reached the
    interface, which is why the first fault was invisible to anyone running the
    program from a terminal to find out why it was failing.

    What did check out, against v4l2-ctl: the capability and format reads agree
    exactly, and a device does flip from output to capture as soon as a writer
    attaches. There are now end to end tests that publish over RTMP, carry it
    through the agent and the sink, and read a frame back off the loopback at the
    source's own resolution.

    Simpler

    Virtual devices are no longer picked from menus. A camera is taken from
    whichever loopback nodes are free, an audio device is created for the source
    and named after it, and each source has two switches. Which device carries
    which source is not a decision worth putting to anyone, and every question
    asked is another way to end up pointing at the wrong thing. What was chosen is
    remembered, so a scene built against a device keeps working.

    Removed as redundant:

    Gone Because
    manual delay, safety margin the delay tracks the slowest source; a typed number cannot improve on it
    fast first frame joining at a keyframe is simply correct; the alternative leaves sources permanently offset
    pinned size the picture size is read from the stream
    timestamp rebase it discards the alignment this program exists to produce
    preview size taken from what the source actually sends
    program view grid one window per source mirrors how cameras work

    A source is now a device on Linux and a window on Windows, one for one, so the
    same rig is set up the same way on either platform.

    What remains is what cannot be worked out: which ports to listen on, the
    shared secret, where the outputs go, the per-source offset, and where to look
    for updates.

    Downloads

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