Repository navigation
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
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 heldleadseconds 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 throughfps,setpts,settb,formatand ascaleto a width and height that are numbers or parameters (what the call wrote, else the DEFAULT); tests intest_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