M5 / final M2-stack work. The fork now identifies itself unambiguously
in logs, the API, and the README without changing the Go module path
(internal imports stay at github.com/datarhei/core/v16 — see NOTES.md
for the rationale).
Identity surfaces:
- app/version.go gains Variant ('dragonfork') and Fork ('Datarhei —
Dragon Fork') as vars (overridable via -ldflags for downstream
re-packagers).
- api.About + the /api endpoint expose 'variant' and 'fork' fields;
Swagger docs regenerated.
- Startup banner logs 'variant' + 'fork' alongside the existing
application + version fields, so a TrueNAS sysadmin tail-following
/var/log can tell at a glance which fork is running.
Documentation:
- README.md rewritten with a Dragon Fork header and Quick start; the
upstream feature surface is summarised in 'From upstream Datarhei'
with a clear additivity statement. Sample process JSON, multi-input
pipeline guidance, link to the design + testing docs.
- NOTICE: Apache 2.0 §4(d) attribution to upstream datarhei Core,
Pion, Echo, FFmpeg.
- CREDITS: enumerated dependency list with licenses.
- CHANGELOG.md prepended with a 'Datarhei — Dragon Fork' section
starting at v0.1.0-dragonfork; upstream's '# Core' history preserved
below.
Module path stays github.com/datarhei/core/v16 by design — the fork is
distinguished by repo location and branch history, not import path.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
BuildArgs hardcoded -map 0✌️0 / -map 0🅰️0 for the two RTP legs.
Correct for production RTMP/SRT publishers (single combined input),
but breaks any process whose audio lives on a different input index
— multi-input lavfi test scaffolds, multi-camera pipelines, SDI +
file-audio mixes, etc.
Adds VideoMap and AudioMap fields to ConfigWebRTC (and the API DTO),
defaulting to the prior literals so existing deployments are
unaffected. BuildArgs reads them.
Tests:
- TestBuildArgs_DefaultMaps locks the empty-string default behavior
- TestBuildArgs_CustomMaps drives the multi-input override path
- TestProcessConfigWebRTCMapsRoundtrip extends the DTO roundtrip
Closes#2.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ProcessConfig in http/api/process.go shipped without a WebRTC field, so
JSON arriving at POST /api/v3/process was silently stripped of
"webrtc":{"enabled":true}. Marshal() handed restream a zero
ConfigWebRTC, the OnProcessStart hook no-op'd, and every WHEP request
returned 404 — even with a running webrtc-enabled process.
Caught on the M2 TrueNAS deploy at acceptance time: GET /process/{id}/config
came back without the webrtc block, despite the inbound JSON having it.
This is the API-layer twin of the earlier 'fix(config): preserve WebRTC
section in Config.Clone()' — same class of bug (drop-on-copy), different
struct.
- Add ProcessConfigWebRTC mirroring app.ConfigWebRTC.
- Marshal: copy DTO -> app.Config.WebRTC.
- Unmarshal: copy app.Config.WebRTC -> DTO.
- Regression tests cover both the JSON->DTO->Config path and the
default (no webrtc block) case.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Installs the WebRTC egress subsystem at Core boot when
cfg.WebRTC.Enable is true and the subsystem constructs cleanly:
- http.Config gains an optional WebRTC *appwebrtc.Handler field;
server.setRoutesV3 mounts its WHEP routes on the JWT-protected
/api/v3 group.
- api.start() constructs the Subsystem, registers its ProcessHooks
with the restreamer, and builds a Handler. A construction failure
is logged and Core continues without WebRTC — consistent with
disabling the subsystem outright.
- api.stop() closes the Handler (tearing down active peers) before
closing the Subsystem (releasing per-process UDP sockets), mirroring
the RTMP/SRT teardown pattern.
Verified: go build ./... clean; go test ./app/webrtc/...
./core/webrtc/... ./restream/... ./http/... all pass.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
created_at represents the time when the configuration has been persisted to disk.
loaded_at represents the time when the configuration has actually been used.
If created_at is larger than loaded_at, then the Core needs a reload in order
to apply the latest configuration.
if created_at is lower than laoded_at, then the Core applied the latest
configuration.
The value of updated_at is irrelevant and shouldn't be used.
For the API endpoint /v3/process two new query parameter are introduced
in order to list only processes that match a pattern for the id and the
reference: idpattern and refpattern. The pattern is a glob pattern. If
patterns for both are given, the results will be intersected. If you use
other query parameters such as id or reference, they will be applied
after the result of the pattern matching.
