mikael-lovqvists-claude-agent/video-setup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: move resolved open questions to Decided section

Browse Source 
Drop policy (per-output configurable), stream ID passthrough at relay,
TCP-only transport for now, soft byte budget limits with hysteresis,
and relay scheduler (strict priority first, pluggable interface) were
all already decided — move them out of Open Questions.

Only genuinely open question remaining: graph representation format.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mikael-lovqvists-claude-agent
2026-03-28 23:10:56 +00:00
parent 6fe45ee097
commit e0934afadb
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
architecture.md
View File

@@ -802,14 +802,14 @@ These were previously open questions and are now resolved:
- **Stream ID assignment**: stream IDs are assigned by the controller, not generated locally by nodes. This ensures both ends of a stream report the same ID and the graph can be reconstructed by correlating node state reports. - **Stream ID assignment**: stream IDs are assigned by the controller, not generated locally by nodes. This ensures both ends of a stream report the same ID and the graph can be reconstructed by correlating node state reports.
- **Single port per node**: one TCP listening port handles all traffic — video frames, control messages, state queries — in both directions. Dedicated per-stream ports on separate sockets are a future option but not the default. - **Single port per node**: one TCP listening port handles all traffic — video frames, control messages, state queries — in both directions. Dedicated per-stream ports on separate sockets are a future option but not the default.
- **First delivery mode**: low-latency (no-buffer) mode is implemented first. No frame queue anywhere in the pipeline — V4L2 dequeue goes directly to transport send; received frames render immediately and are dropped if the display is behind. - **First delivery mode**: low-latency (no-buffer) mode is implemented first. No frame queue anywhere in the pipeline — V4L2 dequeue goes directly to transport send; received frames render immediately and are dropped if the display is behind.
- **Drop policy**: per-output configurable. Both drop-oldest (recency) and drop-newest (continuity) are supported; the policy is set at stream open time.
- **Stream ID remapping at relay**: no remapping — stream IDs pass through unchanged. The relay forwards frames with the same stream ID they arrived with. Site-to-site gateways may need to translate IDs at the boundary but that is a future concern handled at the gateway, not in the relay itself.
- **Transport for relay edges**: TCP only for now. UDP and shared memory (for local hops) are future considerations; the transport abstraction should accommodate them without the relay needing to care which is in use.
- **Byte budgets**: soft limits with hysteresis — two thresholds (start dropping, stop dropping) to avoid thrashing at the boundary.
- **Relay scheduler**: strict priority first. Additional policies (round-robin, weighted round-robin, deficit round-robin, source suppression) are documented in the Relay Design section and will be added later. The scheduler interface is pluggable so policies are interchangeable without touching routing logic.
--- ---
## Open Questions ## Open Questions
- What is the graph's representation format — in-memory object graph, serialized config, or both? - What is the graph's representation format — in-memory object graph, serialized config, or both?
- Drop policy for completeness queues: drop oldest (recency) or drop newest (continuity)? Should be per-output configurable.
- When a relay has multiple inputs on an encapsulated transport, how are streams tagged on the outbound side — same stream_id passthrough, or remapped?
- What transport is used for relay edges — TCP, UDP, shared memory for local hops?
- Should per-output byte budgets be hard limits or soft limits with hysteresis?
- Which relay scheduler policies should be implemented first, and what is the right interface for plugging in a custom policy? Minimum viable set is probably strict priority + weighted round-robin.