FFmpegEngine derives progress as stats.time / durationMs * 100, and the statistics callback runs on every conversion in FFmpegEngineTest — they all pass durationMs = 3_000. But every call site omits onProgress, so nothing on any source set had ever looked at the number.
Mutation: replace percent with a constant. Reddened nothing.
What already existed covers the plumbing downstream and not this: #196 covered the worker's progress lambda with a fake engine that reports whatever the test tells it to, and ProgressNotificationTest covers throttling the same way. The arithmetic was the one part with no reader.
Why the duration is deliberately wrong
The new test passes 30 s as the duration for a fixture that is exactly 3.000 s. The conversion still encodes the whole clip, stats.time still climbs to ~3000 ms, and the reported percentage tops out around 10 rather than 100.
That is what makes it bite. A range check alone is worthless here:
assertion
constant 0
[0, 100]
ignores durationMs
every value in 0..100
passes
passes
passes
never goes backwards
passes
passes
passes
peak in 5..25
fails
fails
fails (~100)
The band is deliberately loose — 5..25 for an expected 10 — because the last statistics callback can land slightly before the final frame, so the peak is "about 3000 ms of a claimed 30 000", not exactly it.
Verification
Local API 34 emulator, after clearing stale result XML:
API 34: tests=61 failures=0 errors=0 skipped=3
61 = the suite's 60 plus this one. The 3 skips are RealMediaBenchmark's two and HardwareFallbackTest (#223).
Closes #229.
`FFmpegEngine` derives progress as `stats.time / durationMs * 100`, and the statistics callback runs on every conversion in `FFmpegEngineTest` — they all pass `durationMs = 3_000`. But **every call site omits `onProgress`**, so nothing on any source set had ever looked at the number.
*Mutation:* replace `percent` with a constant. Reddened nothing.
What already existed covers the plumbing *downstream* and not this: #196 covered the **worker's** progress lambda with a fake engine that reports whatever the test tells it to, and `ProgressNotificationTest` covers throttling the same way. The arithmetic was the one part with no reader.
## Why the duration is deliberately wrong
The new test passes **30 s** as the duration for a fixture that is exactly **3.000 s**. The conversion still encodes the whole clip, `stats.time` still climbs to ~3000 ms, and the reported percentage tops out around **10** rather than 100.
That is what makes it bite. A range check alone is worthless here:
| assertion | constant `0` | `[0, 100]` | ignores `durationMs` |
|---|---|---|---|
| every value in `0..100` | passes | passes | passes |
| never goes backwards | passes | passes | passes |
| **peak in `5..25`** | **fails** | **fails** | **fails** (~100) |
The band is deliberately loose — 5..25 for an expected 10 — because the last statistics callback can land slightly before the final frame, so the peak is "about 3000 ms of a claimed 30 000", not exactly it.
## Verification
Local API 34 emulator, after clearing stale result XML:
```
API 34: tests=61 failures=0 errors=0 skipped=3
```
61 = the suite's 60 plus this one. The 3 skips are `RealMediaBenchmark`'s two and `HardwareFallbackTest` (#223).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #229.
FFmpegEnginederives progress asstats.time / durationMs * 100, and the statistics callback runs on every conversion inFFmpegEngineTest— they all passdurationMs = 3_000. But every call site omitsonProgress, so nothing on any source set had ever looked at the number.Mutation: replace
percentwith a constant. Reddened nothing.What already existed covers the plumbing downstream and not this: #196 covered the worker's progress lambda with a fake engine that reports whatever the test tells it to, and
ProgressNotificationTestcovers throttling the same way. The arithmetic was the one part with no reader.Why the duration is deliberately wrong
The new test passes 30 s as the duration for a fixture that is exactly 3.000 s. The conversion still encodes the whole clip,
stats.timestill climbs to ~3000 ms, and the reported percentage tops out around 10 rather than 100.That is what makes it bite. A range check alone is worthless here:
0[0, 100]durationMs0..1005..25The band is deliberately loose — 5..25 for an expected 10 — because the last statistics callback can land slightly before the final frame, so the peak is "about 3000 ms of a claimed 30 000", not exactly it.
Verification
Local API 34 emulator, after clearing stale result XML:
61 = the suite's 60 plus this one. The 3 skips are
RealMediaBenchmark's two andHardwareFallbackTest(#223).🤖 Generated with Claude Code