Skip to content

hold: a first-frame source whose buffer is full is primed; cli: a lateral that scales is hinted the size it scales to - #20

Merged
imbcmdth merged 2 commits into
mainfrom
fix/port-feed-size-2
Oct 20, 2026
Merged

imbcmdth merged 2 commits into
mainfrom
fix/port-feed-size-2

Conversation

@imbcmdth

Copy link
Copy Markdown
Owner

Two fixes found by running foundmeat's compiled broadcast query on the published 0.32.4 wheels.

  • hold: a first-frame source waited until it held lead seconds before its feed came up, and a port feed is read only while its source has room (600 frames or 96 MiB). Twelve 1080p rgba pictures fill 96 MiB, short of the eighteen a 0.3 s lead takes at 60 fps, so a feed conformed to 1080p never came up: its reader waited on room for the rest of the run, the picture black, the decoder idle. Racy, so an occasional connection got through. It bit on 0.32.4, where the feed is now conformed to its declared 1920x1080, and on 0.32.3 with a full-size clock. A full buffer now counts as primed, as it already settles a tick for a source bound in the plan; unit test with pictures that fill the cap short of the lead.
  • cli: a lateral's picture size was read only from a shape on an input's own picture, so foundmeat's cams, scaled to 800x450 by their parameters' defaults, were still conformed to the 16x16 clock. The compile now follows the column through fps, setpts, settb, format and a scale to a width and height that are numbers or parameters (what the call wrote, else the DEFAULT); tests in test_laterals.py.

On foundmeat's query on the box, three runs: the main feed comes up every time, 2400 pictures decoded, NVDEC busy, 10.1 to 10.5 media seconds per 10 s; the cams arrive at 800x450 with nothing converted, their timecode readable (gradient energy 6.4 against 1.9 on 0.32.4). GPU suites green on the card.

🤖 Generated with Claude Code

imbcmdth and others added 2 commits October 19, 2026 23:10
A first-frame source waits until it holds lead seconds before its feed
comes up, and a port feed is read only while its source has room: 600
frames or 96 MiB. Twelve 1080p rgba pictures fill 96 MiB, short of the
eighteen a 0.3 s lead takes at 60 fps, so a feed conformed to 1080p never
came up and its reader waited on room for the rest of the run, the
picture black and its decoder idle. foundmeat's main feed did this on
0.32.4, where it is now conformed to its declared 1920x1080, and on 0.32.3
with a full-size clock. A full buffer now counts as primed, as it already
settles a tick for a source bound in the plan.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A run-time lateral's picture size was read only from a shape on an input's
own picture, so foundmeat's cams, scaled to 800x450 by their parameters'
defaults, were still conformed to the 16x16 clock. The compile now follows
the column through fps, setpts and format, and through a scale to a width
and a height, each a number or a parameter the call writes or gives a
DEFAULT, the shape's own values read the same way.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@imbcmdth
imbcmdth merged commit a0f7597 into main Oct 20, 2026
2 checks passed
@imbcmdth
imbcmdth deleted the fix/port-feed-size-2 branch October 20, 2026 06:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant