A video becomes an asset like a sound: uploaded once, converted to one
format by a worker of its own, cut into clips in its tab, and worn by a
sprite through its Texture row. Only Chrome is a target, without alpha.
- Server: POST ?r=videos queues the upload under the hash of its bytes,
so the MP4's name is known at once. The worker (VideoWorker over
VideoFormat) writes H.264/AAC, yuv420p, constant frame rate, a
keyframe every 15 frames, at most 1920x1080, with a poster and the
details beside it. A failed job says why and is tried again on the
next upload.
- An upload may be up to 2 GB. It is streamed from the request to disk
and hashed there, so php-fpm holds none of it in memory. The other
routes keep their 256 MB.
- The worker runs in the container game-maker-video on stein2, a
compose project of its own (tools/video/), and in CI beside the PHP
server. The CI image has ffmpeg for it.
- Model: asset type video with size, length, frame rate and sound, and
clips like a sound's. The clip helpers and commands serve both.
- A sprite's Texture row offers videos and clips after the pictures.
resolvePicture names a playing video by a key, and the texture library
hands it to a VideoLibrary with one player per key.
- The editor shows a placed video as a quiet preview. Play starts it
over at its clip's start and lets it be heard through the master bus,
a pause holds it, Esc makes it quiet again.
- Video tab: the picture, a ruler, the clip strip and a track on the
Sound tab's time axis. A drag spans a clip, a handle moves an edge,
Play plays the picked clip.
- The picker shows a video on its way with its progress and adopts an
upload from it once it is ready. Dropping a video file does the same.
Decided on my own:
- Two sprites wearing the same clip share one player and show the same
picture. Control per instance belongs to the follow-up with nodes.
- A video plays in real time, the game's time scale does not slow it.
- The container may use 3 of the 4 cores of stein2.
Findings:
- The first real upload (279 MB) got 413: the API's own ceiling of
256 MB for every request, not nginx or the Brandmauer.
- Chrome has no picture of a video that never played, and a Pixi
VideoSource drawn before the first frame stays empty for good. The
texture is made in the first frame callback (openVideo).
- A player nobody asks for in 2 s is let go. The inspector's PREVIEW
asked only on an edit, so with the sprite not on screen its texture
was destroyed under it and the batcher threw on every frame. The
preview now redraws every frame while it shows a video, like a Time
shader. A let-go texture keeps an empty source instead of none.
- VideoSource.load() reloads the element and cuts off an earlier
play(). Playing starts after loadeddata.
Tests:
- PHP videos.test.php: 68 checks, with the real ffmpeg
- 300 MB upload through Brandmauer and nginx: 201 in 21 s, php-fpm at
13.7 MB RSS at most
- Unit videos.test.ts: 20 tests
- e2e 66 (stein2, atx was off): ALL PASSED, 18 checks; e2e 04 with the
new asset count green
- Gate (atx): 294 files, 4520 tests. serialize.test.ts used video as
its example of an unknown type and now uses a made-up one.
- Counter-checks: a keyframe gap of 30 fails the PHP check, a key that
keeps the video's end fails 2 unit tests, a clip without its end
fails "plays only its stretch" in e2e 66
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sounds follow the road fonts already paved: the file goes to the server
content-addressed under its sha256, the project keeps a named asset that
points at it, and nothing is ever re-encoded. The format is read from the
file's own signature, not from what the browser claims - the same .m4a
arrives as audio/mp4, audio/x-m4a or as nothing at all.
Playing is two nodes. "Play sound" takes the asset and may raise or lower
its volume; every call is its own voice, so two jumps in a row are two
jumps heard. Its loop input is a choice of three - from the asset, on,
off - because a checkbox has to spend one of its two positions on "not
set" and would lose a case: an asset that loops could then never be
played once.
Below the graph core stays browser-free: NodeContext hands out an asset
id, BehaviorSystem resolves it against the project and folds the asset's
own volume and loop into the call, and only viewport/SoundLibrary knows
about Web Audio. A run without a sink plays nothing instead of throwing.
The CI browser is muted, so the ear is no witness: the debug hook counts
started and stopped voices, and step 34 reads that counter.
A font asset holds a file and nothing else, the twin of a texture: the server keeps it
content-addressed under data/fonts/{sha256}.{ext}, with the format read from the file's own
four-byte signature (finfo reports fonts inconsistently across libmagic versions). A text
wears one through its ordinary Font property, so overrides, reset, undo and the Properties
node come for free; no font means the editor's own typeface.
The picker lists everything the server holds and renders each row in the face it offers.
The family name is gm-font-<hash16>, never the name inside the file, so two "Regular" cannot
collide. WorldViewport.syncText is the single place that draws it, which covers scene, game
preview and play at once.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5.5