Skip to content

docs/plans: rusty_h264 and rusty_jpeg upgrades for the chip - #10

Open
Ttimmahlax wants to merge 2 commits into
mainfrom
plans/h264-jpeg-upgrades
Open

docs/plans: rusty_h264 and rusty_jpeg upgrades for the chip#10
Ttimmahlax wants to merge 2 commits into
mainfrom
plans/h264-jpeg-upgrades

Conversation

@Ttimmahlax

Copy link
Copy Markdown
Collaborator

The upstream list Janus (the ESP32 programme) needs from rusty_h264, rusty_jpeg and rff, with a gate and a chip-side effect per item. Companion to rusty_h264 PR #7 (no_std). Docs only.

tim-almond-house and others added 2 commits September 2, 2026 09:16
The upstream list Janus needs from the two codecs and from rff: borrowed
frames and caller-buffer output, a public keyframe request, Baseline as a
named configuration, a written memory model, rusty_jpeg encoder and
decoder without std with YUV input and slice sources, and rff catching up
(the rusty_h264 pin, preset/profile flags, rtp:// input, an MJPEG-over-HTTP
demuxer). Each item names its gate and its effect on the chip.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The no_std pass's follow-ups (std on every std consumer of a bare workspace
dependency; the sequential fast-path flag made thread-local) are recorded
under Done. Upgrade 8 names the gap the libm feature still has: with std on,
only sqrt is routed through libm, so the host-versus-chip determinism the
feature promises holds for one method. Priority row 13.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.

2 participants