e3375530f6
The new max_ms check bounded nothing, because a policy could set max_ms up to
2^53 − 1. A still's piece could then state 2^32 − 1 frames. Rust hashed once
per stated frame (about 29 minutes), and Python built a list of n references
(about 34 GB).
- **§3.4 item 5 and §4.4.** max_ms is at most 600000, and at most 2^24 units on
every component's timebase. Both are policy-piece-bounds, in both readers.
§4.4 gives the reason: a verifier takes a piece whole, so the longest piece
bounds its work. Ten minutes is far past any piece a delivery cuts, and 2^24
units bounds the work on any timebase, which may have up to 2^32 − 1 units a
second.
- **§11.3, before any frame is decoded.** Each piece's floor object, where its
framing reads, must hold one unit per frame of its piece
(floor-object-mismatch). Both verifiers make this check first.
- **Held stills.** Python holds a still's frame and its count (Held) and hashes
the digest a block at a time. Rust's held_digest also feeds a block at a time.
- **Corpus.**
- refusals: max_ms 600001; and the default max_ms on a timebase of 2^32 − 1
units a second.
- policy/max-piece.toml: accepted at both bounds.
- staged-mutations max-ms-past-cap (policy-piece-bounds).
- staged-mutations still-at-cap: the still given the longest piece the policy
allows, its manifest naming the frames, refused by the floor count in both
verifiers.
- **policy_diff.** Its random policies now reach both bounds.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
19 lines
423 B
TOML
19 lines
423 B
TOML
# Accepted: the longest piece a policy may allow (§4.4): max_ms of ten minutes, which is
|
|
# exactly 2^24 units on a timebase of 16777216 units in 600 seconds.
|
|
schema = "wai.pack.policy/1"
|
|
asset_id = "max-piece"
|
|
lead = "v"
|
|
|
|
[[component]]
|
|
id = "v"
|
|
media = "video"
|
|
timebase = { num = 16777216, den = 600 }
|
|
|
|
[[ladder]]
|
|
id = "b0"
|
|
component = "v"
|
|
capability = "wai.video.int_motion"
|
|
role = "base"
|
|
|
|
[segmentation]
|
|
max_ms = 600000
|