* Honor CARGO_BUILD_TARGET in FreeBSD packaging for aarch64 release builds
The shared release workflow cross-compiles FreeBSD aarch64 in the x86_64 VM and sets
CARGO_BUILD_TARGET. package.sh ignored it: it built for the host, read binaries from
target/release, and took the arch from uname -m (amd64 on that VM), so the aarch64 build
would have produced an x86_64 archive with x86_64 binaries.
When CARGO_BUILD_TARGET is set, pass --target, read binaries from target/<triple>/release,
name the archive from the target arch, and skip the --version smoke test (the binary cannot
run on the x86_64 host). Unset keeps the previous behavior.
* Reject unsupported CARGO_BUILD_TARGET and gate the smoke test on the host triple
Only x86_64-unknown-freebsd and aarch64-unknown-freebsd are accepted when CARGO_BUILD_TARGET
is set; anything else exits 2 instead of being labelled freebsd-x86_64.
The --version smoke test now runs when CARGO_BUILD_TARGET is unset or equals this host's
full FreeBSD triple, so a native explicit target is still checked.
Resolve crates/vp9enc/src/lf.rs: main moved sb_plane into FrameFilter::sb_plane
(mi grid and limits as struct fields, no allow(too_many_arguments)). The
branch's 8-lane group filtering (apply mask per lane, filter_group) is
re-applied inside that method; the now-unneeded too_many_arguments allow on
filter_group is dropped (7 arguments).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Resolve crates/av1enc/src/decide.rs: main replaced the long try_tx/code_tx
argument lists with the TransformBlock struct. try_tx and code_tx keep the
branch's scratch-buffer design (TxScratch taken out of the decider) and take
a TransformBlock; reconstruct now takes its three output buffers as a
ReconBuffers struct to satisfy the denied clippy::too_many_arguments.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Conflict in crates/track/src/camtrack/bundle.rs (imports): upstream replaced
the linalg glob import with an explicit list; kept that list and added the
branch's SolveError import (use super::{Distortion, SolveError}). Input
validation, size budget and Result-returning adjust/cost are unchanged.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Conflict in crates/track/src/face.rs: upstream moved the feature-blob search
into FaceTracker::feature_blobs. Re-applied the branch there: the per-pixel
point-in-polygon loop is replaced by non_skin_inside (one crossing pass per
window row) and the roll rotation is hoisted with face_mapper.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Accelerator::comp_frame_yuv420 (default None) renders a top-level comp frame and
converts it over the background to the H.264 export's 8-bit BT.709 limited-range
4:2:0, every byte within one level of the CPU conversion (the GPU kernel follows
it operation for operation, including NaN and half-away-from-zero ties, but a
driver may contract its arithmetic). A 4K frame then reads back 12 MB of planes
instead of 133 MB of RGBA f32.
The H.264 export asks the accelerator for planes when a frame needs nothing after
the render (progressive, project depth, no crop/resize, rendered at the output
size) and otherwise renders and converts on the CPU as before. Deferred
readbacks (a browser worker) keep the pass-based path. Sizes the kernel can't
take (width not a multiple of 8, odd height) are declined before any GPU work.
Like Cx::frames, h264_frames caps GPU frames in flight only while the
accelerator is up (map_frames_while with the same liveness check): once the GPU
stops for good, the remaining frames render on the CPU side by side instead of
one at a time.
rgba_to_yuv420 moves to effectcraft_raster::yuv so the export and the GPU tests
share one reference. The GPU tests skip without an adapter (tests::gpu()), as
the crate's others do.
The policy check now reads the compiled AppSearch and RegLocator rows for the
remembered-folder properties (registry root, key, value name and type for both
scopes) and runs the DIR, FOLDER, PATH and legacy exe actions in sequence order
against seeded values, so their precedence and the preset-folder guard cannot
regress. It also replays the wizard folder actions in sequence order (a
remembered folder beats the new-install default, a typed folder beats both) and
requires the machine restore action between the scope page and costing.
The pre-signing check matched any folder named Program Files, so it rejected
a valid MSI when Windows resolves Program Files elsewhere, accepted the 64-bit
root for an x86 package and accepted a different app name. Build the expected
folder from the package architecture's resolved root and the policy name.
Upstream split lib.rs files into modules and moved engine commands/ to cmd/; this branch's change merges without textual conflicts.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
H.264 and ProRes exports of a 60-frame comp (several render batches, a
rotating stroked ring, a fading solid at a fractional position, a
Screen-mode shape, 8 bpc) must keep the exact bytes main wrote before the
two previous commits.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Much of a layer buffer is often transparent (a stroked ring, a glow-padded
text layer, a precomp canvas), yet every destination pixel sampled it
bilinearly, and 8/16 bpc comps then re-quantised the layer's whole rotated
bounding box.
- Bilinear warps skip 16x16 source tiles whose pixels (and a one-pixel
apron) all have zero alpha: their samples are transparent and were never
drawn.
- The fast affine warp reports the rectangle it changed and, given the
comp's levels, quantises each pixel as it blends it, so draw_comp has
nothing left to re-quantise for that layer. quantize_px moves to
effectcraft-raster for this.
- quantize_rect skips runs of four all-zero (+0.0) pixels, which quantise
to themselves.
- to_rgba8 / to_rgba8_over convert row by row instead of per 4-byte item.
Every pixel stays bit-identical: tests compare the warp against the
reference path, fused quantising against quantising after blending, and
the zero-run skip against per-pixel quantising.
With the previous commit, demo comp to H.264 (`cargo xtask bench --scenario
demo --format h264 --frames 300`, 11 interleaved runs on a 16-thread Ryzen):
wall 9.26 s -> 6.97 s median (-24.8%), 8.55 s -> 6.55 s min (-23.3%); CPU
time -23%. Output byte-identical.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Movie exports (H.264, HEVC, AV1, ProRes, uncompressed) rendered a batch of
frames on every core, then encoded it frame by frame while the render
threads waited. Each batch now encodes on a pool shared by all exports while the
next batch renders (Cx::frames_beside). With deferred GPU readbacks, or
where no thread can be started (wasm without threads), the two still take
turns. A panicking encoder becomes an export error.
H.264 frames are converted to 4:2:0 on the render threads, per frame, instead
of on the encoder's critical path. The conversion reads 8-bit levels from a
table and rounds without a libm call; both give the same values as before
(tested against the previous formula).
Demo comp (1920x1080, 300 frames) to H.264 on a 16-thread Ryzen, export
wall time -6% (median of 7 interleaved runs); output byte-identical.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
BFlat