add a worked example wiring dora-webcam into this node

The only dataflow here drove the viewer from a test fixture, so nothing showed
how to consume a real producer. dataflow_webcam.yml wires dora-webcam v0.1.0
into it: the camera publishes std/media/v1/Image and this node draws it, with
depth, camera_info, text and bbox simply unwired, which is what every input
being optional buys.

The dependency points one way only. A consumer naming its producer is an arrow;
dora-webcam names no consumer, so there is no cycle.

Two things are deliberate. The camera's output type is repeated in the dataflow
because a `git:` node's manifest is not read at validate time, only at build, so
without it the two contracts are never compared -- a deliberate mismatch is
caught with the annotation and passes silently without it. And the file carries
no strict_types: a camera publishes an image and nothing else, and strict
validation warns about every typed input a dataflow leaves unwired.

Interoperability was verified directly, feeding dora-webcam's packed payload
into this node's decoder across bgr8, rgb8, jpeg, png and yuv420: the struct
types are identical and the lossless encodings round-trip exactly.

The dataflow validates but was not run: with dora-cli 1.0.1 a `git:` node
pointing at a private repository does not build over either transport, which
the file and the README record.
This commit is contained in:
2026-09-15 06:26:10 -03:00
parent 363bf006be
commit 15e0b9155a
2 changed files with 65 additions and 0 deletions
+25
View File
@@ -66,6 +66,31 @@ CI=true SOURCE_FRAMES=30 dora run dataflow.yml --uv
`SOURCE_WIDTH` and `SOURCE_HEIGHT` (default 640x480) set the frame size.
### With a real camera
[`dataflow_webcam.yml`](dataflow_webcam.yml) wires
[dora-webcam](https://gitea.liria.cl/liria/dora-webcam) into this node, and is the
worked example of consuming something that is not a test fixture:
```bash
dora run dataflow_webcam.yml --uv
```
The camera publishes `std/media/v1/Image` and this node draws it. `depth`,
`camera_info`, `text` and `bbox` are simply unwired — every input is optional, so a
plain viewer is the result.
It carries no `strict_types`, deliberately. A camera publishes an image and nothing
else, and `dora validate --strict` warns about every *typed* input this node declares
that a dataflow leaves unwired. The strictness belongs to `dataflow.yml`, which drives
all of them.
**Known limitation (dora-cli 1.0.1).** A `git:` node pointing at a private repository
does not build: over `ssh://` on a non-standard port the connection fails, and over
`https://` libgit2 reports `remote authentication required but no callback set`. The
dataflow validates and the wiring is the form a consumer should use, but running it
needs that fixed or the repository made public.
### Node manifest
[`dora-node.yml`](dora-node.yml) declares the node's inputs with type URNs. No source